I’ve been involved in a few conversations this last week or so about kanban, after Ian Carroll visited the Guardian to talk about his experiences with it. The key thing that kanban adds to the usual agile processes is the idea of limits on each stage of development. I started thinking about how to explain the limits to non-process people, and found myself stuck: I know what the limits do, but what actually are they?
Kanban is designed to improve throughput. It operates on work items each going through various predefined stages of a pipeline. So in software development that might be “Ready”, “Back-end development”, “Front-end development”, “Testing”, and “Deploy”. As a refinement some of these stages might be split into “In progress” and “Done”. At any one time a work item is in one of these stages, and is called work in progress, or WIP. The key element of kanban is that it places a hard limit on how much WIP can exist in any stage at any one time. So “Back-end development in progress” might have a limit of 3 items, while “Testing” might have a limit of 2 items.
What the limits do
What’s counter-intuitive about this is that throughput increases because of these limits. The limits surface problems (“We’ve got a bottleneck in testing”) and force the team to address them. Because we usually don’t like to face up to problems it’s very tempting to lift the limits or to dismiss the approach altogether. So explaining the value of the limits is very important, and how to do that is what I’ve been thinking about.
There are lots of good descriptions out there of what limits do:
- “Limiting the amount of work-in-progress (WIP), at each step in the process, prevents overproduction and reveals bottlenecks dynamically so that you can address them before they get out of hand.” — David Peterson
- “Work In Progress limits are designed to reduce multi-tasking and maximize throughput.” — Igor Stoyanov
- “Putting limits on inventory has some very big benefits: less cash is tied up, less space, less handling, less handling damage, etc. Reductions of work-in-process (WIP) inventory have the additional benefits of reducing your products’ lead-time” — Hands On Group (warning: link contains gratuitous pictures of steel coils)
But in terms of working through a description — perhaps by analogy — I’d like to be able to say what a limit is. When someone says “Why have limits at all? Why not just let as much work through as possible?” I’d like to be able to say more than “That won’t work” and instead say, “Look, it’s like a…” Like a… what?
What is a limit?
Raising a limit too high will create too much turbulence and confusion and slow things down. Lowering a limit too far will hold things back and hence slow things down. What kind of thing does this? What analogy can we use to explain it?
It’s tempting to say that limits are priorities. But it’s only all of them together that influence priorities — none of them individually represents a priority, so raising and lowering them becomes meaningless in this analogy.
Nor is a limit a warning signal. A limit is a hard limit, and a strict command that no more may enter this stage. That’s more than just a warning. But saying it’s a command is also insufficient, as that doesn’t help us understand the issues around making sure the adjustment is just so.
I’m tempted to say a limit is a flow control. This fits naturally with the idea of kanban regulating flow, but I have a couple of problems with this. First, it’s too close to the actual thing itself — if you’re wary or unsure of the idea of kanban in the first place this isn’t going to provide enough distance to see it from a fresh perspective. Second, it sounds like something that’s part of a toilet.
Maybe a limit is analogous to a tap. That’s a kind of flow control, but even with this I don’t have an answer to the question “Why don’t we just open up all the taps as much as possible?” The analogy breaks down at the crucial point because water flows by itself, but work doesn’t get done by itself.
I’ve struggled with this for a few days now and don’t have an answer. Any ideas appreciated. Perhaps it doesn’t matter. Perhaps everyone will just naturally understand the virtues of limiting work in progress. However I doubt that’s the case, and until I find a suitable analogy this will gnaw away at me.