Mark Needham

Ken Schwaber recently wrote a blog post where he compared the differences between the kanban, lean and scrum approaches to software development and although I haven’t had the same experiences as he has with the first two, one interesting thing he implies is that with a scrum approach we have slack time built in.

God help us. People found ways to have slack in waterfall, to rest and be creative. With Lean and Kanban, those hiding places are removed. We now have a progressive death march without pause.

The project that I’m currently working on has switched emphasis from being in pure delivery mode into a combination of delivery and handover and it’s been quite noticeable how much more slack we have in the system as a result.

I find it much more enjoyable when there’s a bit of slack such that we’re not churning out story after story.

It gives you the opportunity to explore the code base a bit more and try out any ideas that you have to see if they’re likely to improve the productivity of the team.

An example of this on our project is that we’ve had the time to introduce a calculation descriptions DSL that my colleague Dermot had written in his own time.

This has helped reduce the number of tests required in certain areas of the code base as well as making the code more intuitive and therefore easy to understand.

It can be quite difficult to create this slack time when the team is under big deadline pressure and working on anything which isn’t directly related to hitting that deadline isn’t considered valuable.

I’ve noticed that the typical slack in the projects I’ve worked on tends to be towards the end of the day if we finish a story late on.

That tends to disappear if the team is working late and people start to become too tired to notice that there might be a better way to do things.

It seems to me that it would beneficial to try and work some slack time into projects to allow for the type of innovation that allows us to come up with ideas that allow us to be more productive.