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.
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.
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.
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):
Check out the code from a source code control system
Build the code
Check it works
Deploy it
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.
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.
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.
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 Value
At the Bottleneck
Away from the Bottleneck
Total 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.
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.
"OK, let's give it a whirl!"
"It's harder than it looks."
"It seems to be working!"
"We're reaching the point of no return. Do we really want to do this forever?"
