Explaining Kanban to Scrum Adopters

Today is the debut of our "Getting Started with Kanban for Software Development" Refcard, which should give you a better understanding of this work process technique.  Even if you've done your research on Kanban, the Refcard will still be a great reference tool for implementation.  For those who have only a high-level understanding of Kanban, this article will be a complimentary resource to the refcard, especially if you've experienced Scrum but haven't tried Kanban yet.  One of the best ways to understand something more deeply is to compare it to a similar idea that is more widely understood.

According to Forrester, Scrum is the most popular agile methodology by a strong margin.  Contrary to various misconceptions, Kanban and Scrum are not mutually exclusive.  Thought leaders like Henrik Kniberg have written books about how Scrum and Kanban can be used simultaneously (Scrumban = Kanban with iterations).  Comparing Scrum and Kanban is difficult because in many ways, it's an apples to oranges comparison.  Scrum is a methodology and a framework while Kanban is a technique.  However, Net Objectives CEO Allan Shalloway believes that there is some merit to comparing and contrasting the two concepts and he, David Anderson, and the kanbandev yahoo group all discussed this comparison in-depth last month.

David J. Anderson, the man who pioneered the Kanban technique's basic principles, had this to say about Kanban and Scrum:

"At one level Scrum is presented as quite a prescriptive project management process - Sprints, Scrums, Sprint Planning, Retrospectives, Demos etc etc. The leadership of the Scrum community is anxious to point out that Scrum is much more than this - it is a framework for provoking change and emergent behavior in organizations.

Kanban is not a project management or software development lifecycle method. It is an approach to change management - a framework for catalyzing change in an organization. So it differs from Scrum in that it cannot be used as a process to get work done. It needs to be applied to an existing process. That existing process can be Scrum, or equally any other lifecycle method with which you are familiar, or something that has no name - an ad hoc process. However, as a framework for change Kanban and Scrum can be compared as alternatives."  --David J. Anderson

Some people with only a light understanding of Kanban tend to think that the only difference between it and Scrum is the absence of iterations in Kanban.  Shalloway says there are several primary differences to consider.  First, there are explicit policies.  Kanban says that you should have these to define workflow and increase what the team members learn from it.  While team learning in Scrum usually comes from retrospectives (which usually take place on a weekly, bi-weekly, or monthly basis), users of Kanban have a mini-retrospective every day when they review the Kanban board.  Kanban also entails the management of Work in Progress (WIP) to keep the team focused and avoid delays between work stages.  Scrum will sometimes have many items still in the test stage at the end of a sprint.  This is why Scrum teams can benefit from implementing Kanban's WIP and explicit policies.

Kanban also provides a greater visibility of the process, not the just results, says Shalloway.  This helps managers be more effective in removing impediments to that process.  Inclusion of management is a key area of difference between Kanban and Scrum.  Scrum tells managers to trust the team and never interfere, while Kanban lets managers help the team see all of the things they need to do and provide coaching when necessary.  In Kanban, the manager can better understand the team's process and understand how adding something to their plate and exceeding the WIP limits will cause them to slow down.  In the 'black-box' nature of the Scrum sprint, managers are unable to understand why adding another task will have a drastic effect.

Another difference between Kanban and Scrum is Flow vs. Iterations.  The iteration approach works for Scrum so long as the team is able to seriously enforce the completion of designated tasks by the end of the sprint.  Some teams have trouble doing this because their work is dependent on issues they cannot control.  Kanban teams don't need iterations, but a cadence of input and delivery can be helpful.  This well-known difference however, is not the biggest difference between Scrum and Kanban: Controlled Change Management.  Unlike Scrum, Kanban is able to manage the rate of change in your transition.  In Kanban you can slowly ramp up the rate of process change by managing your WIP limits.  Scrum often requires sudden, dramatic changes to an organization (scrum masters, cross-disciplinary training, etc.).  

Shalloway summarized these differences on a table:



Shalloway says that there are dozens of case studies showing significant work process improvement by explicitly defining policies.  It should allow your development team to streamline your workflow at your own pace. Check out the Kanban Refcard and give it a try in your development team.