Kanban introduction and comparison with Scrum

How Kanban approach with work in progress is different from the one in Scrum?

DNA is the same between Scrum and Kanban. They follow the same Agile Values and Principles of the Manifesto. Main difference is that Scrum is iteration oriented, Kanban is flow oriented and this impacts the way work in progress is limited.

Note that this framework enables different level of priorities so there is typically a fast lane to pass features that are in standard priority lane.

---

What is Kanban and how it is different from Scrum?

Before going in more detail, let’s stress out that the framework we are referring to here, is the Kanban for IT. It is coming from the original Factory Kanban of Toyota. Mindset and purpose are the same but principles and practices are expressed a different way.

To begin with, what are the 4 principles supporting an incremental transformation?

• Firstly, principle 1, Start With What You Do Now: this framework can overlay with the team’s current workflow and its way of working. This enables an incremental and non-disruptive change.
• Secondly, principle 3, Respect the Current Process, Roles & Responsibilities: the third principle also stresses that in addition to workflow, there is no need to disrupt roles and related responsibilities.
• Thirdly, principle 2, Agree to Pursue Incremental, Evolutionary Change: but there should be a will to continuously improve.
• Fourthly, principle 4, Encourage Acts of Leadership at All Levels: and this change is the responsibility of all not just managers.

Furthermore, what are the 6 practices?

This framework does not propose roles. There is no artifact or ceremony prescribed either, even if you can deduce some of them from the practices.
To facilitate the comparison with Scrum, we will gather those practices and illustrate them with typical Kanban implementation based the same split as Scrum: artifacts, roles and ceremonies.

In addition, what are the usual artifacts in a Kanban implementation?

Kanban board: supported by 3 of the practices of this framework

• Visualize the Workflow: the board displays the actual workflow of the team. It is more elaborated than the Scrum workflow for the sprint, the iteration (Todo, In Progress, Done). It can be something like analysis, design, code, test, validate by customers, implement.
• Limit Work in Progress: for each step of the workflow, a work limit is set to enforce limitation of work in progress and to support pull approach. A feature moves to the next step only if the WIP limit allows it. This prevent jamming the system.
• Make Process Policies Explicit: conditions to enter the first step and complete each step is made explicit so all the team share the same understanding.

The cumulative flow diagram: supported by 1 of the practices of this framework

• Manage Flow: the Kanban board helps to manage the flow making the bottlenecks visible. Metrics are captured thanks to the cumulative workflow diagram that enables factual performance monitoring.
  • Vertical axis is the total of all work in progress per date. It is usually split by steps.
  • Horizontal axis is the total elapse time between the creation or start date and the completion date per feature (called lead time for the first and cycle time for the second). It is also usually split by steps.

Comparison of Kanban typical artifacts with Scrum artifacts

• The Kanban board addresses the needs covered in Scrum by the sprint backlog and the product increment.
• The policies defined for each step of the workflow cover the needs supported in Scrum by the Definition of Ready and the Definition of Done.
• The Kanban board may not be enough to collect all the pending requests of the Customers so there may be a need to set a product backlog like in Scrum.
• The Cumulative flow diagram supports factual performance monitoring and covers the needs addressed in Scrum with the statics around the velocity (feature workload delivered sprint after sprint).

Moreover, what are the usual roles in a Kanban implementation?

This framework does not define roles. Practice is to have a person playing the PO role an another one the Scrum Master with the same responsibilities than in Scrum.

At last, what are the usual ceremonies in a Kanban implementation?

This framework does not define explicitly ceremonies. But some of them are implicit. When implemented, they have the same agenda and audience than in Scrum. As there is no sprint in this framework, there is a need to define the frequency of those ceremonies.

• Meetings to prioritize the next features to come and share the underlying vision.
• Then, meetings to demonstrate a feature or a group of features to the PO and Subject Matter Experts.
• Furthermore, meetings to have a retrospective on a given past time period. They are supported by the 2 remaining Kanban practices:
  • Feedback Loops
  • Improve Collaboratively (using models & the scientific method)
• At last, daily meetings to share on achievements, next steps and issues if any, and leverage visual management with the Kanban board.

---

When to use Kanban and when to use Scrum?

Here is a non exhaustive list of questions to choose between Scrum of Kanban depending on the team context:

---

What’s next? Learn more about the other main framework to implement Agile: Scrum

To learn about Scrum or Agile principles, review my other posts. There are also plenty of other materials around Agile and Agile at Scale. Here is my post to have an introduction to Agile at Scale.

Do you want to learn more about Kanban? Here are some valuable references

• The excellent whitebook from Henrik Kniberg.
• Some books about Kanban in IT:
  • From Donald Reinertsen
  • From David Andersen
• Other materials around Toyota Lean System:
  • Toyota Kanban principles
  • Toyota Production System