There are different reasons why limiting the work in progress (WIP limit) is a good thing, but now I would like to talk about one special case where WIP limits are helping move things forward. Let’s assume that you have a working pull system which means that the team members don’t push the work on others, but others can take the work if they are capable to handle them (I’m not using the word free on purpose because what if somebody can work on two things in parallel). Check out the following setup. How many pulls do the team have to do in order to get one work item done?
It takes 21 pulls to have one item done: you pull each work item into each phase one by one and when you run out of pulls you start with the next phase. You can see that in this situation that the actual WIP limit always equals to the number of work items in the system. However, if you have WIP limits the situation is different. With the WIP limit of one you need only 5 pulls but you may have idle work items and idle team members. This is not good either.
The solution is the harmony of the better capability utilisation and the short cycles. Better capability utilisation doesn’t mean that you want all the employees to provide 100% all the time (I suggest lower utilisation time), but you want the team members to work where they are the best or where they need to be. Unless, of course, there is a phase where your capability is low. This is where the shorter cycles kick in. In phases where the capability is low, the lead time will be high due to waiting or slow progress, so you may want to reconsider to make people learn new skills, and therefore be able to work in different phases. This will reduce the cycles because the capability will go up in the phase where it was low before, but it will decrease somewhere else because of the capability withdrawal.
In Kanban we use Chris Matts’ staff liquidity for capability utilitisation and lead time for checking the size of the cycles. Staff liquidity is actually a matrix which tells us the skill level of team members in the different phases. Here is an example:
As you can see the guy on the top is very good at testing (level 3), however he is not really good at development, but has an idea of how to do it (level 1). Moreover, you can see that there is another team member who is good at testing (level 2) which means that it is safe to say that the WIP limit on testing must be 2. If the limit is lower than 2, there is a chance that one person will be idle. If it is higher than 2, we have the no limit situation again: items won’t be pulled until the phase is full which actually means that there may be items that waiting more than they have to.
In Kanban we use lead time and flow efficiency to measure the cycles. Check out this lead time histogram:
And the flow efficiency:
It shows that the team can deliver a work item in 10 days (checkout this post why), but the flow efficiency (ratio between waiting and working) is 5% which is very low: the work items are in an idle state for 95% of their livecycle which is 9.5 days in this case. So, they should figure out in which phase they are waiting the most; probably where their capability is low. And we ended up at staff liquidity again. This is a nice cycle: lead time -> staff liquidity -> lead time -> staff liquidity etc, which is implemented with WIP limits and that’s why WIP limits are important: they are tools of controlling and fine tuning your system.
comments powered by Disqus