Should you choose Scrum or Kanban as your preferred way of working?
In a mature team they will look quite similar. It is not an obvious choice and different experts have strong, but different opinions. I am not affiliated with either framework, but have significant experience in both ways of working (roughly 100 teams doing Scrum and 15 teams doing Kanban) so I will share my thoughts and let you decide for yourself.
Let’s first examine the similarities and differences.
Similarities
- Both are agile (Scrum slightly less by discouraging change during a Sprint – which can be good or bad depending on situation)
- Both are based on the concept of pulling work (in Kanban team pulls when WIP-limit says there is room, in Scrum team pulls a batch of work in Sprint Planning)
- Continuous Improvement is emphasized in both
- Both emphasize transparency and visualization
Differences
[minti_table style=”1″]
| Scrum | Kanban |
|---|---|
| Timeboxed | Continuous flow |
| Cross-functional self-organizing teams | Optional |
| Three roles prescribed | Optional |
[/minti_table]
The most significant difference between Scrum and Kanban is the timeboxed Sprints. In my experience most software development teams have great benefits from working in cross-functional self-organizing teams and make good use of the three roles (Product Owner, Scrum Master and Developer) so in that scenario it might make sense to use those parts even if you are doing Kanban. In fact, you can combine Scrum and Kanban any way you like, this is called Scrumban. A Scrum team might for example choose to put WIP limits on the states on their board and pull work in Daily Scrum based on those.
The most significant difference between Scrum and Kanban for most teams is the timebox. So the key question to ask yourself is if the timebox is more of a benefit or more of a drawback. To many agile/lean coaches the answer seems obvious – it is a drawback, because it makes the ideal of one-piece-flow impossible. And according to lean and Toyota one-piece-flow is part of the ideal endstate (True North) and therefore Kanban is better than Scrum. While there is truth in this, I do not think it is that simple. There are other aspects to consider as well. First of all, the timebox provides focus and a goal that is not needed in a manufacturing context where the cadence is built into the work process (Takt time). Secondly time boxing is used in time management techniques to increase focus and output so it clearly has benefits as well as drawbacks, even if it is a roadblock for True North. Let’s examine timeboxing a bit deeper. Some agile/lean coaches will also argue that the timebox prevents you from releasing as soon as things are done, but I don’t really see any reason for that. If the team and processes are mature enough to release as soon as things are ready – what’s stopping you?
Benefits with timebox:
- Focus on the goal at the end of the Sprint can give extra energy to get things done and help avoid goldplating
- Forces hard decisions to be made – when everything we want can’t be done by the end of a Sprint we are forced to think about the best way forward which sometimes leads to surprising options
- To successfully work with timeboxes the team need to build a strong collaboration and sense of shared ownership of success
- Improves predictability – since lack of predictability becomes very apparent through the nature of the timebox
- Easier to synchronize work if there are team dependencies (not the wanted state obviously, but sometimes unavoidable)
Drawbacks with timebox:
- Start and stop creates a bit of overhead
- Breakdown to make items fit can sometimes be unnatural and add a bit of overhead
- Harder to incorporate the complete flow of work from preparations to follow-up after release in a natural way
- Can cause stress and technical debt
- Forces the whole team to participate in planning – which can be good or bad depending on the situation
For teams that are new the benefits of learning how to deeply collaborate and be more or less forced to become more cross-functional and less dependent on individuals might outweigh the drawbacks. In my experience the path to learning to achieve acceptable levels of predictability is faster with Scrum than with Kanban. On the other hand, it is significantly easier and faster to start with Kanban. All teams I have worked with that has started with Kanban has seen significant benefits within weeks, but a some Scrum teams have struggled a bit in the beginning.
For mature teams the benefits of continuous flow, especially when increasing the flow to include preparations and follow-up, might outweigh the benefits of the timebox.
The answer on what the best choice is unfortunately “it depends”. But here are some thoughts that might be helpful.
Timeboxes might be better if:
- The value of the team collaborating closer and becoming less dependent on individuals is high
- Increased predictability is important
As you can see from arguments above, this becomes less important for mature teams which is some of the reason why very mature teams tend to gravitate towards Kanban. But this doesn’t necessarily mean that all teams should mature towards continuous flow, all benefits and drawbacks needs to be considered in the teams context.
Continuous flow might be better if:
- The nature of work that needs to be done is to a large extent unpredictable
- The cost of cross-training team members (both across parts of the product and across roles) outweighs the benefits
- When people doing the work have other work as well (which might make overhead with timeboxes too big and predictability too hard)
As concluding remark Kanban is much more generally applicable than Scrum. It can be used by pretty much any team and it is very easy to get going. And it can even help visualize and manage work across teams. That being said, I believe Scrum still has a valid place in the agile community and even though timeboxes have drawbacks, the benefits will sometimes outweigh the drawbacks.