Kenji Hiranabe, Visualizing Agile Projects using Kanban Boards

Today’s WhatIs.com word of the day is Theory of Constraints.  It’s an approach to systems management that can be used by anyone in just about any type of management field.

Let’s say you have a very simple system where components  A + B + C + D = Output.   In the 1950s, the conventional American approach would be to make sure that each component in the system was optimized to its fullest so that the total output would also be optimized to its fullest.  (Component A would be optimized, componenent B would be optimized, etc.)

The Theory of Constraints proposes that you should forget about trying to optimize each part of the system.  Instead, you should look at the system holistically and identify the weakest component in the system.  The weakest component — the constraint — will determine, ultimately, how successful the entire system is.

A constraint is a bottleneck.  It impairs or stops throughput.  Because the bottleneck ultimately rules the sucess of the entire system, THAT is what you should place your attention.  The Theory of Contraints proposes that every working system has at least one bottleneck but no more than three (or the system wouldn’t work at all).

So the question becomes, how do you identify the bottleneck?  In a manufacturing plant, you might be able to physically see the bottleneck — it might be a machine that’s backed up.  But what if the system is distributed or the one you’re managing is knowledge-based?  That’s where Kanban comes in.

Kanban is Japanese for “card.”  In manufacturing, it’s a sign or signal in an inventory control system. As supplies are used up, new supplies are requested simply by sending a re-order Kanban card to the supply point. The new supplies are being “pulled” instead of being “pushed” a la Lucy and Ethel at the candy factory.

Agile software development teams have adopted kanban as a way to track progress and identify bottlenecks in the development process.  It’s a pretty common practice to see big sticky-note charts on a wall of a project room.  Now you know the name for those charts — kanban.  And the part of the chart where the sticky notes are jammed up together and overlapping? That’s a visual representation of a constraint.

David J. Anderson explains how he uses kanban to identify bottlenecks and manage software engineering projects.

Kent Beck, as quoted in Extreme Programming inventor talks about agile development

Kent Beck gave a great interview that’s posted on the IBM developerWorks site, where he talks about the payroll project at Chrysler.  It’s a great read.

Now, the payroll program would handle Chrysler’s entire payroll, representing 1/10 of 1 percent of the entire US gross national product — at that scale, with union rules and all the places they operate, it’s a complicated program. They had a crying business need; it had to work. At the same time, this wasn’t rocket science — we just had to execute.

So, after a couple of weeks I interviewed everyone one-on-one. I told the first guy that we’ll divide the project into three-week intervals called, say, iterations. In each iteration we’ll implement a few new features called stories. We’ll write down all the stories we need, slot them into the iterations, then do it.

I told the next guy [I interviewed] that we have these three-week iterations divided into stories. For each story we’ll write these, um, acceptance tests to demonstrate that the stories meet the customer’s expectations.

With each person I interviewed I added a little more. By the end of the day, I’d interviewed 20 people and had laid out Extreme Programming’s basics.

My favorite quote from the article? “Sucks less isn’t progress.”