One of things you can hear repeatedly from me is why we should limit work in progress (WIP) and how it drives continuous improvement. What’s more, I usually advise using rather aggressive WIP limits. The point is that you should generate enough slack time to create space and incentive for improvements.
In other words, the goal is to make people not doing project or product development work quite frequently. Only then, freed from being busy with regular stuff, they can improve the system which they’re part of.
The part which I was paying little attention to was the cost of introducing slack time. After all, these are very rare occasions when clients pay us for improvement work, so this is some sort of investment that doesn’t come for free.
This is why Don Reinertsen’s sessions during Lean Kanban Europe Tour felt, at first, so unaligned with my experience. Don advises to start with WIP limits twice as big as average WIP in the system. This means you barely generate any slack at all. What the heck?
Let’s start with a handful of numbers. Don Reinertsen points that WIP limit which is twice as big as average WIP, when compared to no WIP limit at all, ends up with only 1% idle time more and only 1% rejected work. As a result we get 28% improvement in average cycle time. Quite an impressive change for a very small price. Unfortunately, down the road, we pay more and more for further improvements in cycle time, thus the question: how far should we drive WIP limits?
The further we go the more frequently we have idle time, thus we waste more money. Or do we? Actually, we are doing it on purpose. Introducing slack to the system creates an opportunity to improve. It’s not really idle time.
Instead of comparing value of project or product work to idle time we should compare it to value of improvement work. The price we pay isn’t that high as it would initially seem basing simply on queuing theory.
Well, almost. If we look at the situation within strict borders of a single project value of improvement work is non-existent or intangible at best. How much better will the product be or how much faster will we build remaining features? You don’t know. So you can’t say how much value these improvements will add to the project.
However, saying that the improvements are of no value would be looking from a perspective of optimizing a part; in this case a single project. Often impact of such improvements will be broader than within borders of the project and it will last longer than the project’s time span.
I don’t say I have a method you may use to evaluate cost and value attached to non-project work. If I had I’d probably be a published author by now, had lots of grey hair and a beer belly twice as big. My point is that you definitely shouldn’t account all non-project work as waste. Actually, most of the time cost of this work will be smaller than value you get out of it.
If we based purely on Don Reinertsen’s data and assumed that whenever we hit WIP limit people are idle we could come up with such a chart:
On a horizontal axis we have WIP limits going from infinite (no WIP limit at all) to aggressive WIP limits inflicting much slack time. On a vertical axis we have overall impact on a system. As we introduce WIP limits (we go to the right side of the chart) we gain value thanks to shorter average cycle times and, at least at the beginning, improved throughput. At the same time we pay the cost of delay of rejected or queued work waiting to enter the system (in backlog) and the cost of idle time.
In this case we reach the peak point of the curve pretty quickly, which means that we get most value with rather loose WIP limits. We don’t want to introduce too much idle time to the system as it’s our liability.
However, if we start thinking in terms of slack time, not idle time, and assume that we are able to produce enough value during slack time to compensate the cost the chart will be much different.
In the case number two the only factor working against us is cost of delay of work we can’t start because of WIP limits. The organization still has to pay for people doing non-project work, but we base on assumption that they create equal value during slack time.
The peak of the curve is further to the right, which means that the best possible impact happens when we use more aggressive WIP limits than in the first case.
Personally, I’d go even further. Basing on my past experience I’d speculate that often slack time results in improvements that have positive overall impact on the organization. In other words it would be quite a good idea to fund them as projects as they simply bring or save money. It gives us another scenario.
In this case impact of slack time is positive so it partially compensates increasing cost of delay, as we block more items to enter the system. Eventually, of course, overall impact is negative in each case as at the end of horizontal axis we’d have WIP limit of 0, which would mean infinite cost of delay.
Anyway, the more interesting point to look at is the peak of each curve, as this is a sweet spot for our WIP limits. And this is something we should be looking for.
I guess, by this time you’ve already noticed that there are no numbers on the charts. Obviously, there can’t be any. Specific WIP limits would depend on a number of context-dependent factors, like a team size, process complexity or external dependencies, to mention only the most obvious ones.
The shape of curves will depend on the context as well. Depending on the work you do cost of delay can have different impact, same as value of improvements will differ. Not to mention that cost attached to slack time vary as well.
What I’m trying to show here is that introducing WIP limits isn’t just a simple equation. It’s not without a reason that no credible person would simply give you a number as an answer for a question about WIP limits. You just have to find out by yourself.
By the way, the whole background I drew here is also an answer for the question why my experience seemed so unaligned with ideas shared by Don Reinertsen. I just usually see quite a lot value gained thanks to wise use of slack time. And slack time, by all means, should be accounted differently than idle time.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
2 comments… add one
Interesting. I too in an ideal world, would prefer aggressive WIP limits that actually get hit, and result in slack. Although the effects of WIP limits, like swarming or slack can be very hard for most organisations to accept. Aggressive limits can quickly cause problems significant enough to encourage cheating against, or blatantly rejecting Kanban.
I liked Don’s idea of starting at 2x the average. I used the average, to help smooth out a process with lots of batching in it, and I think it was too aggressive for the organisation. 2x would have been better, and then slowly letting it drop as the understanding of WIP limits and slack grew.
Another interesting point is that you compare slack time and idle time. I usually considered idle time as something that related to work rather than people. When is a “card” not being worked on for example.
Using your definition though, I would equate the two. When a WIP limit is hit I think it is ok to simply go idle. I like that tweet that was going around a few days ago, “just sit there and read a book”. Swarming and process improvement would probably be better, if possible, but once you establish that slack time should be productive you start a slippery slope. Most people would probably just use their slack time to start “preparing for the next work item”, i.e. starting it without pulling it, i.e. cheating against Kanban. I think the best use of slack time is to prevent people from pushing work into parts of a system that don’t have the capacity to accept it. Ideas like swarming and process improvement are good to sell the ideas of WIP limits and true slack to managers that don’t yet accept that 100% utilisation is suboptimal.
(Just to clarify, I think swarming and process improvement are useful, but swarming I think should be a decision that happens before the decision to pull i.e. first look at the board to see what you can help with, then if there is nothing you can help with, see if you can pull. As far as process improvement goes, I think this should happen whenever the need for it arises. Hitting a WIP limit does not always suggest some process improvement is needed, and I doubt the correct improvement is something that would occur to someone just because they hit a WIP limit, and is unlikely something they can simply change during an hour or two of slack).
Something also doesn’t feel right about the way you are looking at individuals and whether they are doing “productive project work” or otherwise “adding value”. Lets just look at the team and not worry about which individuals are utilised more than others. It is old style thinking to see an employee who only books 10% of his time to projects as a liability. Maybe that 10% is appropriate. And it is not that 10% you are paying for anyway, it is his experience, skills etc, in the context of the team.
Its like that old joke about the plumber who charged $1000 to turn a tap. $5 was for turning the tap, the other $995 was for knowing which tap to turn. You would pay him a full salary if he only spent 10% of his time turning taps, and 90% of the time reading a book, provided that his tap-turning was valuable enough to justify his salary. Heck, who can turn taps all day anyway?
Worrying about whether developers are productive in their slack time betrays a cost-oriented thinking approach.
@Kurt – Thanks for a comment. It wasn’t my intention to encourage cost-counting perspective on WIP limits. Actually, I assume that people decide by themselves what they should do with their slack time. And yes, most likely they will first look for blockers they can to solve or work items they can to swarm over. They may choose to be idle too. Still, perfectly fair for me.
The thing I’m surprised about, when reading reactions to the post, is that many still assume that people having slack time would use it in unproductive way. I trust people. Vast majority of the will use this time in a best way, given their understanding of work. Obviously we could bring the argument about how well they understand work, but it is a different discussion.
Anyway, no matter whether they choose to swarm over a problem, help to solve blocked item, learn or work on system improvements, each of these activities is valuable for the company. It shouldn’t be treated simply as idle time. So the argument remains valid.
Another question is whether aggressive WIP limits discourage people to use Kanban. This is a valid question, and if you move far enough that application of the method discourage people to use it I’d advice to take a step back–here: make WIP limits less restrictive. I would, however, say that limit of 2x average WIP is so high that it barely makes people notice there is such a thing.
Finally, I don’t try, or encourage, to count impact of WIP limits in dollars. I just try to show that there is value, sometimes pretty significant, in wise use of slack time. So basically, I’m rather discouraging oversimplified cost counting than encouraging it. Or this was my intention.