Tuesday, June 30, 2009

WIP Limits are for Adults too!

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

Kanban without Pull

My younger daughter’s pre-school uses a kanban system. I’d been staring at it for months without realizing it was a kanban system and after I did I was troubled by the fact that it wasn’t a pull system. So I had to think about it a bit.

First an explanation

The board is laid out into a series of sections with slots in purple for a station (or type) and a fixed number of slots in red for children. The concept is simple. Different types of activities have different limits on the ideal number of children should participate. There are many more activities possible than available on any one day. So the teacher wants to be able to assign activities to slots on the board - and then physically lay out the activity within the room - for example the train table or the doll house. The children (typically 3 to 5 years of age) are empowered with “Free Choice” and can choose the activity they want to participate in. They are also free to move from one activity to another. The cards with their picture are kept in an index card case. When arriving at school at 9am they take their picture out of the case and decide which activity they’d like to start with. They stick their picture into an open red slot using a velcro fastener. If there is no open slot free on the activity they want, they have to choose something else. When they decide to change activities they return to the board and move their picture to the new activity and place it in an open slot. At any time, they can walk past the board to see if a slot has become free. At the end of the day, they move their pictures to the Going Home buffer off the board, and later the teacher returns the photos to the index card box.

It’s not a pull system

While this is clearly a kanban system, as it both limits WIP and uses cards to signal availability, it is not a pull system. This troubled me until I realized that goal is not flow. There is no concept of flowing children from one activity to another and no need for each child to visit each station. There is no flow, so there is no need for pull.

So why limit WIP?

Limiting WIP introduces a rule (or constraint) and the system to enforce and enable it, the kanban system, introduces concepts that 3 year olds have to learn. It introduces some overhead for them to enjoy pre-school. So why do it? Well the rules of kanban enhance collaboration amongst the children. The experience of playing at any one station is enhanced because only the appropriate number of children are at any one station at a time. No station is ever over-crowded.

The kanban system also empowers the children to have “Free Choice” even though they are only 3 or 4 years old. The rules of their kanban system mean that the teacher does not need to manage the number of children at each station, free’ing the manager (err, teacher) to do other things, and the rules insure a collaborative environment and avoid disputes, negotiatiation, arbitration and reconcilliation that would be needed otherwise. The kanban system enhances the experience for the children, shows them greater respect as individuals, empowers them, while giving back the teacher more time to perform value-added activities rather than waste time resolving disputes over resources.

Kanban embraces and enables the People half of the Toyota Way

For me this example truly highlights how kanban embraces and enables the softer people aspects of the Toyota Way and Lean. Kanban respects people by empowering them and free’ing them from managerial supervision. It respects managers by giving them more time to perform value-added activities in this case child development. And kanban systems enable teamwork and collaboration by puting rules and constraints around what is acceptable behavior.

Recently Alistair Cockburn tweeted that Kanban with WIP limits was for Kindergarteners while Kanban without WIP limits was for adults! I’ll blog more about that thought another time. Meanwhile, isn’t it interesting just how much we can learn from kindergarteners and what they can teach us about empowerment and collaboration in the workplace? Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban, Software+Engineering, Project+Management

Kanban Blogosphere Roundup June 30th

It’s been a week since I posted one of these summaries. I’ve been busy on other stuff and haven’t had much time for blogging. Meanwhile, Kanban is generating on average 2 tweets per hour on Twitter and there has been some active new blogging and meetings in the past week. Agile Denver has a good crowd (30+) for Brad Swanson and Frank Vega presenting their experience moving to Kanban from Scrum and why Kanban worked better for his team. Tonight the Limited WIP Society London chapter will be meeting at XtC. And…

Getting Started with Kanban

David Joyce had over 100 people at the BBC last week for his Kanban presentation in London. Skillsmatter have made the video available. I’m told that David used a lot of material from me and Karl Scotland and I’m sure this is a very comprehensive introduction on how to get started with Kanban. The BBC is one of the largest adopters of Kanban and has taken a lead in the media industry which is generally an early adopter of the technique. It seems that media schedules don’t fit nicely into time-boxed iterations and first generation Agile approaches are at best a forced fit. Kanban seems to be gaining traction because it decouples prioritization, cycle time and delivery and allows them to fit naturally into media cycles.

Kanban and People

Last week Henrik Kniberg posted this education cartoon, One Day In Kanban Land. This is a stop frame of part of his animated story from his Kanban versus Scrum presentation that you can see at QCon in San Francisco this coming November.

The Toyota Half Way is a nice piece from Bob Emiliani explaining that TPS has two halves - the continuous improvement half made up of Challenge, Kaizen and Genchi Gembutsu and the Respect for People half made up of Respect and Teamwork.

One or two folks on Twitter jumped on this and suggested that Kanban belongs the in the first half and that Kanban doesn’t address the second half, so it is only a half way solution to the Toyota Way applied in software engineering. This couldn’t be further from the truth. It seems many folks just see the mechanism - the cards, the WIP limits, the signals, and don’t listen to the stories and the effects and the outcomes, or for that matter the motivations. It makes me believe that many people don’t actually take the time to watch the presentations before they pass comments.

One of the original motivations for Kanban (in software development) was to limit WIP to enable a truly sustainable pace and to eliminate variability from the day-to-day lives of the workers. This truly shows respect for the knowledge worker. Kanban and its policies empower workers. What is more respectful than empowerment? Kanban encourages teamwork across the whole value stream. It changes the culture of an organization and the result is a much more collaborative workforce. Henrik’s One Day in Kanban Land cartoon demonstrates this admirably.

So it’s entirely false to suggest that Kanban only delivers the Toyota Half Way. Perhaps those saying this need to reflect that ‘respect’ does not equal ‘politeness’ and ‘teamwork’ need not only be among defined teams. ‘Respect’ in this context means trust, empower, and do not punish failure rather seek to learn, understand and adjust. ‘Teamwork’ in this context means collaboration at all levels and along the full value stream.

...+++...

And finally, I missed this earlier post from June 10th on the costs of iterations with Kanban. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban, Software+Engineering, Project+Management