WIP limits - The magic sauce in Kanban

A software development process can be viewed as a queuing system. Little’s law states:

Lead Time = Work In Progress / Throughput

Lead time is the time that a work item (represented by a card on a Kanban board)  spends in a system in various work states. We want to reduce that, so we can get more work done i.e. increase throughput. As you can tell from the equation, reducing WIP (work in progress) is one way of achieving that. 

Less is more

We've all heard that and have certainly experienced that. That's an earthy way of stating Little's law. We can get more done, when we are focused and working on fewer things.

Why?

We are not wired to work on multiple tasks at the same time. When we say we are multitasking, we are really switching our attention from one task to the other i.e switching contexts. Context switching is a waste. Studies have shown that with every additional task taken up there’s a 20% loss. If we are working on three different tasks, we’ve lost almost half the time in just context switching.

Grandma was right - less is more. But don't tell grandma that. Not unless you want her to limit you to just a couple of  freshly baked cookies instead of the usual half dozen. 

Ok, we should limit WIP.  But how do we determine the WIP limit?

We experiment.

If we set the limit too high, we will continue working on multiple tasks. If we set the limit too low, we may cause bottlenecks and affect the flow of work in the system.We want the WIP limit to be optimal so we can have a smooth flow.

But it’s not a science. The board will tell you. 

There are advantages to starting with a lower WIP limit

Yes, they’ll cause starvation and pain. But lower limits will expose potential problems in the system. The industry uses the analogy of the WIP limit with lowering the waterline. Lowering the waterline exposes the rocks (i.e. bottlenecks and constraints).  When the problems are exposed, the team can work to remove the bottlenecks and constraints until the work flows smoothly again. 

And so on and so forth.

It creates slack

When everybody is working  all the time, there's not much time to introspect, retrospect, experiment, innovate or even  have lunch. As a rule of thumb, lead times go up when utilization crosses around eighty percent.  High utilization is not good. We've probably experienced this when the highways begin to fill up with cars or when the CPU on the computer gets toward its capacity.

How do we create slack?

We could hire additional members on the team. Imagine going to the folks that handle the purse strings and telling them that we want ten developers in the team but we only want to keep eight developers working because we've heard that utilization  at above eighty percent is not good. Good luck with that :)

Or - we could apply WIP limits

If we have a team of ten and we've put an overall WIP limit of 8, and assuming only one person works on an item at a time, we've taken away work from a couple of developers. In other words, we've intentionally created slack (or  excess capacity). And slack is good because it will allow these two "idle" developers to do a few things such as pair up with other developers or help resolve issues at bottlenecks.

And funnily enough, this will help get more work done.

It's an enabler for a "Pull"system

A pull system is one where the downstream process pulls in work only when it's ready to process it. This will result in producing only what's needed, transferring work to a work station when needed and reduce inventories i.e. it will help result in a lean outcome.

When we have WIP limits, we cannot take on work unless  we have a "slot" available on the work station. We are consciously defining our capacity to take on work. Imagine if we did not have limits. Work would be "pushed" to us by the upstream process - whether we were ready or not. And  most likely, it would just wait  to be acted on. That's a waste.

WIP limits make Kanban a "Pull" system.

It's an enabler for Kaizen

It's not that we don't want to improve, but it's usually that we don't know where to start. Or what our bottlenecks/problems are. Lower work limits are a great enabler for continuous improvement (kaizen). When you run into the bottleneck, resist the temptation to immediately raise the WIP limit. Get a conversation started in the team and look to resolve the bottleneck. 

Pound the rocks to submission. And if you still have a bottleneck, raise the limit to enable flow.

Trust the board. The board does not lie.