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.
The IT Risk Manager 
February 11th, 2014 at 10:39 pm
Staff liquidity increases the number of choices about the work you do next, not the amount of work you take on. If some skills are limited to a small number of team members and those team members are tied up, I can’t choose to take on any work that requires those skills. So the scarcity of skills, or rather, the distribution of those skills among the team, limits the options available for which work the team can take on next.
It is possible, and in many cases quite likely, that these will coincide: the more valuable or urgent or high priority work requires the scarcer skills. As well as reserving the people with the broader skills to deploy later, you could proactively engage in skills and knowledge transfer within the team, to adapt the skills distribution to better suit the anticipated work. Of course this presupposes you can know what kind of work is coming down the pipe.
February 12th, 2014 at 8:07 am
Dan
OK, I’ll admit it. I’m jealous. You write more clearly about this stuff than I do.
In terms of managing the pipeline, I like the concept of a Tornado Graphas introduced by Todd Little ( ww.toddlittleweb.com ). Implementation is pretty straight forward.
1. Get the “team” to create a liquidity matrix.. (Skills versus people, self scored matrix).
2. Get the Product Owner to present a Tornado Graph of what is in the pipeline. One month with high degree of certainty / Three Month with less certainty / Six to Twelve month with little certainty.
3. Teams map items in Tornado Graph to Matrix, add new skills as required.
4. Team identify gaps.
5. Teams manage the process of filling the gaps in the matrix (Deliberate skills transfer and acquisition.
February 12th, 2014 at 8:29 am
That’s almost exactly what I just proposed to one of my clients. I didn’t know it had a name! Thanks for that. As for writing, I was just playing back what I got from your article to make sure I’d got it right. I thought you made it pretty clear.
Do you have a reference for Todd’s process?
February 12th, 2014 at 9:41 pm
Todd doesn’t have a process. He just references tornado charts in his risk presentations. There used to be one on Vimeo from LKNA but I cannot find it.
February 12th, 2014 at 6:15 am
Chris, can you please advice if I got the concept of Staff Liquidity?
While many Kanban practitioners worry about how to manage the variability in the work items, the greater source of variability is to be found in the people doing the work.
Here comes the Staff Liquidity concept where we assign the work not to the best people but to the average people that could barely do it.
The most versatile and capable people are left to float around and should not be allocated to any other tasks. So if a problem comes up, they are immediately available to address it. At the same time since they are not committed to a work item no work item will be late.
From TOC perspective using Staff Liquidity we build a capacity buffer ready to cover the special cause variations in the work process.
That in fact means we follow the Five Focusing Steps advocated by TOC:
1) We have identified the system constraint – the average people that could barely do the work. They are able to absorb the common cause variation in the work items.
2) We decided how to exploit the system constraint – we focus on keeping the constraint as busy as possible by giving the average people work they could barely do.
3) We subordinate everything else to the constraint – the most capable people are not the ones doing the work.
4) We elevate the system constraint – by training the average people that could barely do the work. At the same time we train the best people as well in order to ensure that the system constraint (in this case the average people) will not move.
5) We return to Step 1 and don’t let inertia create a new system constraint.
http://dimiterbak.blogspot.com/2013/06/staff-liquidity-explained-using-toc.html
February 12th, 2014 at 10:16 pm
Dimiter
I love this way of expressing staff liquidity. I will think about it over the next couple of days and give you feedback.
Chris