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!
