The Work In Progress limit (WIP limit from now on) is one of the most powerful but counter-intuitive concepts I had the fortune to encounter in my work life.
When suggesting teams to introduce a WIP limit to their boards, I hear objections like “are you saying that doing less things at the same time is going to make you faster? You must be wrong? If I start 10 things I’ll finish earlier than if I can only do 2 at the same time!”
or “Working on one thing at the time only? That’s NOT efficient!”
It is indeed a counter intuitive concept, proven by the fact that most people object to it based on common sense.
You might say, why don’t you explain the reasons behind the value of WIP?
Don’t get me wrong, I am familiar with queuing theory, Little’s law and the relation between resource utilization and queue size, but these concepts are not something that can be explained easily every time that the objections are brought forward. Funnily enough, explaining them, is not really efficient.
I have been helping teams use Kanban and the Kanban method for a while now and I have used different approaches around WIP limits to identify the one that gives the best results for the teams.
I have come to the conclusion that the most efficient way to go about this is by (I hate the word) imposing the WIP limit at the very beginning of the adoption, as part of Shu in the Shu Ha Ri learning pattern.
The great thing about having a WIP limit is that it gives strong signals to the team
- What’s the most important problem we have to solve now?
- What’s the highest risk our kanban board is telling us about?
If your board has a WIP limit you will have to answer the questions and act, if you don’t have one, you can always pick the easy cop out of taking a new less important task. The questions posed by the WIP limit are uncomfortable ones, they won’t allow the team to take the easy option. That’s why I believe that teams will benefit from having them since day one.
I have seen WIP limits cause turmoil in teams, people initially feel uneasy. I believe, the feeling derives from the fact that team members don’t believe yet WIP limits will work, and this is due to their aforementioned counter-intuitive nature.
Eventually teams will internalise the fact that WIP limits help the team focus on delivering instead of retreating to more comfortable, less valuable tasks and it does indeed improve flow. But that’s after a while.
My point is, that if we don’t impose the limit at the beginning, the team might not get there on their own.
As I said before I tried many different coaching approaches, the one that worked for me better so far is this:
- A session with the team in which I go into the details of the mathematical reasons why WIP limits improve flow (most people won’t believe everything but will have some context and hopefully some curiosity)
- Get the team started with a system that includes a WIP limit initially set by me and low enough to be uncomfortable (see above)
- Attend team’s standups, to discourage breaking WIP and ask the difficult questions I mention above if the team is not able yet to read them from the board
- Facilitate a retrospective after 2 weeks of use and have a conversation around whether the limit is too low or too high
What was your coaching experience? Can you share alternative paths?
| Reference: | What I learned about helping teams use WIP limits from our JCG partner Augusto Evangelisti at the mysoftwarequality blog. |
