Think You're "Doing Kanban?" Think Again.

Over the past several weeks I've visited three different cities in the U.S. with the same message: "Yes You Kanban." For 90+ minutes I've discussed with attendees of the No Fluff Just Stuff software symposiums in Boston, Seattle, and Atlanta, the benefits that they can reap from incorporating the principles of Kanban, a methodology focused on continuous, iterative improvement of existing software development processes, into their daily work.

Don't miss what I just said. Kanban is a methodology focused on continuous, iterative improvement of existing software development processes. And yet you'll often see and hear statements like "We've stopped doing XP/Scrum/RUP/Process X and now we're doing Kanban." Now it may be true that they've scrapped their previous methodology in favor of something that uses a kanban (little 'k') system (i.e. a pull system implemented using signal cards) to manage the work. However, it's quite impossible to use a kanban system without a process already in place.

Statements such as "Kanban is better than XP/Scrum/RUP/whatever" and "Kanban is a drop-in replacement for XP/Scrum/RUP/whatever" are totally meaningless. A kanban system is nothing more than a tool for managing workflow. It cannot be universally good or bad - it totally depends on the context in which it is used and how it is used in that context. It doesn't define the workflow; it only helps you to manage and improve the workflow.

A couple of days ago, David Anderson, author of KANBAN: Successful Evolutionary Change For Your Technology Business and one of the most influential leaders in the Kanban community, posted a challenging message to the kanbandev Yahoo! Group that has caused quite a stir. As I read his message, I realized that he and I were really trying to communicate the same points. With his permission, I've reproduced a portion of his post below:

Kanban is NOT a software development life cycle or project management methodology! It is not a way of making software or running projects that make software!

You apply a kanban system to an existing software development process (such as Extreme Programming, or Personal Software Process, or a traditional SDLC). In doing so, it may be disruptive to your existing project management method. It will change the project management planning, coordination and reporting.

Use of a kanban system is not possible unless there is an existing development process in use.

The Kanban Method is an approach to change management that employs a kanban system on to an existing process context in order to provoke evolutionary/incremental change. This is best done when a scientific approach based on models such as the Theory of Constraints, Theory of Profound Knowledge, Lean Waste model, and so on, is used.

When people talk about doing Kanban in preference to Scrum, for example, with maintenance work, they are actually suggesting that an alternative project management method is adopted that involves the mechanics of a kanban system. Underlying this there must be a software development method. This software development method is usually left as an exercise for the reader as it is never explained, or is perhaps so simple/basic/traditional as to remain unstated. And perhaps that is okay. However, we need to understand that these implementations represent a personal choice, and are unique in their own right. Such implementations do not represent a generic "kanban" prescription.

There is no kanban process for software development. At least I am not aware of one. I have never published one. Nor has Corey Ladas.

To summarize, we as software developers must use some process to develop software. Our choices range from XP to the Team Software Process and everything in between, but they do not include Kanban.

Kanban doesn't tell us anything about how to develop software. In fact, it's really a borrowed idea for us, one that predates the modern software development industry. It's focus is workflow visualization, eliminating waste by limiting work in progress, measuring and managing flow, eliminating confusion and depersonalizing issues by making process polices explicit, and nurturing a kaizen culture of continuous improvement through the careful study of the process under management and the application of models such as Systems Thinking and the Theory of Constraints. It can literally be applied to any discipline of work at large and small scales. It can help us a great deal to develop software more efficiently and with higher quality, but it cannot tell us how to do our jobs. It primes the pump, if you will, of continuous improvement, but without something to improve, it has absolutely nothing to offer.

So, the next time you say you're "doing Kanban," think again. Do you have a defined software process that you're using Kanban to manage and improve? Or are you just passing cards around on a board?