Don’t be fooled by Little’s Law
Quite a while ago, when I started to explore the world of KanBan, a 2nd generation agile method that can be applied to many forms of knowledge work, I — of course — stumbled over Little’s law. I don’t want to dig too deep into the theorem itself here, but it basically says, that within any queuing system there’s a linear relation between the Lead-Time (LT), the Work-In-Progress (WIP) and Throughput (TP), often expressed like this:
LT = WIP / TP.
That linear relation always looked counter-intuitive to me — it just doesn't match my experience. Even before I knew Little’s law, I had a gut instinct, that there’s some kind of exponential relation between the amount of parallel work and the Lead-Time: It doesn’t just take twice the time to complete a task, if the amount of tasks that are being worked on is doubled, there’s some additional loss of efficiency.
But Little’s law is linear! How can this be? We’ll get there soon, but let me clarify the term knowledge work first:
The main feature differentiating knowledge work from other conventional work is that the basic task of knowledge work is thinking. Although all types of jobs entail a mix of physical, social, and mental work, it is the perennial processing of non-routine problems that require non-linear and creative thinking that characterizes knowledge work. (Reinhardt, et. al.; Knowledge and Process Management 18, 2011, No. 3, pp. 150–174)
Assume a team of knowledge workers processing non-routine problems, developing software applications for instance — that is a queue system and therefore Little’s law applies. Optimizing the Lead-Time of that system/team is a major task from the management perspective, since incomplete work cannot be billed.
For the time being, let’s also assume that the Throughput of that system is limited by the number of team members and treat that as constant. (Of course it’s also an option to add more team members — up to a certain point, but that’s another story.)
Agreed? Ok.
If the Throughput is constant, Little’s law tells us, that the only option to lower the Lead-Time is to the reduce the amount of parallel work (WIP). That’s the reason why KanBan is WIP-limited and why the team decides about the amount of work for the next Sprint in Scrum (besides some other reasons).
So far, so good, keep that in mind for a sec.
Let’s look at cost of task switching. It’s well known that our brain has a fixed limit of seven, plus/minus two, for processing information (George L. Miller; The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information in The Psychological Review, 1956, vol. 63, pp. 81–97). Therefore, when switching tasks, information has to be (kind of) unloaded and other information has to be loaded and processed. Task switching can lead to loosing up to 40% of productivity (Susan Weinschenk, 2012; The True Cost Of Multi-Tasking) and is named one of the seven wastes of software development (Matt Stine, 2010; The Seven Wastes of Software Development).
Task switching is not mentioned in Little’s law. Why? Is it irrelevant? Does Little’s law just apply to conventional work, since in conventional work there’s no such kind of task switching? You process whatever you do until it’s ready and afterwards proceed to the next task, which is — due to the nature of conventional work — quite similar or even repetitive (no unload/load cycle). Think of a drive-in of some fast-food restaurant.
I assert, that quite every knowledge worker out there will agree that task switching is real, occurs daily, perhaps even hourly. And it’s related to WIP as we’ll see soon!
Let’s do just a little bit of math and try to calculate the waste introduced by task switching: If a (knowledge) worker has one task, the number of theoretically possible tasks switches (PTS) is obviously zero. If (s)he has 4 tasks, PTS is 6. With 6 Tasks it’s 15, with 8 it’s 28. This is calculated by this formula: PTS = WIP! / (2! * (WIP-2)!). That’s a non-linear relation, since it involves Faculty (!).
Possible task switches doesn’t mean, that they really occur. We have to multiply PTS with a individual likelihood of a system that task switching occurs — which is a constant factor, let’s assume 35%. If we further assume a task switch wastes a median time of 10 Minutes, we’ll get this Graph:
In that example, an employee with 10 tasks assigned will waste 2,5 hours of time due to task switching. Of course, this it just a theoretical example to illustrate my point. Real world values depend on way to many factors that influence a median task switch duration and the likelihood of the system that task switches occur.
Now, back to Little’s law and try to integrate the fact, that we have waste due to task switching in a knowledge work system, which relates to WIP in a non-linear fashion.
The naive approach would be to claim Little’s Law as non-applicable to knowledge work. Wrong! To be honest, I was also fooled by this approach, since I had no clue, how a non-linear waste-function can fit into a linear queue-function. Luckily I stumbled over an article by Frank Vega named Little’s Law: Isn’t It a Linear Relationship? written in Sept. 2012 as result of a conversation with Arne Roock.
I had to read it several times to, well, at least start to understand why this Article is the key to resolve my doubts that Little’s law applies to knowledge work and already includes a non-linear component: The simplifying — and at first sight valid looking — assumption, that the Throughput stays constant if the WIP is raised is wrong.
The waste I calculated above does what? It lowers the Throughput of the system — by an amount that relates non-linear to WIP as we’ve seen. With a non-linear denominator (TP) in Little’s law, the Lead-Time also behaves non-linear!
Summary
Don’t be fooled by an apparent simplicity of Little’s law. It’s not just the simple linear mathematical formula it seems to be at first glance. There’s a specific setting around that simple formula, that must not be overlooked.
Also keep in mind that raising WIP also raises the Lead-Time in a non-linear way due to waste introduced by task switching.
