Karl Scottland, asked me to give you more precice information about Scrum and Kanban. He http://availagility.wordpress.com/2008/10/28/kanban-flow-and-cadence/

A Kanban system is a mechanism for controlling the work in the software development system.  Kanban can be defined as “visual card”, as shown below – kindly written for me by Kenji Hiranabe [?] at Agile 2008. read more about his article here.

After reading his article, I do not see in which way my understanding of this idea is wrong.

Toyota describes KANBAN:

Kanban

A small sign that is the key control for the Just-In-Time production; it serves as

1. Instruction for production and conveyance
2. Visual control tool to check for over production and to detect irregular processing speeds
3. Tool to perform kaizen

So if we agree that it is a TOOL, that means CARD than we can not explain a way of development as KANBAN.

What Kirk explains is a traditional work process control system in which work is broken down into simple tasks:

What does a Kanban System look like for software development?  Very simply, there is a queue of work, which goes through a number of stages of development until its done.  When work is completed in a stage, it goes into a downstream queue for the next stage.  When someone needs new work to do, they pull it from their upstream queue.  This can be depicted as below. Kirk Scottland

This is definitely not SCRUM or the idea of working creatively together. It imposed specialization. I do not say that I can not see that it is a much nicer TASKBOARD but this is the only thing you get.

The  conclusion of Kirk and obviously a lot of others ….

The consequences of using a kanban system are that the Product Backlog can be eliminated, because the immediate queue is the only work of interest, timeboxed iterations (i.e.Sprints) can be eliminated, because work is pulled as necessary, and estimation can be eliminated, because work is not planned into iterations. — Kirk Scottland

Is right – if you do have a production system. You can use this system wonderfully in maintenance teams. Who do tons of bug fixed – working on the crap the others did not care about. But … it is not old. The idea that people get here was explained by Jeff Sutherland years ago. He mentioned a Scrum C version. With a continuous stream of backlog items. He implemented such a thing in Patient Keeper.

The terrible danger of this approach is that we put the the thinking about the features before the development. KANBAN might work in stable environments as a production system needs and prerequisites, but it will not help a team to overcome complexity.

Scrum was and is not a process, it is not even a form of telling people how to work. It is a way to control choas, control complexity and help teams to have a creative, empowerd and fullfilling work.

Again — KANBAN is a TOOL it is NOT a mindset, or a new way of enjoying work. (btw – did you remember what happened to the japanese work-force after working in an KANBAN environment ?)

Why do we always look into processess of the manufacture world. Why does nobody tries to see the value of the work-processes that works in companies like PIXAR or IDEO. These are the companies in which creativity and coolness lifes. Not in old-school toyota lean production type delivery units.