When Is Kanban Better Than Scrum?

Scrum and Kanban are both steadily becoming more popular. When to choose one over the other?

Context Matters

I do not prefer Scrum or Kanban. It does not make sense to say one is better than the other. It all depends on the context. Slippers are great in summer. Uggs are great in winter. Uggs still look hideous in all seasons though☺. The same holds for Scrum and Kanban. The context and expected outcome determine which method will likely perform better.

Scrum & Kanban Summary

Before we start zooming in and discussing Scrum and Kanban in detail, I will summarize both to refresh your mind.

Scrum

Cross-functional team works in time-boxed iterations called sprints. The work of each sprint is forecasted based on estimates. Each day the team checks progress of the sprint relative to the forecast. During the sprint adjusting scope is possible, if it does not endanger the sprint goal. At the end of the sprint the potentially releasable increment is inspected. The process to deliver the increment is examined each sprint with the aim to improve it.

Kanban

Pull-based work system where individual work items are completed with a focus on improving the flow of work. Work is completed without using estimates and by limiting Work In Progress for each workflow state. The current state of work items is visualized using a Kanban board.

Conditions That Influence Kanban And Scrum

1. Team Experience

Kanban has few rules and is more lightweight than Scrum. Paradoxically, this is what makes Kanban more challenging to do well. Your team needs to be able to handle the lack of rules. Kanban easily turns into a do anything you want kind of thing, because it gives so much freedom. Inexperienced teams will have more difficulty thriving in conditions where they need to fill in all the blanks themselves.

Agile practices present in Scrum may be necessary for your team to perform well. Kanban does not mention retrospectives, refining issues, stand-ups or crafting goals together. If your team is unaware of these practices, then they may not apply them.

Scrum is all about working as a cross-functional team, Kanban does not enforce this. Even though working together as a cross-functional team will help to improve the flow of work items in Kanban as well.

For these reasons it may make more sense to start with Scrum with an inexperienced team. Once good agile practices are established, you can switch over to Kanban, if you wish. Then your team can apply Scrum practices that will improve Kanban flow and have the best of both worlds.

2. Team Of Independent Developers

I once worked on a team that actually were not working on things together. Each developer worked on their own project in their own programming language. The only thing in common was the API they used to develop their applications.

We started with Scrum, but it did not work. If a developer worked on something, he was the only one who could work on that issue. Nobody could take work over from him. Each time we would discuss an issue in refinement only a single person would pay attention. The other people knew they would not be working on this issue, so why bother taking in all details? We went back to Kanban, removing overhead and improving performance of the team.

3. Frequently Shifting Priorities

When the priorities of your company shift daily, Scrum is not your ally. Scrum helps keeping your development team safe from the crazy whims of the outside world. Did you not add it in sprint planning? Then please wait until the next sprint if possible. If not possible, then we first check if it does not endanger the sprint goal before adding it. And if we do add it, we most likely will also remove something else. If stakeholders are affected, we can immediately inform them.

Kanban gives the freedom to change direction at any moment. Frequently shifting priorities can be something which needs to change in the organisation. In this case Scrum may be a good idea. Scrum helps forcing the organisation to adapt to the cadence of sprints. You will be able to tell stakeholders that the sprint already started and you would prefer to not pick it up right now.

4. Importance Of Planning

The flexibility of Kanban comes at a price: it is more difficult to plan using Kanban. Forecasting using Scrum is more straightforward. A burn up chart paints a pretty clear picture of the expected delivery date, including the variability.

In Kanban you have to make more complicated calculations using cycle time and Little’s law. Each time priorities change repeating calculations is necessary. This makes planning ahead more difficult and laborious. Plus the fact priorities may change often potentially adds more uncertainty to the planning.

5. Legacy Codebase With Technical Debt

If your development team works on a legacy codebase, then Kanban may make more sense. When you ask your team to estimate work, they are not able to do so or it takes a lot of time to get an estimate. They will start talking about spaghetti code and how nobody has a clue how the code works. A lot of code needs refactoring if you want to introduce new functionality.

Also in a legacy codebase production issues may appear frequently and be difficult to resolve. This makes planning and estimation difficult, because it adds a lot of variability.

Kanban flourishes if you want to maintain the current situation and roll with it. If you want to change the status quo instead of going with the flow, Scrum could also be an option. So there is no preferred method, it depends on what you want to achieve.

6. Team Size

Scrum recommends the development team to have 3 to 9 members. Kanban does not come with size limitations and allows you to just roll with it. This does not mean having mammoth-sized teams will suddenly become a good idea. But it could be that the team-size is just a given you need to work with.

Adapt To Your Situation

One method is not better than the other, regardless of context or expected outcome. You need to pick the right one for your situation. There are conditions that affect the chance one method will work better than the other. Pick carefully while taking into account the situation. Check if it leads to the desired outcomes. Evaluate and consider adjusting if it does not. Do not stick to something just because you want it to work. Keep doing what you are doing and you will keep getting what you are getting.