Kanban vs Scrum

Introduction

There are many different agile methodologies – Scrum, Kanban, XP (Extreme Programming), Lean, Crystal, FDD (Feature Driven Development), mutual hybrids, etc.
The two most common methodologies are Scrum and Kanban: according to various studies, the share of Scrum use is over 50%, Kanban and various hybrids around 15%.
Kanban vs Scrum is definitely not in competition with each other, their principles are largely the same and they are also used as a hybrid (ScrumBan). The goal of both frameworks is the same – to help manufacture a product or provide a service as efficiently as possible and to the customer with the greatest value proposition. Both methodologies share agile principles and values.
The choice of a specific agile methodology depends on the specific situation and the needs of the organization.

History

1990. In the 1990s, Dr. Jeff Sutherland and Ken Schwaber began to combine object-oriented programming with Japanese product development methods. The name “Scrum” comes from the rugby sports game and means players gathering in a circle, putting their heads together, and quickly discussing the game plan.
Scrum began to spread more widely in the world in 2002 with the popularization of the Agile Manifesto .

Kanban’s roots go back to the 1940s when Toyota was developing products, and it became more widespread a decade later than Scrum, after the method was adapted for development by David Anderson. The name “Kanban” means “visual sign” in Japanese, which denoted the use of a visual job tracking board in the automotive industry.

Kanban vs Scrum: Key Differences

Workflow

The main difference between Scrum and Kanban is the length of the development cycle – Scrum is about working in 2-week (1-4 week) cycles called sprints. A certain amount of work is taken into one sprint and the team’s goal is to complete the work by the end of the sprint.
The Kanban workflow is continuous and time-indefinite, with the team picking jobs from a constantly changing list of pending tasks as needed.

Limitations

Scrum has a limit on how many jobs can fit into one sprint to ensure that all jobs are completed by the end of the sprint.
Kanban has a limit on the number of tasks that can be worked on at the same time (WIP – Work In Progress), which helps to check that there are not too few or too many tasks in the work.

Plaques

Scrum and Kanban boards can both contain columns of your choice, usually using the statuses “pending”, “in progress”, “testing” and “done”.

On the Scrum board, only one sprint work can be seen at a time, and the pending work (Backlog) is in a separate view.
On the Kanban board, the pending work in the first column is always present and visible.
The Scrum board is cleared at the end of each sprint and recreated at the next sprint, the Kanban board is permanent.

The Scrum board belongs to one dedicated Scrum team at a time.
The Kanban board can be shared between different teams or people as needed.

In Scrum, the prioritization of tasks on the board is very important – the works with higher priority are located at the top. In Kanban, prioritization is not directly mandatory, but it is often used.

Changes

Scrum avoids modifying jobs within an ongoing sprint. New jobs can only be added to the next, pending sprint.
In Kanban, jobs can be changed at any time and as much as necessary.

Releases

Scrum releases to the production environment at the end of each sprint. Recently, however, the use of ad-hoc releases has also become more common.
In Kanban, delivery takes place on an ongoing basis, as part of a continuous process.

Roles

Scrum has three clearly defined roles:

• Product Owner, who manages new jobs and prioritizes
• Scrum Master, who helps the team follow agile Scrum principles and remove obstacles
• A development team that performs the work and has a strong collective responsibility.

There are no specific roles assigned to Kanban.

Team

The Scrum team does not have a direct leader or project manager, they are self-organizing and equal, despite different responsibilities. Scrum teams are cross-functional, i.e. the team has all the skills necessary for development.
The Kanban team also works on the principles of self-organization, but does not have to be multifunctional, but cooperation with other specialized teams is also allowed.

Events

Scrum uses specific events:

• Daily Scrum
• Sprint Planning
• Sprint Review
• Sprint Retrospective

Kanban does not directly define events, but often borrows from the Scrum framework, such as daily meetings and retrospectives, are used.

Metrics

In Scrum, the central metric for teams is velocity, which represents the total number of points scored in one sprint (e.g. 35 points). Velocity helps predict how much work will be completed in future sprints and when the expected deadline for completion of the development is.

Kanban usually uses two metrics:

• Lead time – the time it took from job description to job completion
• Cycle time – the time it took from the start of the job to the completion of the job

Lead time measures time from the customer’s point of view, Cycle time from the team’s work process.

Assessment

In Scrum, it is important to assess the volume and complexity of the work and assign point values to them. In Kanban, assessment is not strictly mandatory, but it is done if desired.

An important component of the Scrum framework is the Burndown graph. There are no directly defined graphs in Kanban, although they are of course used – e.g. a Cumulative Flow Diagram (CFD).

Kanban vs Scrum: Which Methodology to Choose?

When describing these two methodologies, generalizations are often made such as “Scrum is for product teams, Kanban is for service teams” or “Scrum is for complex work, Kanban is for simple work”.
In fact, these generalizations are not very valid, because many product teams are very efficient at developing products on Kanban that are far from simple.

To choose a method, it is worth asking the following control questions.

“Is this the first agile project for the team?”

If the answer is “yes”, then it makes more sense to choose Scrum, which is faster and more understandable to master when entering the agile world.

“How quickly does the team need to react to changes?”

If the answer is “very quickly, within hours or days”, then it is advisable to choose Kanban, which can be used to quickly bring requests for change to the team and do not have to wait until the end of the 2-week sprint. On the other hand, it is good to keep in mind that all kinds of urgent work disrupts the team’s workflow and concentration, and it may be wiser to sleep through the night, because the next day the level of criticality may seem significantly smaller.
Kanban is almost always used by different maintenance teams and DevOps teams.

“How often do you need to do exhausts?”

If the answer is “daily or every few days”, then choose Kanban, which works in continuous patch mode.

“Is it the development of a new application or product?”

If the answer is “yes”, then choose Scrum, which gives you better tools to make a Minimum Viable Product (MVP) with high quality and minimal cost.

“Is this a follow-up to the development and maintenance of an existing product?”

Choose the Kanban that is better suited for maintenance work.

“Do I necessarily have to choose between these two methodologies?”

Absolutely not. Once you’ve mastered the agile mindset and practiced it for a while, it’s a good time to start experimenting. Many teams work very successfully with different hybrids such as ScrumBan, Scrum/XP, choosing the most suitable practices for their conditions and wishes.
All agile teams are different, and experimentation and continuous improvement are key.

Summary table of the differences between Kanban and Scrum

Volume

the sprint

each sprint

The article was first published in Äripäev Tietovara in March 2020: https://teabevara.ee/et/app/it-juhtimine/metoodikate-scrum-ja-kanban-vordlus