For decades now, the Operations Research and Industrial Engineering communities—and especially Lean and Theory of Constraints (TOC) practitioners—have preached the importance of limiting “work in progress,” or WIP, in order to improve flow in a process or system. The conceptual foundation for such WIP limits is known as “Little’s Law,” named after John Little for having provided the first proof of the theorem back in 1961. In order to boost the throughput of a system, Little’s Law asserts that either cycle times (or “lead time”) must get faster for a given level of WIP, or that WIP must go up while cycle times stay the same.
Little’s Law in Practice
Those unfamiliar with the typical application of Little’s Law might be thinking, “Wait a second—why would it make sense to limit WIP when trying to boost throughput, if higher WIP can lead to better throughput for a given lead time?” The answer is that higher WIP levels often cause lead times to degrade significantly, more than erasing any potential throughput benefit of higher WIP. For example, if we add cars to a wide-open highway, that highway system will immediately show higher throughput, as all cars can continue to go at the speed limit. However, if we push cars onto an already congested highway, we will slow things down so badly that these additional cars end up worsening the overall performance of the highway system. The key question, of course, is whether the system is already over capacity—or more precisely, whether the system’s WIP is already past the optimal flow point on its flow-density curve.
In practice, it’s often human nature to push systems beyond their capacity, and so Little’s Law teaches us that limiting WIP in most situations helps improve performance. Using our highway example, we might try to limit the number of cars entering from the on ramps in hopes of minimizing congestion of the system overall.
But what if we inadvertently limit WIP too much, and only allow on the highway, say, half the number of cars that it could handle at the speed limit? According to Little’s Law (and common sense), this will invariably result in poor throughput of the system—lots of people waiting on the onramps for no good reason. Clearly, a better solution here would be to establish a WIP target that helps us understand when to limit WIP, and when to encourage more WIP, depending on whether the system is over capacity or under capacity. We just need to know what that target should be, and whether it might change under different circumstances (e.g., when it rains).
How to Apply WIP Targets for Team Performance
When applying the concept of a WIP target for teams of human beings, the key question again is “What’s the right target?” Fortunately, this is an easy one, proved over and over again across countless studies: the human brain can only really handle one task at a time with any level of speed and effectiveness. So for individuals, the best WIP target is simply “1.” If an individual tries to juggle ten tasks at the same time, switching back and forth constantly on all of them, they will almost invariably complete those 10 tasks much more slowly than if they simply worked one at a time through to completion. And the more complicated the task, the greater the degradation in performance when task switching.
For a team of ten people, therefore, the best WIP target would be no more than “10.” Note that the best answer here may not be “exactly 10,” but “no more than 10.” Why? Simply because some tasks lend themselves to having two individuals collaborate to achieve optimal flow. For example, a two-person team of movers will likely move your big furniture items faster working together than individually—it’s nearly always faster to have two people carry that big couch than to split them up and ask each to try and hoist big and unwieldy items by themselves. Similarly, in software development, some teams have seen “paired programming”—two programmers working together on the same programming task—generate higher levels of team productivity than having each individual work their own task. If the whole team finds this to be the case, then the right WIP target for that team would be 1 task for every 2 people, or for our team of ten, a Team WIP target of “5.”
But wait, what if some team members work better individually, while others work better in pairs, or even in groups of three or four? In that case, the team must have the freedom to experiment with different Team WIP targets—they might start with a target of “7,” knowing that some members work well in pairs, while others do not, and perhaps compare their results with a target of “8” to see if that helps or hurts team productivity.
What about when task owners get stuck and need help? In this case, the team might experiment with having one senior expert as a “floater,” lending support to whichever task owners might need it. This might cause us to adjust our Team WIP target downward somewhat, perhaps to “6,” and see if that helps or hurts the flow of team task completions.
What about the scenario in which the team starts to get really good, so that they no longer need the expert floater very often? We might then ask that expert to go back to focusing on her own tasks, thus boosting the Team WIP target back to “7” or “8.”
What about different task types? We might have some tasks that lend themselves to small teams, while others seem better handled by individuals. The 2-person team of movers might work together when moving that big table, but individually on those boxes of books. In this case, we might try and fine-tune the Team WIP target by task type, or simply adjust the overall Team WIP target according to the mix of tasks at hand.
You might be thinking, “Hey, given that we want WIP no higher than 10 for any 10-person team, wouldn’t it be better to simply impose a Team WIP limit of 10?” There are at least two reasons why this will be suboptimal:
1. There will invariably be instances in which one or more team members are stuck on a task in progress, and unable to proceed without help that may be a long time coming. In this case, we would usually prefer to have these team members pull a second task, as opposed to just sitting idle for days on end waiting for help to arrive (or worse, sticking the blocked task back over on the To Do list so that it no longer counts as WIP).
2. The Team WIP limit does nothing to encourage teams to experiment with optimal Team WIP levels, which will nearly always be some number below the number of team members. For some 10-person teams—such as our team of paired programmers—a WIP level of 10 might inadvertently encourage each pair of programmers to work two tasks simultaneously, degrading single-task focus and slowing things down significantly.
Single-Task Focus + Team Autonomy = High Performance
While having a Team WIP target designed around single-task focus is key, perhaps even more powerful is trusting the team to fine-tune its own WIP target as it experiments with better and better ways to improve flow. So while the difference between a WIP limit and a WIP target might seem subtle, the message each one sends to the team can be drastically different. A WIP limit risks sending the message, “We in management know best, and don’t trust you to figure out how to pursue ever-higher levels of performance, so we’re setting a limit, and you must comply and follow it.” In contrast, a WIP target sends the message, “We in management want to protect you from the evils of task switching, and therefore encourage you to set a WIP target that helps maximize single-task focus across the team; as for how best to organize yourselves in the pursuit of ever-higher levels of performance, we trust that you will experiment with different Team WIP targets, and adjust them as you see fit.”
When coupled with Lean’s flow-enhancing benefits of “pull” (self-assigning tasks when ready) in a highly visual manner, the team’s sense of autonomy will be amplified further, as it sends the message, “We trust you to work at a steady, sustainable pace, and to do so with a sense of urgency; we further trust you to take breaks when needed, to cover for your fellow team members when needed, and to always put the needs of the team first.”
While there are of course other important considerations when pursuing high performance—such as TOC’s focus on identifying and exploiting the system constraint, or Six Sigma’s focus on keeping variation under control—we believe that eliminating WIP limits in favor of WIP targets is usually the most powerful way to achieve dramatic gains in task-level productivity, simply because of how effectively they promote both single-task focus and team autonomy.
More of us practitioners need to embrace the notion of WIP targets, as opposed to WIP limits, before their benefits can be more widely recognized. It would also help for tool vendors to begin offering features that support teams’ pursuit of ever-higher productivity through effective WIP targets. Fortunately, two such vendors have begun to pay attention, slating such capabilities for near-term release. I’m happy to share more on these vendors for anyone interested—just drop me a note at Mike@FortezzaConsulting.com.
You must log in to post a comment. Log in now.