Kanban vs. Scrum - How to Find the Right Project Framework

1. Waterfall, lean or agile?
2. What is Kanban?
3. Process of a Kanban procedure
4. Kanban summarised
5. What is Scrum - a simple explanation
6. Scrum process
7. Scrum summarised
8. Commonalities between Kanban and Scrum
9. Differences between Kanban and Scrum
10. When to use Kanban, when to use Scrum?
11. Conclusion: Which framework is right for you?

Waterfall, lean or agile?

If you're dealing with the topic of project management or project management tools like awork sooner or later you will encounter the terms waterfall, agile or even lean. But what exactly does this mean? To gain a better understanding of Kanban and Scrum, we'll briefly explain each method:

• Waterfall: In the waterfall model, the project proceeds in a linear fashion and is divided into individual phases. These phases are clearly separated from each other and always form the prerequisite for the subsequent project section. The disadvantages of the Waterfall often lie in the practical implementation: In reality, the individual phases cannot always be clearly separated from each other. Moreover, the waterfall method is inflexible if something needs to be changed in the product along the way. For today's projects, this approach is therefore often no longer up-to-date. Processes occur faster, expectations and requirements of a product often change during development. 

• Lean: Lean management is an approach that focuses on the efficient design of the value chain. It looks at which activities can be better coordinated, and how unnecessary tasks can be avoided. This approach is especially popular for products and projects that exhibit a certain degree of standardisation.

• Agile: Agile project management, too, ultimately aims to improve processes. Agile methods, however, place a stronger emphasis on flexibility compared to lean management. An important principle of this approach is that the project remains open to changes in requirements. Therefore, agile methods are popular in software development.

Simply put: While lean management focuses on the process, agile management is about flexible adaptability to the product.

So which of these categories do Kanban and Scrum fall into? In fact, it is the case that both frameworks have characteristics of lean and agile management. Why that is, you'll find out in the following sections.

What is Kanban?

Kanban, which means 'card', comes from Japan and was developed there by Taiichi Ōno in the 1940s at the car manufacturer Toyota. At the heart of Kanban is a continuous process, which acts according to the supermarket principle (alternatively pull principle): A consumer (also called 'sink') draws the resources necessary for his work step from a so-called buffer warehouse, which in turn is filled by suppliers ('source'). Instead of a large central warehouse, the individual, smaller buffer warehouses are distributed along the production line. This keeps communication and procurement channels short and transparency increases. 

Two important elements for production control are the Kanban card and the Kanban board:

• Kanban card: This card serves as a medium to communicate the removal (and therefore necessary 'refilling') of a resource from the buffer warehouse. The Kanban card contains important information about the quantity and quality of the removed goods, so that the body responsible for the buffer warehouse can replenish the stock promptly. Kanban does not provide for the buffer warehouses to be produced too much in advance. This prevents the capital from being tied up through too high inventory levels over a longer period of time. 

• Kanban board: The Kanban board can be seen as an alternative to the Kanban card. Such a board visualises the production process using several columns, in which the individual subtasks are arranged. These columns are usually divided into the phases 'Planning', 'To be Done' and 'Done'. The basic principles of a Kanban board are visualization, limitation of unfinished work, and constant improvement of efficiency.

Your Kanban board could look like this:

Process of a Kanban procedure

In Kanban, the production chain is initiated by the last production stage. As soon as the inventory in this production stage falls below a certain value, the preceding production site is signaled that the buffer warehouse needs to be filled up. The upstream unit takes resources from its own buffer warehouse to start production, which may in turn initiate earlier production. 

A simple example of this would be the supermarket: Customers (sink) take goods from the shelf (buffer warehouse). As soon as it is empty or falls below a certain minimum stock, the shelf is refilled by the employees (source). 

Kanban summarised

Kanban is a process in which the actual consumption controls the production chains. Overproduction is thus avoided. The pull principle and the decentralised buffer warehouses not only promote the self-responsibility and self-organisation of those involved, they also shorten communication paths and increase transparency. 

Kanban is particularly suitable for standardised products that are to have low variance and for which there is a more or less constant demand. Kanban primarily focuses on cost-optimised production, which is why it is often counted as lean management. Due to decentralised storage and the resulting flexibility in production, the framework also has characteristics of agile management. You can find even more information about this method in our other guide to the 7 best tools for digital Kanban boards.

What is Scrum - a simple explanation

In addition to Kanban, Scrum is one of the most popular methods for project management. It was developed in the 1960s by mathematician Tony Buzan. Since the early 2000s, the method has been popular in software development, but it can essentially be used in all areas. While there is a more or less linear process sequence in Kanban, the Scrum method is iterative, i.e. repetitive. 

In Scrum, the project is divided into several cycles called Sprints, which last between one and four weeks. After each sprint, the work results and internal processes are evaluated in order to continuously optimise both the product and one's own way of working. In essence, Scrum consists of three pillars: the three roles, the five events and the three artefacts.

• Roles: Scrum assigns a role to each person involved in the project: the Scrum master, the product owner and the developers. The task of the Scrum master is to ensure compliance with the Scrum rules (more on this later). The product owner is responsible for the requirements of the product and prioritises the tasks to be completed. The developers are the team that autonomously works on the fulfillment of these tasks during the sprint. 

• Events: Scrum recognises five events: sprint planning, the sprint itself, the sprint review, the sprint retrospective, and the daily scrum. In the sprint planning session, the tasks to be accomplished within the coming sprint are defined. In addition, the approach and duration of the sprint are determined. During the actual sprint, the developers work through these tasks and inform themselves in short daily scrums about the current status of the project. After each sprint there is a review in which the previous work results are assessed and often already presented to users. In the team-internal sprint retrospective, one's own work is once again evaluated to increase efficiency for the next sprint.

• Artefacts: The artefacts in Scrum consist of the product backlog, the sprint backlog and the increment. The product backlog contains all requirements for the product and the tasks to be completed. From this, the sprint backlog is fed, which contains the subtasks for the upcoming sprint. The increment is the work result that stands at the end of a sprint. 

Visualised, a Scrum process looks like this:

Scrum process

As already mentioned, the Scrum method is iterative, i.e. it consists of repetitive cycles. Scrum starts with a planning session. In this, the upcoming tasks for the sprint are determined and recorded in the sprint backlog. In the following sprint, the developers work on implementing these tasks. 

What is important here is that no changes to the tasks or priorities are made within a sprint. In addition, the development team operates completely self-organised. The task of the Scrum master here is merely to enable the developers to work smoothly. In the Daily Scrums, which last a maximum of 15 minutes, the individual actors report on the current status of their task. At the end of the sprint, the team presents the results (increment) in a review and reflects on their own approach in the retrospective.

Scrum summarised

Scrum is an iterative framework for project management. To this end, the project is divided into several shorter sprints, in which the tasks are worked through by the developers in a self-organised manner and without further external influence. Daily, short update meetings and more comprehensive evaluations after each sprint increase transparency and promote process optimisation. 

Although changes to tasks are not planned for in the sprint, Scrum focuses on agile management: requirements for the product and the tasks are constantly reassessed and, if necessary, adjusted as part of the review and planning session. Flexibility is in the foreground. Another important feature of Scrum: The duration of all events is fixed in time. For example, a sprint can last a maximum of four weeks, the planning session a maximum of two hours per sprint week. How long the individual events last and much more you can also find out in our glossary article on the topic Scrum.

Commonalities between Kanban and Scrum

As has already become clear, Kanban and Scrum have some commonalities, which we summarise here once again: 

• Agile and lean: Both Scrum and Kanban have characteristics of Lean Management and Agile Project Management. Both strive for continuous process and cost optimisation of Lean Management and the adaptability of Agile Management. In the case of Kanban, this is achieved by the consumption controlling the production quantity. In Scrum, efficiency is evaluated and optimised through reviews and retrospectives.  

• Self-organisation: Both methods promote the individual responsibility of the participants. By eliminating central control points (for example, the central warehouse in Kanban), employees largely act independently.  In Scrum, self-organisation is particularly prevalent during sprints, when developers organise and process their tasks.

• Transparency: Short communication channels and openness are two central elements in Kanban and Scrum. In Kanban, this is manifested, for example, in the procurement routes from the buffer warehouses, whereby the responsible parties always know how many resources are still needed and available. In Scrum, this is achieved through the aforementioned retrospectives and the exchange in the Daily Scrum.

• Work-in-Progress Limitation: Both Kanban and Scrum are designed to limit concurrent tasks in such a way that production is cost-optimised. In Kanban, this is reflected in the fact that replenishing the buffer warehouses only begins when a minimum stock level is reached. In Scrum, this is evident because each Sprint contains a limited catalogue of tasks. 

• Pull principle: Both frameworks work according to the pull principle. In Kanban, this is done, for example, in the form of the Kanban board, in Scrum as part of the planning session.

Differences between Kanban and Scrum

Despite all the commonalities, there are also some differences between Kanban and Scrum:

• Roles: Scrum assigns everyone involved a role. This division does not exist in the Kanban method.

• Rhythm: In Scrum the development happens in several short sprints. Kanban, on the other hand, prescribes a constant flow of production. 

• Time planning: Scrum sets the maximum duration for all events, in Kanban this is optional. 

• Predictability: Scrum is especially suitable for projects whose requirements and end results can still change with the progress of development. In Kanban, it is important that the product is largely standardised and the outcome is already known.

When to use Kanban, when to use Scrum?

So when do you use Kanban and when do you use Scrum? It helps to include in the decision whether your project is rather simple or complex. But what does that actually mean?

The Stacey matrix, depicted below, can help you categorise. It divides the requirements for a project in four stages: simple, complicated, complex and chaotic.

A project is considered simple when the most important factors for getting the job done are known - these include things like required work materials, targeted timeframe and desired result. If most of these factors are known but some are unknown, the project is complicated. A task is considered complex when the relevant things are mostly unknown and only a few are known. If very little is known about the factors, a project is considered chaotic.

Kanban is mainly used in the areas of simple and complicated project application. The reason: Kanban is excellent for optimising processes that are standardised to a certain extent and that are to be optimised along the value chain. 

Scrum is particularly helpful when you enter the complex area of the Stacey matrix. Complex tasks with many unknowns cannot usually be planned in full - but such a plan is not envisaged in Scrum anyway. Instead, the inherently complex task is divided into many small stages, during which the approach and prioritisation of tasks can be adjusted again and again. For this reason, Scrum is often used in software development.

Conclusion: Which framework is right for you?

Whether Kanban or Scrum is the right approach for you depends on many factors - these include the complexity of your project, the way you want to work together in your team and not least the type of product you are working on.

To make planning and execution easier for you, there are now numerous project management software, with which you can coordinate the processes and your team in a snap. We have already listed some of the most popular tools among the users on OMR Reviews below for you:

Jira

Notion

Trello

Asana

monday.com