Zsolt Fabok, a good friend of mine, has written a blog post responding to a talk I gave where I said “Explicit WIP Limits destroy options”. Before I respond, there are a couple of inaccuracies in the post that I want to call out.
- In the video I said that “Explicit WIP limits destroy options”. I did not say that “WIP limits destroy options”. This is a subtle but significant difference. It is possible that Zsolt misheard what I say in the video. Instead of “Explicit WIP limits”, I advocate the use of WIP limiting policies.
- Zsolt says “In this context it means that “the more liquid our staff” the more work items we can work on in parallel, which means that we have more options.” This is a misunderstanding of Staff Liquidity. Staff Liquidity is about the number of types of task that a team member can work on. It has nothing to do with working on things in parallel. This misunderstanding may be based on another misguided definition of staff liquidity that is based on the number of transactions in a system. (The number of transactions is a measure of system activity, not liquidity.)
Point 1 completely undermines the argument made in Zsolt post. Typical WIP limiting policies would be no more than one EPIC (unit of delivery of value) in progress, and no team member/pair should work on more than one task at a time (Blocked tasks should be marked as such). It is vital that everyone on the team knows the value of limiting WIP.
“Explicit WIP limited systems”, or Kanban systems as they are known, destroy options for the person managing risk in the system. The problem is that this coercive management technique (not necessarily the manager*) dictate the next task that a team member should take in certain circumstances. Given the WIP limit for the “waiting for test” queue is three and the queue currently has two items in it, when someone finishes a development task, then they know that the next task they should take is a testing task. Given that they do not like testing, when this happens, then they might do other stuff until someone else finishes, takes the testing task and then they will take the next development task.
The limits force behaviour. Without the limits, team members pick the tasks that they want to. Making this visible makes it easier to identify people who do not want to perform certain roles. This can lead to a discussion to see if they need further training or they disagree with WIP limits. This is a very important option for the person(s) managing the system, as it shows whether all the team members understand and support the approach.
To be clear, having more WIP reduces options. A smaller WIP increases options. Creating a system with lower WIP and no waste (i.e. where effective swarming takes place) is not a simple task.
Zsolt has been nominated for Kanban Community’s Brickell Quay Award. Please vote for him. :-)
*Sometimes enthusiastic team members can force an approach on other passive members who are not aware of the consequences.