Playing with Little‘s Law

Little’s Law, as we use it in Kanban, states a relationship between average Lead Time, average Throughput and average Work in Progress.

The original formula comes from queuing theory and looks like this:  

L = λ x W

L is the average number of items in a queuing system.

λ is the average number of items arriving into the queuing system over some unit of time

W is the average time a work item spends overall in the queuing system

If we transfer the formula into knowledge work, there are some interesting implications we have to consider. For example: Did you know that Little’s Law only holds true in a stable system where we have Conservation of Flow? This means that every work unit passes the whole system and that the average arrival rate of work equals the average departure rate. I strongly recommend Frank Vega’s great Blog Post Little’s Law: Isn’t ita Linear Relationship? on this topic! My main takeway from Frank’s article is that we need to dig a little bit deeper into the topic before we start calculating lead times according to Little’s Law.

But besides this calculations (at the Advanced Kanban Metrics Tutorial in Boston we called this „The Fancy Stuff“), there are some other interesting things we can use Little’s Law for. For example: discussion!

Here are some examples of fruitful discussions I had with different teams over the last couple of months. This is the variant of Little’s Law which I use (and which is probably most common within the Kanban community):

The first interesting thing here is: If we want to shorten Lead Times (and who does not want to do this?), we have two choices: We can either increase Throughput or decrease the Work in Progress (WIP). This ist trivial, right? But as soon as we make people think about the measures they typically take to shorten lead times, we will probably discover something interesting: Most of them are on the Throughput side. Hiring additional staff, making people work overtime, buying better tools, building frameworks, yelling at people...All these means are quite common in our industry – and they all try to increase the Throughput. But do they work well? In most cases: No! There are different reasons behind this. One is Brooke’s Law. Another one might be that most of these measures lead to a deep J-Curve, meaning it gets much worse before it gets better. So instead of trying harder and harder to increase Throughput, perhaps we should have a look at the numerator of the equation: Work in Progress. If we manage to decrease the WIP, this would lead to shorter lead times. The simpliest way for doing so is to establish a new policy that states: „We as a team agree that we do not want to have more than X items in progress at any time. Before we start another item, we need to finish an old one first.“

Perhaps it is as simple as this. Perhaps it isn’t. But the interesting point here is that now the teams starts discussing things in a completely different way, because they’ve never thought about it from this perspective!

Now let’s go one step further. So far we’ve assumed that we take a measure (new tool, new policy etc.) and this measure will only effect one part of Little’s Law (e.g. Throughput). In practice it’s often not that simple. Let’s take Pair Programming as an example. What will happen if a team starts pairing? One effect might be that the Throughput goes down, because utilization of team members goes down. And this is certainly the most common argument against Pair Programming. (Let’s forget the fact for know that in reality often Throughput does not go down, because pairing leads to less multitasking and better focus.) At the same time something else happens: Pair Programming means that we decrease WIP dramatically! And this will lead to shorter Lead Times. So what we observe in reality quite often is that the overall Lead Time after introducing Pair Programming will be shorter than before – in addition to higher quality and better risk management through continuous knowledge transfer. We’ve seen this happening many times. But it sounds counter intuitive and therefore it’s hard to convince people to give it a try. Using Little’s Law as a model can help making these effects clearer and easier to understand/explain.

Let’s look at another example: utilization. If we consider our Lead Times to be too long, our first reaction is: We need to work more efficiently. And we get there by higher utilization. So we start „managing people“ better so that they don’t have any idle times anymore. According to Little’s Law this might be a good thing to do in order to increase Throughput. But what we often forget is the fact that at the same time we increase the WIP. How can we get better utilization of people? We make them work at new tasks every time they have spare capacity! So the overall effect of higher utilization is often longer Lead Times instead of shorter ones (not to mention poorer quality and a higher stress level of the employees)!

I would be interested in your experiences: How do you use Little’s Law? Do you find it useful? Do you have other examples for fruitful discussions? Please leave a comment!

P.S. If you want to learn more about the fancy side of Little’s Law, you really should attend Lean Kanban Central Europe in Vienna, Oct 22-23. Dan Vacanti will give his talk Little’s Flaw, and together with Frank Vega, he will give the workshop Advanced Kanban Metrics which I really recommend!