For some time now (at least since May 24th) Alistair Cockburn has been expressing a dissenting view about Kanban and the value of imposing WIP limits. I'd like to quote a number of his tweets on the topic. These are quotes from May 24th to 28th. You can follow Alistair on Twitter @totheralistair.

in reply to @ponderings Agreed - might call w limits "Kanban for Kindergardners" vs w/o limits "Kanban for Grownups". Why not treat them as adults?

in reply to @bellware What I'm saying is that WIP limits enforce (read: replace thinking) what simply observing would give you, but triggers stoppages.

continuing... @bellware Indeed - and you don't need to back up the assembly line to get that. WIP limits are muda.

in reply to @bellware @davengeo WIP limits are training wheels --- I say this in part to provoke thinking, partly cuz it may be true

and again @bellware I suggest you try removing WIP limits and use your eyes and brain instead of backed-up Q to notice bottlenecks

While Alistair's dissenting voice is welcomed and I believe healthy as a challenge to the emerging Kanban community, these tweets can't go unanswered. Alistair carries a considerable stature in the industry and snappy soundbites such as these tend to get repeated without depth of understanding.

I like to give Alistair the credit for being the first person to observe that Agile Software Development is a Collaborative (or Cooperative) Game. A game in which the outcome isn't zero sum and in which the players muct cooperate rather than compete to maximize the outcome. It's interesting then that Alistair doesn't appear to have recognized that introducing WIP limits is introducing a new rule (or set of rules) to that collaborative game.

What we've come to recognize is that the introduction of WIP limits forces conversations to happen that were not happening before, and the derivative mechanisms resulting from WIP limits such as prioritization meetings and selection mechanisms, impediment escalation and a focus on flow to both shorten cycle time and improve predictability encourage collaboration and cultural change for the better, that was not present even with first generation Agile methods.

Alistair suggests that WIP limits are waste. The facts are that we started with no limits. Then we introduced the concept of managing WIP and controling it so it doesn't spiral to infinity. Several people who tried this seriously in the mid-naughties (circa 2004-2006) soon realized that managing WIP helps and if managing it helps wouldn't limiting it be both simpler and create greater freedom. [For example, Sterling Mortensen at HP.] Limiting WIP eliminates the coordination costs (management overhead) or "waste" of having to manage WIP. Limiting WIP enabled work-in-progress to become self-organizing. So WIP limits don't add waste they remove waste. They free managers to worry about more value-added activities.

Alistair also suggests that WIP limits are for children while adults can do just fine without them. Again, this is in denial of the reality and history. Traditionally, we haven't limited WIP. In fact, the concept of WIP wasn't even in the paradigm of project management or software development until this decade. So plenty of adults have been struggling with managing WIP without limits for a long time. [In the HP case study they discovered they had almost 5 years worth of WIP before they started to manage it.] Alistair suggests that we don't need WIP limits to see bottlenecks or other stoppages (impediments, blocking issues). And while this is true, we need to look at the facts and how well we as an Agile Software Development community are doing with that.

The reality is that most Agile Project Management tools struggle to show blocked work and do not treat blocking issues as first class objects. There are no features for escalation and no features for reporting quantity of work blocked, time blocked, who the issue is assigned to or what they are doing about it. The tools vendors are only just catching up with this kind of functionality. There has been little emphasis on prioritizing the removal of blocking issues or resolving stoppages. Why? Because before Kanban they weren't treated as stoppages. They were treated as work that could be put aside while something else was started. Adding WIP limits has helped the adults change their focus onto issue management and resolution to keep things flowing, rather than keeping busy. I blogged at great length on this topic last month Managing WIP isn't the Same as Limiting WIP Part 1.

What about bottlenecks? Well the introduction of cumulative flow diagrams (later called burn up charts by some of the Scrum community, and also known as finger charts) in 2002 was slow to catch on. Some tools vendors did provide limited support for CFDs but guidance on how to read them and use them was limited pretty much to anything I published until very recently. One developer at a major Agile project management tool vendor only recently tweeted that his product was finally "all pimped out with a CFD." So what about simply walking the floor and asking "where is the bottleneck?" Well generally that wasn't happening either. If teams were managing bottlenecks then lots of people in our profession would have slack time because they aren't working in the bottleneck station. As a result the 40 hour week or sustainable pace would be commonplace among Agile teams and across our industry, but it isn't! The guidance on Lean and flow and how to see bottlenecks with CFDs and what to do about them with TOC has been widely available since 2003. The reality is that it hasn't been happening. When we introduce WIP limits and adjust them correctly, bottlenecks manifest themselves and the effects are felt immediately. The organization recognizes the bottleneck for its true impact and something gets done about it. This behavior is becoming much more commonplace with Kanban.

WIP limits are for adults! They are for adults that care about sustainable pace, flow, throughput, and process improvement. They are for adults that care about increased collaboration and cooperation and a higher trust more empowered workforce and culture in the workplace. WIP limits are surprisingly empowering! It's interesting that a constraint can be something that makes you free! WIP limits are a new rule in the collaborative game that is Agile Software Development. Its a rule that empowers people, treats them with respect, increases social capital and collaboration in the workplace and focuses organizations on improving their process for long term benefit. WIP limits enable "stop the line." They enable the Lean concept of the pursuit of perfection by encouraging a focus on process improvement.

When asking whether WIP limits are for beginners or experts ask those who are actually using the technique whether they could imagine going back to merely managing WIP or worse not bothering at all? In my kindergarten example from yesterday, could you imagine the chaos that would be introduced by removing the WIP limits? Even if it wasn't chaos how much wasted time would be spent negotiating and agreeing acceptable limits of children at each workstation? How much effort would be wasted resolving disputes with arbitration?

WIP Limits are a new rule in the collaborative game of Agile Software Development. Adults use them to eliminate waste! Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban, Software+Engineering, Project+Management, Alistair+Cockburn