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

Tuesday, June 23, 2009

Kanban Blogosphere Roundup June 23rd

Jon Miller has started using his own personal kanban system. Read his adventures of the first day and note how kaizen events to make improvement kicked in almost immediately. Note also that he doesn’t feel the need to create a WIP limit for his “delegated to” column simply because the constraint of the size of the board is well below his capacity constraint. He’s also introduced some classes of service and despite all these changes he’s managing to keep it simple. I hope Jon keeps up this diary of introducing Kanban to his personal business. His incredibly instructional for us all. Thanks for sharing Jon.

Karl Scotland wrote a Kanban sidebar for a forthcoming book by Rachel Davies and Liz Sedley. He’s recently revised it during the final review process before printing. Here is take 2 on his Kanban sidebar.

And Alan Barber shares his Kanban board with us, “added a few tasks and completed one.”

Meanwhile Rick Simmons reports via Twitter that his team made 3 or 4 revisions to their Kanban system on the 1st day. This is exactly the sort of behavior I’d expect if a team has a culture that already lends itself to kaizen. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban, Software+Engineering, Project+Management

Monday, June 22, 2009

Kanban and Lean Roundup June 22nd

In today’s roundup, I’m covering some more general Lean stuff that is flying under the more specific flag of Kanban. It’s amazing how people want to be associated with success.

First off, who is this making Kanban t-shirts all of a sudden? Personally, I’ll be waiting for my official Limited WIP Society shirt! Designing these is on my backlog, but I haven’t pulled that job into my personal WIP limit yet

Next up, super post from Rob Bowley detailing his team’s current practices. A lot of Lean going on here with cumulative flow diagrams, cycle time metrics and so forth. Excellent stuff. One or two tweets on this referred to it as Kanban but Rob is really quite clear in his post. He’s doing Lean stuff and doesn’t even call his card wall a Kanban board.

Matt Wynne’s Kanban State of Mind is worth revisiting.

Kanban in Portugal anyone?

And another example of someone trying to adopt Kanban for their personal life. Not sure if this one has a WIP limit and is a pull system or not.

I’m not entirely sure what Si Alhir is on about with this comparison of Leanness, Agility, and Competitiveness. If someone can understand this chart and explain it to me, please leave a comment. Thanks.

I’ve mentioned it before on Kanban Roundup but Kallokian blog’s Defining Kanban has provoked an interesting discussion thread about kanban versus Critical Chain and early versus late start. I’ve noticed that when talking to folks with a manufacturing and industrial engineering background about our use of Kanban (or Drum-Buffer-Rope earlier on) that they simply can’t get their heads around it. They have a mindset that project management is for knowledge work problems and they have their pet solutions to variability and project dependency graphs such as Critical Chain or GERT (Gantt meets PERT and they had a baby.)

The whole issue of early versus late start is mute with Kanban (using a capital “K” now) because of the prioritization scheme and the use of classes of service. There are no estimates - unless the class of service demands it and a specifically “late start” prioritization scheme is adopted, as I have documented with the Fixed Delivery Date class of service at Corbis (and elsewhere) - so you can’t early or late start against an estimate. There is no concept of a dependency graph of the order of work because selection of work is delayed until it is prioritized into the input queue. This looks awfully similar to “late start” to me, but what it really is, is a very similar process to TOC Buffer Management and self-prioritization in advanced DBR solutions.

The problem with the folks debating the project management solutions is that they can’t break their minds out of the project management dependency graph paradigm and think of software development as a flow problem. They want to wrap everything up in a project with a defined release date and by doing so, wrap all the activities within the bundle into a homogenuous blob from a risk perspective. There is no concept of “cost of delay” or “loss function” at the individual work item level, only at the project level. Kanban frees us from these man made imaginary constraints and enables us to treat the work independently from a risk perspective and consider the cost of delay (or potential loss) for each item indvidually. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban, Software+Engineering, Project+Management