Kanban Blog

Kanban and other techniques for developing better software faster.

Kanban boards are mirrors

One of the first steps with Kanban is to map out the current process. A strength of Kanban is that it does not start with an anxiety-inducing upheaval. It starts simply by mapping out the existing process exactly as it stands. The Kanban board is a mirror that reflects the flow of work. What you see may not be pretty, but once the flow is visible, you can gradually make changes to your process to improve things.

A common mistake is to map handovers rather than the states a work item can be in. Individuals often perform several actions on a work item before handing it over to someone else. Mapping these intermediate, finer-grained states makes it easier to identify the exact location of bottlenecks and provides more possibilities for improving flow. For example, by allowing less busy people in the team to shoulder some of the burden.

It's worth emphasizing that a Kanban board with lots of columns does not mean you have to do lots of handovers. A single person may take a work item all the way across the board without any handovers. The intermediate work item states are only made explicit to provide insight. Later, handovers may be introduced but only if they improve flow.

It's also important to note that the states should reflect real states that the work goes through and not states that you think the work "should" go through. New states can be introduced later on, but the first task is to map reality as it is. Sometimes To Do/Doing/Done is as fine-grained as you can go to start with.

Redesigning to cut end-to-end time

When you have a multi-step process it's often better to perform the steps one-by-one, even if they could be done in parallel. The reason is that each step offers you a chance to learn something and catch problems early, before you make a large investment.

However, sometimes having low turnaround times is more valuable. In these cases, running steps in parallel can really help. Vanguard, for example, took this approach when it was brought in by a borough council that was trying to reduce the time taken to train nursery school teachers. The training process looked like this:

The CRB (Criminal Records Bureau) checks were being performed before the training for good reasons. The council didn't want to waste time and money training the wrong people, and there were concerns about child safety during the training.

But when they questioned these assumptions, they realised that in fact only a tiny percentage of applicants failed the background checks and, although the training involved children, the applicants were fully supervised at all times, so the risk was negligible.

They redesigned the process to run the CRB checks in parallel with the training and found they didn't need to make any other changes as this change alone brought them well within their targetted performance level.

Seeing progress is motivating

There's always this question of what to do with the Kanban cards once you've finished with them – once features have made it all the way across the board and been deployed into production. What do you do with the cards? Do you throw them away? Do you keep them as souvenirs? Do you pile them up? What do you do with them?

I recommend keeping them. Not just keeping them, but putting them on display. It's a real motivator – a visual reminder of the progress you've made. And it's not just you it helps, it also reassures the sponsors and helps them appreciate what you've done. Even though they can see the software as it evolves, it's easy to forget all the work that's gone into it. Seeing the cards reinforces the point. This is my experience anyway. So, my recommendation is keep the cards as long as possible and keep them as visible as possible.

Obviously you don't want to clutter up the board, so maybe you want to move them onto the wall or somewhere nearby but make sure you don't throw them away. They're important.

Who can adopt Kanban?

One of the best things about Kanban is the low barrier to adoption. You don't have to be practising Scrum or XP or be certified at CMM Level 5. The columns on your Kanban board could be as simple as: "To Do", "Doing", and "Done".

You're in good enough shape to start using Kanban if you can (manually or otherwise):

If you can't do those — and many teams can't — then you probably have more important things to worry about than setting up a Kanban board.

Buffer your bottlenecks

Since the bottleneck is so critical, one of the things we want to do is make sure that it rarely (preferably never) runs out of work. You might wonder how a bottleneck can run dry, when, by definition, it is fed by a wider pipe? The thing to remember is that in our kanban system we're purposely limiting work-in-progress (WIP), and work items vary in size; so a couple of large items being processed upstream could end up temporarily starving the bottleneck.

The solution is to place a buffer in front of the bottleneck, as per the diagram below. In this example, the development team is the bottleneck so a buffer with a limit of 3 work items has been inserted immediately before it (the numbers at the top of the columns are the limits).

How do you size the buffer?
Each extra item of WIP carries a penalty in terms of lead time, so start with a small number and adjust it up or down empirically. Another thing you might consider is breaking up larger work items into smaller items, or the opposite – bringing together several small items to form larger items. Reducing the variability in size of the work items may allow you to reduce the size of the buffer.

How many buffers do we need?
Strictly speaking, at any point in time, there can only be one bottleneck in the pipeline. However, when you have variation – not just in terms of the size of work items, but in terms of the type of work and the people involved – the bottleneck may move from time to time. After a while of running the kanban system you'll get a feel for where the bottlenecks most commonly appear. Place your buffers appropriately.

Cracking the WIP

Limiting work-in-progress can be a bit annoying to start with, but you have to think of the consequences — being confronted with issues when they're small saves you from a much larger pain in the future. Like brushing your teeth, once you get in the habit, it's no big deal.

WIP is like inventory in a warehouse: the more you carry, the further you are from the market and the harder it is to respond to change. Business value is often dramatically affected by time - if your Christmas campaign isn't released until January, you've missed the opportunity. The lead-time on new features can make the difference between dominating the market or constantly playing catch-up.

Without specific policies to limit WIP, people will naturally tend to multi-task. Non-bottlenecks will start new tasks whenever they're waiting for a bottleneck to complete. The effect is a continually growing pile of partially-completed work. Since the bottleneck limits the throughput of the system, the extra WIP doesn't actually result in more throughput; it just pushes up lead-times.

I'm not saying that all multi-tasking should be eliminated. You have to be able to put something on the back-burner every now and then to let the subconscious mind think about it, or ask someone a quick question and expect a quick reply. But uncontrolled multi-tasking can do a lot of damage.

Kanban lets you strike the right balance: limiting the amount of WIP to a point that is comfortable but not out of hand. How tightly you can squeeze the limits depends on the maturity of the team.

To begin with, it can be frustrating to have to wait on the bottleneck before you can continue to the next piece of work, or to have to justify why some piece of work must be expedited. But this frustration is the thing that drives improvement. Issues like these need to be addressed, and Kanban prods you to address them sooner, rather than later when it will really hurt.

Time at the bottleneck is what counts

Which of these feature ideas should we select?

Feature Estimated
Production Time
A $100,000 40 hrs
B $80,000 40 hrs
C $60,000 40 hrs

Feature A? It's a no-brainer, right?

Not necessarily. The Theory of Constraints tells us that the overall throughput of our production pipeline is limited by the throughput of the bottleneck. That means if we want to squeeze as much value through our pipeline as possible we have to squeeze as much value through the bottleneck as possible. So what's important isn't the total time, but the time that each of the features takes at the bottleneck.

Feature Estimated
At the
Away from the
Production Time
A $100,000 20 hrs 20 hrs 40 hrs
B $80,000 10 hrs 30 hrs 40 hrs
C $60,000 10 hrs 30 hrs 40 hrs

In this case, for the same 20 hours at the bottleneck we can produce both B and C for a total of $140,000, compared with A at $100,000.

If you're not convinced, imagine the following scenario: You have 100 business analysts, 100 developers and 1 tester. All the work has to be tested by the tester. The tester is the bottleneck and everyone else spends most of their day sat around twiddling their thumbs. Obviously we want to do everything we can to off-load tasks from the tester onto other people. This is effectively what features B and C do, compared with A, because they require less time with the tester.

Curve your Enthusiasm

What can you do to help people persist with a change? This graph from Ray Immelman is brilliant. The fact it's over-simplified doesn't matter because there's enough intuitive truth in it to be convincing.

Before you introduce a change, show this graph to everyone involved. And when the initial enthusiasm drops, and people start to have second thoughts, pull out the graph again.

Enthusiasm curve
First Peak "OK, let's give it a whirl!"
First Trough "It's harder than it looks."
Second Peak "It seems to be working!"
Second Trough "We're reaching the point of no return. Do we really want to do this forever?"
High Enthusiasm "Hey, we're starting to get really good at this."