Simulating The Benefits Of WIP Management
We talk about the benefits of limiting, or more appropriately managing, WIP all the time in Lean and Agile circles, but I think it can be get people and teams to buy into the concept. The problem, in my opinion, is that there is always a lag, and sometimes a significant one, between implementation and realization of the benefits. Even with evidence from past efforts in other organizations or case studies there can be a healthy dose of skepticism that these principles will work. You hear things like “Yes, we understand what you are saying, but our company is very different from other companies you have mentioned”. Thus you are effectively asking folks to take a leap of faith. That can be a tall order.
To make this somewhat less of a hurdle I have started using simulation to demonstrate how and why the principles work. The biggest benefit of using a simulation is that you can speed it up so the impact of making changes can be visualized in real time. Simulations also provide a way of demonstrating bottom-line impact that is normally more difficult to do in the real world. For example when you can model how profitability can be increased by actually adding people rather than cutting people you have a much better chance of decision makers considering it seriously vs. if you just discussed it conceptually.
I have used a couple of different simulation tools with decent success. Both are free online tools that are relatively simple to use and do a very nice job of visualizing flow:
Kanban Flow Simulator by Mateusz Gajdzik
I use both of them depending on the audience and what I am trying to demonstrate. Boiling it down, if I want something really simple that demonstrates bottom line impact I like the FLOWer simulator. If I want more control over the model, the process flow, and something a bit more robust I like the KFS simulator. Here is high level walk through of a talk I did last week with some of the teams I am working with using the FLOWer simulator.
Set The Stage — First I set the stage and describe the scenario we are simulating:
- Simple work flow of Ready->Development->Testing->Done
- 4 Devs, 2 Testers
- Up to 3 items can be expedited at once
- Effectively no WIP limits
- Item effort ranges from 4 to 20 days
- I note that this scenario isn’t terribly dissimilar to theirs
- I provide a brief background on how the model works so it isn’t perceived as a bunch of voodoo
Scenario 1: Baseline- I run the simulation with the inputs above to demonstrate what it looks like with no WIP management. The simulation does not produce the same result each time so I run it 4 or 5 times for each scenario taking the low and high results. I note that in the first scenario our cycle times are all over the map ranging from 100 to 350 days. Our earnings are in the red ranging from -$300K to -$100K
Scenario 2: Add WIP Limits- Next, I add WIP limits of 5, 10, and 8 on the Ready, Development, and Testing respectively and run the simulation another 4 to 5 times. I note that there is still quite a variance in our cycle times, but the range is much smaller between 40 and 150. Our earnings are now in the black ranging from $50K to $210K. I also note the high utilization level
Scenario 3: Eliminate Expedites- Now we eliminate expedited issues and see that cycle times now range between 40 and 125 days. Our earnings have jumped to $140K to $1.3M. I mention that expedited issues can be deceiving in that on the surface it appears you might be doing the most valuable thing possible, but when you have high numbers of expedited issues they take a significant toll on the value of your WIP
Scenario 4: Add Testers- Next we add two additional testers to the team keeping everything else the same. After running the sims we see that our cycle times are dropped further averaging somewhere around 80 days and our earnings ranging between $900K and $2M. The aspect I really enjoy noting is that the utilization level of the testers has gone down significantly yet we are making even more profit. I have found the notion of team members being anything less that 100% utilized is one of the tougher things for people to buy into
Scenario 5: Reduce Item Size- The fifth step is to focus on the reducing the range of the size of our items. I change the item size range to 4 to 10 days. By slicing our value up smaller we get value delivered sooner and less time lost to context switching when items get blocked. Our cycle times continue to drop like stones in water and our earnings range is up to $1.4M and $2.3M
Scenario 6: Max It Out- Finally I max out the number of Devs to 10 and Testers to 8. I drop the item range down to 1 to 3 days. Then I increase the WIP limits of the three statuses to 6, 16, and 10. I note to the group that managing WIP doesn’t always mean reducing WIP. In this case we increase the number of team members to the point where there would the existing WIP limits would constrain the team too much. Work is not infinitely divisible and the team is only capable of swarming so much on any given item. We run the simulation and see that our cycle times are now consistently about about 10 days and our earnings range from $4.1M to $7.7M. This scenario may not necessarily be realistic, but it still illustrates the point that these principles can have a profound impact
Summing it all up this is what our scenario progression looks like graphed out
I am very conscious when discussing the simulations to point out that there are a lot of assumptions in the model and that every situation is different. For instance, if a team is heavily specialized with very little cross-skilled team members the benefits of WIP limits and swarming likely won’t have the kind of impact we see in the simulation. In fact they could make things worse. That however is why making these kinds of changes often requires work, innovation, creativity, and patience. The key is to understand their particular situation and where they can get the most bang for the buck to start and what things will require longer term efforts. I like to finish up by pointing out where they might have already realized some of the benefits to help connect the dots. You can see in the image below a noticeable drop in cycle times around 10/1.
I hope you found this informative and useful. I would love to hear your feedback and suggestions as to how this could be made even better.
