Kanban for software development is a newer kid on the block, at least in the US. Besides being just another word like Scrum that is not commonly understood in the English language, how does it stack up? Both Kanban and Scrum align with the well with the value system described in the Agile Manifesto. And they make an interesting pair.

As much as we love Scrum, even we would have to admit that it’s not perfect.  Nothing is. In fact, a large part of the literature describes workarounds for various deficiencies that Scrum presents to us in certain circumstances.

One of the more commonly noted deficiencies in Scrum is that it plans its work a whole Sprint at a time.  This “batch” planning process is often not agile enough to cope with the actual rate of change of requirements.  In fact, PlaceHolder Stories, discussions of mid-Sprint Re-planning, and discussions of renegotiating the scope of a Sprint are common deficiencies that teams must cope with.

The new kid, called Kanban, which solves some of these deficiencies and presents others, is becoming popular for software development projects.

Altogether, Kanban, Scrum, XP and many other agile methods rely on a task boards and index card like systems to simultaneously decompose and manage the work. What’s new about task boards and index card systems? Index card systems have been around at least since 1925, when the first one was formalized by Dr. Crawford and used later to build NASA rockets. Increasing task orientation is a well understood method for improving team performance and has been well documented since the 1950s. Our goal will be to highlight both Kanban and Scrum and then touch on why we need to reinvent them ourselves so often.

Learning Objectives

• An overview of Kanban
• An overview of Scrum
• Stacking them side by side
• The Power of Index Card Systems and Task Orientation
• Can one reduce or evolve from one to the other?
• Why do we repeat ourselves so often?