For what type of projects Kanban and Scrum better adjusted compared to each other?

Question

For which type of projects Kanban is better suited for? For which type of projects Scrum is better suited for?

Answer 1

Scrum works well for projects that:

• Have relatively stable requirements - such that they don't often need to be changed inside a sprint
• Team sizes from 3-9
• Have a stable team that has the time to learn and adopt a framework
• Benefit from a regular time-box (the sprint)

Kanban works well on projects that:

• Have changing priorities
• Frequently have new requirements appear that must be handled quickly
• Have almost any team size and may even vary the team members
• Find a time-boxed sprint to restrictive
• Have lots of external dependencies or complex interactions between specialists

Mike Cohn talks about this in more detail.

Answer 2

The two approaches actually solve different problems and are fairly compatible with each other if you happen to have both problems.

Scrum

Scrum is designed to solve complex-adaptive problems. That is, problems that are difficult or impossible to quickly identify the best solution for, moving targets, and problems where you understand the problem better the more you work on it. It creates rigid timeboxes that the team should have a shippable increment for because the nature of the problems it is designed to solve are a high risk for run-away work. For example, making a new mobile experience for a bank might be a prime candidate. A team could debate forever what the best new mobile experience is without getting closer to building it. However, as they iterate through and review real software with users, they will better understand what those users need.

Kanban

Kanban is all about flow of work and optimizing a system toward a certain goal (usually throughput and speed of delivery). Kanban is applied to any existing process, so it can also be applied to a Scrum team. In Kanban, you visualize the flow of work and apply constraints to it in order to discover bottlenecks, inefficiencies, and challenges that you can then improve on. A common challenge teams face is that Kanban is not a process, method, or framework by itself. You have to layer it onto another process. This can be Scrum, XP, waterfall, or any other process you happen to practice.

One warning would be that, though you can use both together, adopting both at once can be overwhelming. I usually recommend starting with one, based on the problem you are trying to solve.

Also, it is true that Scrum uses timeboxes and Kanban does not prescribe them. However, Kanban uses other constraints such as WIP limits. Kanban is not a good alternative for when Scrum sounds hard. Kanban is less overtly disruptive to the status quo than Scrum, but I'd argue it is actually harder.

Answer 3

Henrik Kniberg and Mattias Skarin have written a short book about similarities and differences between Scrum and Kanban, if you are interested. There is also a summary from Henrik Kniberg found here. For a TL;DR you can jump to page 48 of the summary where you will find this:

If you look at the Kanban differences, where there is no lock down into iterations of prescribed duration, it uses lead time instead of velocity for planning and improvement, it's not mandatory to split work items into smaller estimable items, adding items anytime capacity is available, and there is no need to build a prioritized backlog, and you combine that with what's mentioned in Barnaby Golden's answer (+1), it can be deduced that Scrum works better for product development while Kanban is better suited for production support (for example, you're faster to respond to new work with Kanban than it is with Scrum where you are trying to protect your sprint goal by not messing to much with the sprint scope).

Answer 4

Both Kanban and Scrum share some of the same principles, including:

• Both are visual
• Teams practicing either are self-organized
• Both focus on the concept of continuous improvement, uncovering bottlenecks
• Both create future commitments, aiming to be as accurate as possible with delivery of work

However, they also have distinct differences, including:

• Scrum practices the concept of Sprints, which have start/end dates. Where as Kanban is an ongoing process.
• Kanban inspires work in progress limits but has no formal process where by work is "committed to" within a set duration of time, like a Sprint. Instead, everything is continuously planned in Kanban, and picked up as work in progress moves to completion.
• Scrum uses estimation via story points to track the complexity of work. Kanban doesn’t measure the complexity of work as strictly, but rather encourages work not being started until other work has finished.
• Teams that practice Scrum will typically have team members with designated roles and responsibilities, such as product owners scrum masters. Kanban has no formal roles.

I hope this helps, I wrote an extensive blog post about kanban vs scrum a few months ago, worth giving it a read!