When teams are going through an agile transformation, they often wonder whether they should organize using Scrum or rather choose Kanban.
Starting by following one of the two frameworks or methodologies is always a good idea if your team is not experienced in working in an agile environment. They are designed to support teams, understanding the intention behind agile project management and help them to get on track quickly. But when it comes to decide which approach suits their needs the best, your team might begin to struggle.
Ideally, your team can take that decision on its own. That would already demonstrate a basic understanding of the agile mindset: Agility comes along with trust, taking responsibility and being able to decide independently. Regardless of who is taking the responsibility of this decision, it should be made together as a team. They know their work best and can judge what would support their work. In order to take the right decision, you should understand the differences between Scrum and Kanban.
What is Scrum?
In a nutshell, Scrum is an iteration-based framework introduced by Jeff Sutherland and Ken Schwaber in the early 90s. Since then, it has improved and evolved in detail, but kept its fundamental rulesets. Basically, your team members will organize their work in a so-called product backlog. This is nothing else than a dynamic list of tasks that need to be completed in order to achieve a specific goal (e.g. building a product). Based on that, Scrum comes with some roles and ceremonies, which help shaping the foundation of continuous improvement and iterative product delivery:
- Product Owner
- Scrum Master
- (Development) Team
- Daily Standup
- Sprint Planning
- Sprint Review
- Sprint Retrospective
- Backlog Refinement
Every role has a different focus and responsibility. The Product Owner focuses on the numbers of the project. His or her goal is to ensure that the right value will be delivered. One of the main tasks of the product owner is the maintenance of the product backlog. You will continuously fill it with new requirements and tasks and prioritize it accordingly. The more you reach the top of the product backlog, the better structured and refined are the individual tasks.
The whole Scrum flow will be supported and facilitated by the Scrum Master. He or she takes care of the meeting facilitation, answering questions regarding Scrum and supports the team to resolve blockers that hold back your team from working efficiently.
While the Product Owner prioritizes the backlog accordingly, a proper discussion with the team is still necessary, so that everybody has the same understanding of the requirements. The Scrum Guide only provides broad rules for refining your backlog. They call it „an ongoing process“ which „consumes no more than 10% of the capacity of the [Development] Team“. In our experience, the backlog refinement process should be a regular meeting where the Product Owner discusses new important topics from the backlog together with your team. Your team members will be able to ask questions and the feedback can be integrated into the task in order to achieve a better understanding of the requirements of the specific task.
Within Scrum, the team is working iteratively, means that every iteration (usually two weeks) contains an agreed amount of product backlog items that define a specific goal the team wants to achieve. Before every iteration, your team discusses with the Product Owner in the Sprint Planning meeting what exactly can be taken into the upcoming iteration and ultimately, you form your Sprint Goal.
In Scrum, an iteration is called a Sprint. When the Sprint begins, your team will meet daily for the Daily Standup meeting for 15 minutes to talk about what they work on right now as well as raise impediments and valuable information. The focus in this meeting is the Sprint Goal. At the end of the Sprint, your team will present their results to the stakeholders in the Sprint Review Meeting. After that, your team will meet for the Sprint Retrospective Meeting – the most important meeting for your team. There, your team members have the chance to open up within the team, reflect and discuss what went well and what can be improved after this Sprint. Once this is done, a new Sprint will be defined in the Sprint Planning meeting, and the process starts again.
What is Kanban?
In contrast to Scrum, Kanban can be considered as more lightweight. It is not a framework but rather a methodology. This means you will neither find any defined ceremonies nor any roles in Kanban. Initially Kanban has been used at Toyota to plan and control their production. Its goal is to achieve an organized flow. Originally, Kanban was introduced with two key features: Visualize your work and work in a pull-based system.
Visualizing your work is a key tool in Kanban. The word Kanban is a Japanese for a sign or a card. And that is the intention of Kanban: Using cards or signs on a board to visualize your work – the Kanban board. It represents your workflow, based on at least three columns. Usually, these columns are called: Open, In Progress and Done. For some teams, this already represents their workflow, other teams might need more columns to properly represent their workflow. The goal of the Kanban Board is to visualize the path a task must go through, from its creation until it is done. Ultimately this visualization will help the team to identify bottlenecks in the workflow. Adaption and improvements will be made in order to resolve these bottlenecks.
The second feature is a principle of Lean management: the pull principle. In general, it defines a way of how you deal with your work. You first pull the next task out of the bucket once you are finished with the one before. In our case, we can say that we first pull a new task to the In Progress column once there is capacity. It has the benefit that it represents the current demand of work. Working in a push principle, you can anticipate the demand of work from the outside. This could lead into situations where there is not enough work or too much work in the workflow. Based on that idea, David J Anderson has evolved that system into a management method with the aim to improve service delivery and evolve business to be a „fit for purpose“. He took the two key features and transformed them into a set of six properties and four principles.
- Visualize the workflow
- Limit work in progress
- Focus on the flow
- Explicit Policies
- Feedback Loops
- Improve (Kaizen) continuously and collaboratively
- Start with what you are doing now
- Agree to evolutionary change
- Respect current Processes, people, roles and titles
- Every team member is a leader
In order to use Kanban successfully in your team, you should follow every property and principle closely. The big advantage of Kanban is that you can just put it on top of how you currently work in the team. There is no immediate change of your workflow necessary. You just start with a Kanban Board, investigate the bottlenecks and resolve them in order to improve your workflow. Kanban, as well as Scrum, is aiming for a constant process of improvement and adaption.
Which way to go?
According to the 13th annual State of Agile report, 72% of Software teams are practicing Scrum or a hybrid that includes Scrum. That is also the reason why teams vote for Scrum. Their rules and ceremonies are straight forward and easy to understand. But teams often fail when it comes to the execution.
Ken Schwaber compared it with learning how to play chess: „I equate Scrum to the game of chess. You can read the official rulebook for chess. The moves, players, sequences, scoring, etc. are all specified. Learn them. Then you can play chess.“ Many people would agree with him that you will not win the chess world championship with this amount of knowledge, but you certainly are able to play it. You probably will lose a lot at the beginning, and you will learn from the failures you made and become a better chess player over time.
The same applies for Scrum. When your team is performing their first Sprint, it will probably make a lot of mistakes and might not even reach its Sprint Goal. Reflecting on the mistakes the team did and learn from them, is the first step of using Scrum successfully. Scrum is the ideal framework for it. All the ceremonies intend to support the team improving over time.
On the other hand, there is Kanban. At first sight, it looks that using Kanban is the easier way to become an agile team. Kanban is quite lightweight. There are no defined roles or ceremonies necessary. Many teams argue that only minor adaptions need to be made in order to implement Kanban. „We only need the Kanban board. The rest is already there.“ In fact, the opposite is the case. Especially because of that, it is harder to evolve into an agile team. A missing expert of the agile topic makes it harder for the team to follow agile principles. Nobody can support them or give feedback in everyday situations. Missing ceremonies makes it difficult talking about the right topics for unexperienced teams. Especially reflection on their work is missing quite often in teams trying to work with Kanban.
So which way should you go then?
We at amiconsult had the chance to support and consult many teams, helping them to make the right decision. One distinction can be the division into complicated and obvious work or goals. Our experience is that Scrum works well if there is a complicated goal the team should aim for and the way how to achieve it is unknown for the moment. Due to the iteration-based approach, your team always has the chance to reflect each step it takes and check if it still moves to the anticipated goal. The ceremonies help the team to stay on track and support talking about the right things. An experienced Scrum Master will also make sure that you get the best knowledge out of working with agile tools. Additionally, with Scrum, teams can demonstrate first product increment fast, so that the stakeholder gets an idea what the result will look like quite early. So, if you want to see first results of your manufacturing product fast and focus on that, then Scrum is a good option for you.
In contrast, amiconsult has successfully supported teams using Kanban in areas where the teams are more service oriented. Especially support and maintenance teams benefit from Kanban. They usually need to react on service incidents and requests fast, but their tasks are more based on best practice and clear for the team. Additionally, their work is generally similar and they know their topics well. Usually their backlog is quite dynamic, so the priority can change fast. Using Kanban will help you to react in these situations faster than with Scrum.
In case you need support in finding the right way becoming agile, feel free to contact us!