Scrum vs. Kanban: Why I Recommend Kanban for Most Teams

As feedback for my book (german only at the moment, sorry!), I received a comment that it would be good to explain why I recommend Kanban in the final chapters. A good opportunity for this blog post.

Before we dive into the details, a quick disclaimer: This is based on my personal experiences.

What are Scrum and Kanban?

Let's start with a look at Wikipedia. What does it say about the "methods" Scrum and Kanban?

Scrum is an agile team collaboration framework commonly used in software development and other industries.

Kanban is a lean method to manage and improve work across human systems.

And there you can already see the biggest difference in the self-conception of these "methods". While Scrum emphasizes "team collaboration", Kanban mentions "work". Scrum focuses on the team and the people, while Kanban puts the work at the center. These are two fundamentally different things, and you can notice that in practice as well.

Notice anything? Neither of the definitions says anything about "project management".

My Background

I work in an agency that develops and customizes software for clients. I implement these activities with my team (currently seven people). The work is heterogeneous: smaller tasks (effort under one day) take place parallel to larger activities (50 days and more).

With this team, I used Scrum "by the book" as a method for over five years in the past. We had a certified Scrum Master, and I was a certified PO.

After these five years, we switched to Kanban. The reasons for this will become clear to you after reading the article.

How we can categorize work

We will talk a lot about work ("the stories") today. To help you better understand how different work can be, let's look at the Stacey Matrix.

On the X-axis, we see a classification of work into "clear" and "unclear". Here, experience is the topic. Have we done this type of work before? Do we already know solutions?

On the Y-axis, the clarity of the requirement is plotted. Is it clearly formulated or is there great uncertainty?

With the Stacey Matrix, you have a tool at hand with which you can go through your stories from the last few weeks. If you are more in the "Simple" range, a method like Scrum or Kanban is nice, but not necessary.

The further you move towards the top right, the more effective it can be to apply a method. Which one? Let's look into the next chapters for that.

When Scrum has its strengths

Besides many small details, there are a few outstanding points for me that are crucial for Scrum to work. These are for me:

• You need an environment in which everyone involved - yes, everyone, not just the Scrum team - has understood that there is an uncertainty about the product to be developed. With the Scrum method, this uncertainty can then be managed (through iteration - feedback - adaptation - iteration).
• You must be able to commit to an increment, and it must be impossible for interrupters to force you to break your commitment.

What do I mean by that? Too often I have seen and read that, for example, management or other third parties love the word Scrum but have very little idea of what it actually means to apply Scrum and why they are applying Scrum. To understand this, just take a look at the memes from @FakeScrumStats.

One of the most important elements in Scrum is the Sprint. To make this successful, the planning of the sprint is elementary. For this, teams use various methods to see if they have correctly understood the next tasks (stories), if they are well prepared, and how big they are. The idea (which is a good one!) is to bring stability to the uncertainty for at least a manageable period (the sprint) and then, after the end of the sprint, enter a feedback cycle. After that, based on the grown experience and feedback, the plan can be adjusted. This is intended - according to the theory - to lead to permanently doing the "right" work in an uncertain or unknown environment (see Stacey Matrix above).

And here the biggest problem of Scrum comes to light. What happens if something unplanned is added during the sprint? Requirements that weren't so clear after all? Support? Something is more important than thought during planning? Something else is "forced" on the team from the outside? Then the backbone of Scrum - the sprint - is broken.

In my practice, I have experienced that we started to reserve X% of our "capacity" for the unknown. I have experienced that X% never fit. This ensures that a sprint feels very unsatisfying and unproductive, and it actually is.

Therefore, for me, Scrum is only really suitable in a few cases. In my eyes, for Scrum to play to its strengths, the work must be homogeneous. All team members work on one product. Everyone in the company understands the rhythm of the sprint cycle. There is a product vision, and for every sprint, a sprint goal can be defined based on the vision that is more than "all stories should be finished". Everyone in the company understands that a disruption to the team only makes the team slower.

When it became clear to us back then that our work no longer met the above conditions, it was clear to us that we had to turn to another method - better suited to our situation.

When Kanban has its strengths

Kanban focuses on managing the work. Kanban knows no team and also knows no differentiated roles. Kanban is also often referred to as a change management method, and that is correct.

In Kanban, we accept that work can change permanently. It can become more important or less important. It can be large or small. It can be simple or complex. In Kanban, we optimize our system for exactly this realization. We adapt because the world is constantly changing.

If we look at the core of Kanban, it is about optimizing the flow of our stations. An explanation of what flow means and which principles apply in systems where elements flow can be found on my Flow Physics page. It's about the relay race, Little's Law, bottlenecks and constraints, and "Work in Progress".

In our situation, which I outlined above, Kanban is significantly better suited to deliver good software quickly. We manage the work, not the people. We practice Kaizen - the permanent improvement process - to adapt our system in small steps to the environment and the challenges - agile in the sense of flexible.

What you can do now

If you are considering which method is suitable for you, then look at your work. What do you produce? How stable are you, and is your environment suitable to keep a sprint stable? Where do you stand in the Stacey Matrix?

I claim that for very many of you, Kanban is the better choice, as you must permanently react to changes in your environment and have little chance of a stable sprint.

I further claim that many of you do Scrum because it is the more well-known system and because there are clear rules in the Scrum Guide about what a team has to do and when. Likewise - in the hardcore version - it is popular with management because Scrum offers mechanisms to control and harass a team.

And overall, I can recommend everyone to read and think about the concept of Shuhari. Maybe you are in the Shu phase, or maybe already at Ri? There are often enough moments when you leave a method behind - be it in martial arts or in agile work.