Written by Paul D. Race for BreakThrough Communications, btcomm.com. Copyright © 2017 All Rights Reserved.

So far our articles have been explaining various aspects of Agile Scrum methodology. But certain of the teams I work with have found that another methodology works better for their planning and processes than Scrum. That is Kanban, an outgrowth of early Just-In-Time methodologies that were originally developed by the Japanese automobile industry.

The term “Lean” was eventually applied to a family of related approaches, and those approaches migrated into other industries, including software development. One aspect of “Lean” that is almost universal, and even used in Scrum methodology is the “bulletin board” that shows how work items are making progress from the planning to implementation stage.

The term often used for these bulletin boards is Kan Ban, or Kanban, taken from two Japanese words that mean literally “sign board” ( ). In Japanese, this phrase could apply to the billboards you saw driving in to work this morning. But in Agile methodologies, it means a specific kind of billboard that shows the stages of progress for individual tasks.

Different teams may use different labels and different numbers of columns. (The color-coding on this Kanban board is arbitrary.)

As much as this may look like similar charts used in Agile Scrum, they are used differently, as a result of core differences between the methodologies.

Cycles Versus Continuous Flow

The biggest difference between Scrum and Kanban processes is that Scrum uses iterative cycles, while Kanban attempts to deliver a continuous flow of improvements.

Both methodologies have a prioritized backlog of tasks (enhancements, fixes, etc.) that need to be done.

A Scrum team will take on the number of tasks they think they can do within a predefined timespan. Ideally, all planning for this “sprint” is done at the beginning of that timespan, and the success of each task is evaluated by or at the end of the sprint.

A Kanban team will generally assign each task to the next person who is ready and qualified to take it on.

So the Kanban-like charts used by Scrum teams represent a single sprint, usually two, three, or four weeks. The left column contains, not the whole backlog, but only the tasks that the team agreed to complete in the coming sprint. Ideally, each sprint starts with the new tasks all lined up in the left column, like horses in the starting gate. During the Sprint they move from left to right at different speeds. But if all goes well, they’re all in the right column by the end of the sprint.

The name and number of each column in the graphic below differs from team to team. The point of the graphic is to show that – ideally – each “chunk” of tasks selected for that sprint should start and end at the same time.

Kanban teams, however, do not start and stop and start and stop. Once a Kanban project has begun, you will never see the tasks lined up in a row again. As tasks move across the board toward completion, new tasks are assigned.

A true Kanban board will always look more like the board in the middle of the graphic above than like either of the other two.

Three Principles of Kanban

For the continuous flow of projects to work, several ruling principles must be observed. The three most important are probably:

1. Visualize the Workflow – use the Kanban board as a constant reminder of how things are going.
2. Limit Work in Progress – avoid having more tasks active than you have people to do them.
3. Manage Flow – Identify bottlenecks and ways to reduce their impact. As an example, in the Kanban board at the top of this article, a “buffer” has been put before the “in progress” column. This “holding area” for tasks that are ready for the next stage reduces the chance that a developer will finish with one task and have nothing in the pipeline.

Other Differences

Of course, there are many other differences. These include:

• Less Organizational Upheaval – Adopting Scum methodologies usually means changing reporting structures, job descriptions, and even daily schedules, while many organizations can adopt Kanban without changing any of those things.
• Assignment Versus Volunteering – As a related difference, Scrum team members generally volunteer for their task assignments, while many Kanban team leaders assign tasks in a more traditional paradigm.
• Distinct Versus Overlapping Skill Sets – Scrum teams usually include people with different skill sets, so that a single enhancement or bug fix may work its way through multiple team members as it’s designed, developed, and tested. For Kanban to work at its best, there must be overlap of skill sets, so that – in most cases – tasks can be assigned to the next available person, who may take it through the entire process. This way tasks aren’t stuck waiting on individuals with specific qualifications.

One of the most interesting differences is in the way teams track velocities – metrics that demonstrate whether a team is becoming more efficient over time. But that will have to wait for a different article.