Right now I’m doing a lot of education and presentations. I find
that the doesn’t supply me with as much blogging material sadly. But I
have had a small nagging thought about a blog post I feel needs to be
written. Here it is:
There’s a lot of buzz around
Kanban as you
sure know and one way you really see that is that a lot of teams are
taking up Kanban… and sadly misuse it. Just as with many other
methodologies I think that people interpret what they think is correct
without really taking the time to learn the theory behind it. I have a
hunch that we will hear about Kan-but in the near future.
This is both sad and very strange as well; Kanban
in itself is really supersimple. In fact you could sum it up as
Janice Linden-Reed does on the excellent
www.Kanban101.com site:
Yes – in fact those simple rules are a good summation of the basics of
Kanban. And still there are, quite a few, implementation that doesn’t do
all of these. The most common mistake I’ve seen is not limiting
WIP.
What is WIP?
WIP or Work in Process (the term I prefer) simply means the amount of work you and your team does at the same time. It’s a core concept of Lean and Kanban and you want to limit the amount of work that is in progress at the same time.
Why should I limit WIP?
So why should I do that? What good comes from having less work going on at the same time? Well – you can say a lot about this but a very basic thing is that with less stuff going on at the same time each item will take shorter time to complete, according to a mathematical law called Little’s Law. So less stuff going on at the same time will improve our lead time or time through the whole process. (In fact it may just improve our cycle time, which is the time in our process, if the complete lead time is affected by other parts of the process than ours. But that just advanced stuff, don’t you think :)). And if the lead time is improve we gain a lot of stuff; not only can items be taken into production earlier but also does it make us less sensitive for risk, more agile and flexible. Finally it builds trust with our stakeholders as small items being completed often and with predictability is, for the most part, actually valued above speed. There’s a lot more to say on why you should limit WIP, but hey this is a blog post and not a book, right? Read here and here if you want to learn more.
So how much WIP should I allow then?
Aha – the big question! How much is enough? The first thing to understand is that limiting WIP is a policy that we as a team take upon ourselves. It cannot (or at least shouldn’t) be enforced up us be somebody else. A bit like Scrum, where we let the team pick from the product backlog how much they think the manage to complete during the next sprint. So we want to let the team limit the work to their capacity. For sheer numbers there are loads of strategies:
- 2 for each person so you can start with something else if you get stuck
- 1 per person so you are forced to help each other when you get stuck
- # of persons divided by 2 to get a real focus on collaboration
- Start with what you think is the bottleneck. For example just limit WIP for the 2 testers to maybe 4 items and let the rest of the team adjust to that limitation.
- Any old number and change it as needed
In any case; you want a low WIP limit but not 1. If you set it to 1
then it means that even the slightest disturbance in the force in
your flow will be completely stopped. You probably don’t want that.
Why is WIP not limited in many cases?
So if Kanban is those 3 simple rules above – why doesn’t they get implemented? Are we really that lazy? Eeeeeh – well no …. but I think that it has to do with no understanding the function of the WIP limit as well as who “owns” it and can change it. For example many Scrum teams feel the need to ditch iterations as their work doesn’t fit into iterations. For example with a lot of urgent items being thrown into the sprint and wrecking the planning. So iterations are dropped but when doing that you don’t put in another policy to limit your work. Pretty soon the board is crowded with stickies, you lose track of your work and your lead times increase. It’s about here that you start to feel that the board isn’t helping you and people start to have “private backlogs”. In other cases people simply start to use a board. They might not even think about limiting work in any case. So what happens is (and I’ve seen this to many times) that a board with a myriad of stickies is created and just hangs there. It’s really sad to see a capable visualization tool like a board not being used or just drowning under the load of the stickies. With no WIP limit in place you are simply showing everybody how much work you are doing at the same time. It’s seldom flattering as we know (as a mathematical fact) that a lot of simultaneous work also mean slower progress through your value stream.
Conclusion
Kanban is really simple:
- Visualize work – by the help of a board for example
- Limit Work in process in some way
- Help work to flow – manage the problems that occurs and make the items move fast through your process.
That’s it! Don’t take any stuff out. Kanban is so small it cannot even become Kanbut. It will be just “but”. Remember that limiting Work in Process is your way to control the amount of work you are taking on, and the speed with which work flows through your process. You (and your team) owns that policy – you are allowed to change it. Don’t just display the amount of work you are doing to the world – limit WIP and improve the lead time for it.