I attended an interesting talk by Dan Vacanti last week at the monthly Agile New England meeting. (I missed him at LSSC '12 last month.) He dove into Little's Law - in a talk titled Little's Flaw - with an emphasis on understanding the assumptions underlying the law and the desire to NOT misuse it. The discussion went in several directions, as the audience were fairly engaged with what he had to say - he probably could have spent another hour with the audience, given the interest level.
The law can be written several ways, but here is the one Vacanti used in the discussion:
Avg (Lead Time) = Avg (Work In Process) / Avg (Output)
The short form of the argument is that Little's Law is deceptively simple. There are no requirements about the distribution of the quantities, nor about the size of the items, nor about how many people are working on an item. However, the law DOES require that the system be relatively stable over the period being measured AND that the average rate of incoming work be balanced with the rate of outgoing work (no accumulation or consumption). Oh, and don't forget to use consistent units - this is an obvious one from my engineering training, but Vacanti sees the mistake frequently enough to call it out.
Vacanti fit the discussion of Little's Law into its use in Kanban. The thing that most perked my interest was around using Cumulative Flow Diagrams (CFD). Vacanti was adamant that Kanban isn't as powerful if you just focus on the wall of cards. He sees CFD charts being particularly helpful in the "make policies explicit" and "manage flow" principles of Kanban. CFD can help you see things that you may not be able to see on the card wall. Or you can see things in a different way. (Here's a blog that describes CFDs in Kanban. It's also the source for this image. There are many other discussions as well.)
I liked his deconstruction of a CFD in terms of Little's Law - and in conjunction with the assumptions described above. For example, one of the key assumptions is that the rate of incoming and outgoing items should be approximately the same. You can see whether this holds true immediately on a CFD, as the slope of the "done" line at the bottom of the CFD should be about the same as the slope of the "ready" line at the top. (Note that this "ready" column doesn't include the backlog of ideas or possibilities - that's a different discussion.) Other elements of a CFD: a vertical line gives you the WIP; a horizontal line tells you the Lead Time; slope of "done" is your system's Output (often called throughput); and the slope of the top line is the arrival rate. Given that, it is easy to convert into the Little's Law relationship: when WIP is small, the Lead Time tends to be small. When WIP grows, the Lead Time increases as well.
The other nice thing about the CFD is that, given the assumptions, it is a predictive tool. If the level of WIP starts to go up, the Lead Time is sure to increase, unless other factors change (for example, you've hired more people and can get more out the door in the same time frame). I also liked the comments he made about predictability:
"Predictability does NOT mean (the system is) deterministic."
"You can get predictability through having explicit policies AND honoring those policies."
Diverging from the discussion last week: This issue of balancing the active work with the demands on the system comes up in portfolio management. I've said many times that just because you have a great idea, doesn't mean you should start working on it. This discussion is another demonstration of that. Jamming more work into the system merely serves to slow down the entire system. Sure, something will come out eventually, but what will it be? And do your customers want it?
Here is Dan Vacanti's blog entry on the subject from earlier in the year, Little's Flaw - Part I, if you want to get a better sense of what he said, as opposed to my interpretation.
[CFD image from the blog entry by Michael Dubakov.]