By Chris Sims
In my most recent InfoQ article, I write about someone's approach to making a kanban flow look less like a waterfall process. The result is a workflow with new names for the steps. That's fine, but it misses the point that even if the steps are the same, an agile kanban system is far from, and far better than, a traditional waterfall process.
Waterfall is a batch-and-queue process. All of the work in one phase, say requirements gathering, is done before the next phase begins. In this way the requirements work is done as a batch. The output from this batch is then queued up waiting on the next phase to begin. The problems with this are many.
First off, this batch-and-queue builds up a lot of unfinished work-in-progress. Each piece of work-in-progress represents time, and thus money, invested. The work-in-progress is not shippable product, and so earns the business no money. The more we pile up work-in-progress, the more our investment increases, while our return stays at zero.
Another problem with the batch-and-queue waterfall process is that we are unable to get meaningful feedback from our customers until very near the end. We don't know that we misunderstood some of the fundamental requirements until it is very difficult, and expensive, to make corrections. We also don't find out about quality and performance issues until late in the game. Finally, accommodating changing requirements is notoriously difficult.
A kanban system, by contrast, is a single-piece-flow (AKA continuous flow) system. A single piece of work moves through all of the steps from start to finish, resulting in finished product. The whole point of a kanban system is to minimize the amount of unfinished work-in-progress. Even if a given kanban process has steps that look exactly like waterfall, there are huge gains simply from avoiding the batching and queuing. The team will produce their first bit of finished product dramatically sooner. The business has the opportunity to start earning a return right away. The customer can give feedback. Misunderstandings can be addressed. All of the additional goodness that comes from short feedback cycles happens.
I'm not saying that the best way to do an agile kanban system is to take each feature (or story) through a mini waterfall; there are better ways. I am saying that even if a kanban flow looks superficially like waterfall, the fact that it is a single-piece-flow system makes it fundamentally better.
Comments