Scrum vs. Kanban

Karl Scottland, asked me to give you more precice information about Scrum and Kanban. He

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:


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.


5 responses to “Scrum vs. Kanban

  1. Boris
    Kanban is more like Type C development than Scrum. Overlapping phases rather than timeboxes.
    Kanban does not impose specialisation, but allows harnessing specialisation while collaborating as a team.
    Kanban does not require thinking up front. In fact the opposite. It tries to limit up front investment.
    Finally, Kanban IS a tool. Not a process. Its not prescriptive.
    Karl (not Kirk)

  2. Pingback: #notkanban « AvailAgility

  3. Hi Karl,
    so in fact you agree with what I try to get to people. I do not doubt that Kanban as a tool might help people to structure the work, but obviously it is not a “better” Scrum or can replace Scrum. Type C development (Jeff Sutherland) had been Scrum. Scrum does not force people to do do any practices. Scrum tries to help people to “Deliver every month, or faster” and “inspect and adapt” by “asking the team” how to be able to “deliver every month” faster.

    The only thing I do not really understand is, why we look for improvements of work in OLD, and very production like process models. Why not looking into models from a total different world: Science, Art, Creativity. Why do we always try to re-implement bureaucracy?

  4. Boris,
    Yes, I agree that neither Scrum and Kanban silver bullets or alternatives.
    However, I do not see that kanban is implementing bureaucracy. It puts boundaries in place like Scrum does.
    I recommend Managing the Design Factory by Don Reinertsen for a good understanding of how Lean ideas can apply to creative processes.

  5. I just wrote an article called “Kanban vs Scrum”, trying to clarify how they relate.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s