Scrum vs. Kanban

Author

Daniel Huchthausen

Why Agile

What are the reasons to use agile approaches in projects? Let’s answer this question with some figures: The 2013 “State of agile” survey found that the greater majority of people using the agile approach had a faster completion time (~73%) whereas only 6% claimed that projects took longer. Before people start working with agile tools they have expectations about the benefits, and after the projects completion they can say whether their expectations were met, or not. The following image shows the importance of several aspects and whether they improved by using agile methodologies or tools.

Based on the graph above it is important for 75% of the participants of the survey to accelerate the “time to market” (blue bar). For 83% of projects this aspect improved by using agile methodologies (yellow bar). This behavior can be seen for all of the shown aspects: important aspects improved for the vast majority of projects. What the survey didn’t talk about, are the reasons why for some participants those aspects didn’t improve.

The Agile Manifesto

There are a lot of agile methodologies and tools that have similarities and differences. All are based on the same principles, which are written down in the “Manifesto for Agile Software Development“. The manifesto states that certain aspects are more important than others and that it is necessary to internalize those facts.

For example the manifesto says that responding to change is more important than following a plan. An important factor for the success of agile projects is that the participants have the right mindset to work in an agile project environment. Another important advice is that you shouldn’t limit yourself to just one tool. Combine aspects from different tools that fit your needs, but be aware of the fact that you are combining several tools.

Since most agile methodologies are based on the same principles, many of them have quite similar approaches. Some of them use a lot of restrictions, others leave a lot of freedom. The Agile Manifesto states the basic principles and each methodology uses its own set of tools and rules. The challenge is to find the methodology and tools that best fit your needs. To support this we want to compare the two most widespread methodologies in more detail.

Comparison of Scrum and Kanban

It is said that working on projects with agile tools helps organizations to complete projects faster. This is because tools like Scrum or Kanban are process tools – they use transparency to show optimization potential and thereby help to work more effectively. They expect users to experiment by adjusting screws and by customizing the environment. Another similarity of the two tools is that they are both not very prescriptive – they provide a framework and leave space to adjust the methodology to your conditions. Nevertheless, Scrum is more prescriptive than Kanban.

Workload

One difference between the tools is, that Scrum limits the workflow by limiting the work in progess (WIP) indirectly whereas Kanban limits the WIP directly. In Scrum the limit of WIP is managed by the workload during one iteration, or sprint. In case of the following board the maximal workload is 4 (there can be a maximum of 4 cards in the WIP column), because there are only four cards. The Kanban board is different in one little detail, the 2 in the WIP column. This limits the WIP to two simultaneous tasks. Therefore it would be allowed to start with task C immediately, but task D can only be started after either B or C are finished. The Scrum team on the other hand is allowed to start the tasks C and D immediately.

Response Time for new Requirements

Another difference of the two tools is the way they respond to new requirements. Let’s say you have the following situation in your Srum or Kanban project and someone turns up and wants to add “E” to the board.

In which way do the teams react to the new card?

The Scrum team typically says something like: “Sorry, but we have committed to A, B, C and D for this sprint. Of course you can add E to the next sprint.”

The Kanban team would say something like: “Of course you can add E to the board. But to do that you have to remove either C or D, because the limit of 2 tasks is reached right now. Or you wait until we finished A or B.”

Depending on the timing for the new requirement, in Scrum the response time to new requirements can be something between the full length of the sprint and one day (in case the requirement comes up one day before the new sprint starts). Therefore the average response time is half the sprint length. In Kanban the response time is as long as it takes to get capacity available. This can be instantly (by removing another task) or the time it takes to complete another task.

Comparison

The following tables will show you several similarities, differences and the basic work rules of the two methodologies to point out their strengths and weaknesses. The comparison should also help you to find the approach (or certain aspects) you can use in your projects.

1. Similarities
Both…
… are pull scheduling systems. This means that the team chooses when and how much work to commit to.
… are based on continuous and empirical process optimization.
… emphasize responding to change over following a plan.
… are Lean and Agile.
… limit WIP.
… use transparency to dive process improvement.
… focus on delivering releasable software early and often.
… are based on self-organizing teams.
… require breaking the work into pieces.
… help to continuously optimize the release plan based on empirical data.

2. Work Rules
The different approaches of the two tools can be shown best by showing their basic work rules.

3. Differences
To emphasize the differences between the two tools a bit more the following table shows some aspects that are prescribed or optional in the tools.

As you can see, the two methodologies have basic similarities, but they are very different when you look at the the details. Those details become more clearly if you look at a less trivial example, that’s why we want to do exactly that.

A less Trivial Example

The following example represents a project that is less trivial than the one in the second part of this series. There is a product backlog containing several tasks and a production process that consists of several steps.

> In case of Scrum the team is in the first sprint, which consists of the tasks A, B, C, D, E and F. A is already done, B to E are at the moment in progress and F is still to do. During the upcoming sprints the team will commit to the tasks G to N.
> The Kanban board consists of the backlog from which maximal 2 tasks can be selected for priorization. The development section allows max. 3 tasks at once (tasks from both columns – ongoing and done – count). After the development the features need to be tested and after that they will be in the production environment and are thereby done. You can see that the board represents the different states of the production process.

The Scrum board will be reset after each sprint, whereas the Kanban board is persistent.

After a few Scrum sprints or simply after some time the two boards could look like this:

Das Scrum Team hat im letzten Sprint die Karten K bis N ausgewählt. 3 Karten sind gerade noch in Bearbeitung. Auf dem Kanban Board ist zu sehen, dass N und K gerade noch getestet werden und M schon implementiert wurde, aber noch nicht getestet werden kann.

Note: For Kanban it is not necessary that there is a maximal amount of tasks for each column.

The Kanban board, which contains more columns than the Scrum board, can help to optimize the process steps, because it is necessary to think about them in order to draw the board. It can also be very helpful to optimize the amount of allowed cards per column, because this can reveal bottle necks. The Scrum board and the partition of tasks into sprints helps to organize tasks and to think about reasonable packages. But remember, it is always possible to combine aspects of different methodologies and tools to find the board, rules and tools that fit your project best.

Other Agile Tools and Methodologies

Besides the two tools Scrum and Kanban there is a huge number of other agile tools and methodologies that serve as an inspiration for you. The more you read about them, the more you will see that they are based on the same principles (which are stated in the agile manifesto) and that some use the same approaches and methods. Here is a short list of some wide spread approaches that you could take a look into.

> Extream Programming (XP)
> Lean Software Development
> Feature Driven Development (FDD)
> Crystal Family
> Test Driven Development (TDD)

Conclusion

A Kanban board represents the workflow of a project whereas a Scrum board always consists of the same columns. Another big difference is that it is possible to limit the number of cards in certain columns when using Kanban while Scrum limits the WIP by restricting the number of cards in the Sprint Backlog.

Besides the two methodologies that were presented here there are numerous other agile approaches. Some of them are based on Scrum or Kanban. A very widespread approach is a combination of Extream Programming and Scrum, because both supplement each other very well. It’s up to you to find the methodologies, tools and rules that you want to use to accomplish the aims of your projects. Since there is no “one fits all” for all projects you have to experiment and try variations.

Interesting Links:

> http://www.extremeprogramming.org/

> http://en.wikipedia.org/wiki/Lean_software_development

> http://www.agilemodeling.com/essays/fdd.htm

> http://en.wikiversity.org/wiki/Crystal_Methods

> http://www.agiledata.org/essays/tdd.html

This post was originally published in our partner blog by the SCM-Manager Universe Team. There it was devided into 3 parts.