What Is Slack Time For?

Jurgen Appelo recently touched the subject of slack time discussing what kind of tasks are supposed to be done in such time slots.

First thing that I find disputable is reducing slack time to mere padding: “I expect the task to be done in 1,5 hours but to be perfectly safe I’ll start it 3 hours earlier so I can deal with unexpected difficulties.” I guess I’m way closer to Marcin Floryan’s comment under the post. Anyway, that’s not what raised my biggest concerns.

I don’t agree with Jurgen on what slack is, or should be, for. Jurgen points that when we think about important things, like improvement, refactoring, learning and brushing teeth, we should actually plan for that and not hope that there will be enough slack time to have all of them done somehow. After all, we know that hope is not a strategy. Well, at least not a good one.

First, I see it a result of a simplified view of slack time. Actually, with Work In Progress limits set properly I can expect to have pretty stable amount of slack time over time. The thing I can’t predict is when exactly it will happen and who exactly will hit the limit and will be granted free slot. However, lucky me, statistics is on my side – the slack time distribution should be pretty fair over time.

I say “pretty fair” as when I have a very stable process, which software development is not by the way, I will likely face the situation that people who work on bottleneck part of the process won’t get slack time at all. Fortunately software development is really far from being “very stable” and even if it was we would still be able to deal with the situation using different means, e.g. the way Jurgen proposes.

Second, I actually think that slack is a perfect tool to be used against important but not urgent tasks. Improvement and learning definitely fall into this category. Refactoring may or may not, depending on a software development approach you use. And brushing teeth? Well, unless you accept the fact you’re killing colleagues with your poisonous breath I would treat it as important and urgent.

Yes, it means that I accept the fact that we may not spend any minute improving or learning (consciously) for some time. Considering my WIP limits are reasonable such situation would happen if and only if a team is perfectly balanced, our productivity keeps super-stable and there are no non-standard cases. Um, have I just said it is impossible not to have slack time? Oh, well.

Of course there is another situation: too loose or no WIP limits at all. And yes, in such case planning tasks, which would normally be done during slack time slots, is one of ways to go. But definitely not the only one! And not the most effective one either!

Actually planning improvement, learning, etc. tasks is just adding additional work items to your project. It doesn’t make you more flexible. Pretty much the opposite.

Simply adding “empty” slack time slots, which can be filled by a specific task which, at the moment, seems most reasonable can be a more effective approach.

You can do even better though. If your system natively introduces slack time these empty slots will appear not when someone arbitrary says so, but exactly when it is optimal for the system, i.e. when adding another regular task would overcrowd the flow, thus harm the productivity.

With such approach I believe slack time is actually the right place for important stuff.

Actually if a task is simply optional I would likely advise not to do it at all. After all, why add the complexity which isn’t needed. Isn’t everything around complex enough? Thus I don’t consider slack time a tool to be used to do optional stuff.