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?
A very brief explanation of kanban
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.
David Peterson and Mike Burrows have more detail.
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.
niksilver.com 
I see limits as a series of levers that put the team in control of their process. By adjusting the levers (limits) and measuring the outcome on flow, throughput, and cycle time, the team will find out if increasing or decreasing a limit is an improvement.
In terms of analogies, how about variable speed limits on motorways, like those on the M25?
A quote from Mary and Tom Poppendieck: “Just as a highway cannot provide acceptable service without some slack in capacity, so you probably are not providing your customers with the highest level of service if you have no slack in your organization.”
Ian — Yes, I think the limits are levers, though I’m hoping to find something that’s both more tangible (i.e. a lever on what, exactly?) and somewhat distant from the reality (to give a new perspective).
John — I did consider the traffic analogy, but still wasn’t satisfied with that. Increasing the limits is equivalent to building more lanes on the motorway, but the consequence is different. In kanban it’s a worsening of throughput. But in road building it makes no difference at all — more cars come along and clog up the roads again. It’s neither worse nor better. The analogy breaks down because cars propel themselves (effectively: they each come with their own driver) but tasks don’t complete themselves — they still depend on the same number of people.
Imagine you are pushing water through a (horizontal) pipe. You apply a constant force.
With a smaller pipe, each drop of water will get more force applied to it, and hence more speed.
That leads to a single drop of water getting to the other end faster than if the pipe was really wide.
Water is work. You applying the force is you working (i.e. putting in the same hours every day).
A drop of water is the work item. And finally: the pipe is the limit. (The width of the pipe, to be exact)
You can get 10 drops of water 1 cm of the way, or 1 drop of water 10 cm of the way to finish.
Limits are rules for self-control. They give you a focus on depth, over breadth.
If respected, they force you to complete the thing you are working on instead of jumping to the next.
I think if we follow the analogy of the tap we have to consider the tap is part of the system and the water is the work. If we now consider the sink which is also part of the system by turning on the tap to full we run the risk of the sink filling up before it drains away. In agile this would cause the sink to overflow and work would be lost to either be mopped up later or just shelved forever. In KANBAN this would show that work was getting stuck in the sink area and when reviewed it would further show that this isn’t however the fault of the sink and there are possibly two solutions. The first is to decrease the flow or we could increase the size of the waste pipe. Now increasing the size of the waste pipe might cause problems further down or further back up the system but this is the point of KANBAN, its as Nik says to surface your bottle necks so you can try and balance the system. For me the Tap analogy works.
Yes, I think the tap/water analogy might be the best one available… and in my conversations I’ll just have to skirt around the edge of toilets, so to speak.