After some discussions on the leandevelopment list, it would seem that slack has has more benefits than I realized. My current list:
- If you’re not the bottleneck in your process, adding slack won’t decrease throughput and may well increase it (since it makes it easier for you to avoid stealing resources from the bottleneck).
- Leaving a little slack makes your schedule more predictable: you can work harder to make a date if that should prove to be necessary.
- It gives people time to recharge.
- It gives people time to experiment, to try to find improvements that they might not have found if their nose was constantly at the grindstone.
One nice thing about lists like this is that you can turn them around to find places where you should be wary of applying it to your situation. In particular:
The first point suggests that, if you are the bottleneck, slack isn’t a particularly good idea: the bottleneck controls throughput, so the less the bottleneck works, the lower the throughput. And, even if you aren’t the bottleneck, you shouldn’t stick in so much slack as to become the bottleneck. (And you should consider spending some of your slack time figuring out how to help the bottleneck.) Exercise for the reader (actually, an exercise for the writer): what’s the bottleneck in your organization?
The second point suggests that you should have enough control over your schedule to know when you should eat into your slack. Mary Poppendieck mentioned a company that had been working on an 8-week cycle, with 6 weeks development and 2 weeks testing. They got the 2 weeks of testing down to one week; they turned the second week into slack intstead of adding it to development. That way, if problems show up after release, people can jump on them immediately. (And people are motivated to make sure problems don’t show up after release!)
The third point is a reminder that, if necessary, people will create their own slack whether you like it or not; if you try to avoid that, your reward will be burned-out employees. The flip side is that you don’t need vast amounts of slack to get this benefit.
And the fourth point is the most interesting one, and the one whose benefits are potentially largest and hardest to predict. Which means that I have nothing coherent to say about it.
Post Revisions:
There are no revisions for this post.
[…] Of course, there are more levels to this problem: in particular, we shouldn’t be inserting defects into our code in the first place. (We’re getting better at that, fortunately.) And we don’t want to use Bugzilla as a substitute for our product backlog: there should be some control over how features get scheduled for implementation. And it can be hard to maintain a steady implementation pace if you’re getting constantly interrupted by bug work. There are solutions to all these problems, however. (E.g. for the latter, a two-part strategy of not writing defects in the first place and allocating slack in your schedule in the second place.) For now, from my point of view, our most urgent issues are (first) reducing the defect backlog and (second) improving response time. […]
11/5/2006 @ 4:03 pm