extreme programming

Kanban - a way to visualize bottlenecks in your software development project

A Kanban Board shows the current status of all the tasks to be done within this iteration. The tasks are represented by cards (Post-It Notes), and the statuses are presented by areas on the board separated and labeled ToDo, Doing, and Done. This Kanban Board helps the team understand how they are doing well as well as what to do next and makes the team self-directing. 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.

Overheard: Kent Beck, extreme programming and the quest for quality

I think it’s a combination of technical and social factors that leads to all the defects in deployed software. Part of it is the attitude that software is just inherently unreliable, and customers are conditioned to accept that. Developers are conditioned to accept that. Testers are conditioned to accept that. We just decided it was like the weather and there’s nothing we could do about it, which isn’t a very responsible position because in fact, there’s a lot that software developers can do about it. 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.”