Many Kanban practitioners learn the basic principles of the method through a simulation called "GetKanban". In this fictional scenario, an organization develops some software features using a Kanban System to manage the flow of work.
At some point in the scenario, a new Test Manager called Carlos joins the organization. At that point in time, strict WIP limits are observed in every activity of the development workflow. But Carlos doesn't want Testing to be seen as "holding up" work, so he decides to remove WIP constraints for that activity. "My staff can handle the work", he points out.
As a result of this (and some other policy changes that result in an inability to collaborate across activity boundaries), Testing invariably gets overwhelmed with the influx of work coming from upstream activities.
The most obvious, visible effect of this change of policy is the pile up of tickets in the Test column. But, what else is happening to that work?
Work goes idle
Well, the problem is, in fact, that not much is happening to that work: with only 2 "units of capacity" to do testing (represented in the simulation by 2 green dice), and the inability to collaborate with other people in the workflow, testing can focus only on (at most) 2 of those tickets at any given time; all the others will have to wait for attention.
Some people will be quick to point out, however, that "in real life" we would able to stretch out capacity to cover more than two tickets: we may have "2 dice", but each dice can "multitask" over more than one ticket at a time. While this can be true, it doesn't change the fact that there's a limit for human capacity to handle things simultaneously, so while we might be able to "time slice" across several work items, eventually we'll reach a point where some work items will have to wait while we "multitask" on others.
This is, then, the most immediate effect of high WIP: work will "age in place", accumulating Lead Time without making any progress. In essence, "idle work" waiting for "very busy people" to have some time (and energy) to devote to it.
But this is not the only thing happening to "idle work": as it seats waiting, any defects and wrong assumptions hidden in it will not be discovered until later. Any required rework needed will have to be started, or "added to the backlog", causing the Lead Time for the original ticket (or the value it was meant to provide) to increase even further.
With the passage of time, we also start to forget things like context, details, decisions, ideas, etc. As work ages, we then need additional time to "get back into the zone" when we eventually go back to it, and the likelihood of forgetting something and introducing a defect (which will cause rework later) also increases. In both cases, the result is an increase of lead time.
Additionally, the feedback loop carrying information about the defect or wrong assumption will become longer: there will be a delay of that information arriving to other places, allowing other pieces of work containing similar problems to continue their flow in the workflow, potentially causing additional rework (and more delay) later.
We also need to remember that we don't just "do" the work, we also need to manage it: work needs to be tracked and accounted for, we need to talk about it to understand it (or "groom" it), or to report its status to others, and we need to plan other activities around it.
The more WIP there is, the more the overhead it will generate. The immediate effect of high WIP in this regard is the clutter it causes on tracking mechanisms, like Kanban boards. When this happens, the increased visibility (if at all possible) tends to cause confusion more than it illuminates.
But we don't track work just to show it on boards, dashboards, and spreadsheets: we do it so that we can talk about it. And we do that, more often than not, in meetings. As a result, the higher the WIP, the more meetings are usually required to manage it. And the more difficult is to conduct this meetings productively, not just because the amount of work is high, but because yet another effect that high number causes: cognitive overload.
Our minds are not well equipped to deal with large number of items. Once we become overwhelmed by having to deal with too many things simultaneously (and the ceiling is not very high), we start loosing track, and confusion, paralysis, and stress set in. Making progress becomes more difficult, usually resulting in yet more delay and longer lead times, decreased quality, or both.
Finally, information (and knowledge in general) has a tendency to decay over time: some of it can become less relevant, and loose value. High WIP, through upwards pressure on Lead Time, can then result in less valuable work delivered to the hands of our customers.
Ok, so what can we do?
We've known the solution to the "too much WIP" problem for a long time, and in Kanban we have a General Practice for it: Limit WIP. The idea behind it is that it essentially allows us to focus, and that way avoid most of the negative side effects I described earlier, obtaining faster lead times and better quality.
Easier said than done, however: it's not uncommon to find significant resistance to the idea of WIP limits (from all levels in the organizational hierarchy), and even when it's attempted, people find the practice difficult to sustain.
It might help to keep in mind that the practice should be better understood as "Constraint and Manage WIP" rather than (just) "Limit WIP". WIP will naturally fluctuate, and negative effects can be felt both with high and low amounts, which suggests that active measures should be taken to make sure it's under some for of control. We tend to think of the WIP Limit as the "ceiling" for WIP, but we can also understand it as some form of "average" value around which we will allow amount of work to fluctuate, within certain boundaries. If we understand (and control) the spread of that WIP variation, we have essentially set up a limit, without necessarily declaring a number to post on a Kanban board.
One way to accomplish this can be to agree to follow the principle of "prefer finishing to starting" (also known as "start finishing, stop starting"). This way, although there may be no limits on the number of work items on a given column, or even within a workflow, when given the chance to decide what to focus on, our preferences will be directed to those items closer to the finish line.
There are also what Donald Reinertsen calls other "demand side" strategies for WIP control, where rather than preventing work items from entering (which is what a WIP Limit normally does), we setup rules to "kick out" items once certain level of WIP is reached. An example of this could be to discard or abandon aging work items, or work items of lesser value (the way network routers start dropping packages to deal with congestion). Another strategy could involve relaxing definitions of Done, or having optional scope that can be discarded or deferred, thus allowing the work item to flow forward. These strategies might feel like "cheating", and they are definitely not universally applicable, but we need to remember that the goal is to find a pragmatic, adequate trade-off.
If imposing an explicit WIP limit is a possibility, there are then multiple options, from Personal WIP Limits, to CONWIP (limits that apply to sequences of activities in a workflow), to activity limits, etc.
Personal WIP limits are often a common first step, since it can be adapted to each individual's preference and comfort zone. It can also be a good option in situations where there is considerable "irrefutable demand", and incoming work cannot be denied entry. While it will not stop overall WIP from increasing, at the very least It will allow individuals to focus better, and to work at a sustainable pace. If combined with the "start finishing, stop starting" rule, it can have the effect of achieving smoother flow, even if lead times are long and unpredictable.
"You don't limit WIP with a WIP Limit"
My colleague Alexei Zheglov is known for these wonderful, often tweet-size aphorisms we call "alexeisms", and one of then is applicable to this discussion: "You don't limit WIP with a WIP Limit".
As mentioned earlier, more than just limiting WIP, we need to manage it. But regardless of the strategy we use, keeping WIP under control is not about dictating policy, like posting a number a top a Kanban board column.; it's really about gaining agreement and then following through with those agreements. So, it's really a matter of leadership.
This article is part of a series on Sources of Delay. Find the main article, and links to other parts here.
Comments