Kanban vs. Scrum – How to Choose?
Kanban vs. Scrum – Which is Right for my Team?
Clients frequently ask us when they should use Kanban and when they should use Scrum. To form a recommendation, these are some of the questions we ask:
What best describes the nature of your team’s work? Is it complex, risky, and/or new feature-oriented or is it well-defined, fluid, and/or more service-oriented?
If you answered yes to complex, risky, and/or new feature-oriented, score 1 for Scrum. If you answered yes to well-defined, fluid, and/or more service-oriented, score 1 for Kanban. The Scrum framework is designed to address complex, adaptive problems. Kanban is a Lean method applied to a team’s process in order to improve flow.
Do your priorities change often? Do you have trouble locking scope for 1-2 weeks at a time? Do you have more than 25% scope churn during a 2 week period?
If you answered yes to these questions, score 1 for Kanban. By dropping the fixed timebox, it may allow your team to adapt more easily to the quickly changing priorities of your business.
Do your teams struggle to break features into incremental pieces of value to be delivered in less than a week?
If you answered yes, score 1 for Scrum. Both approaches work best when you break your work down into small incremental pieces. The Scrum Sprint timebox can help teams new to the practice recognize their deficiency (work not completed at the end of the sprint) and adapt (retrospective).
Can teams break work down to reasonably small, similarly sized chunks?
If yes to these, score 1 for Kanban. Kanban removes the overhead of estimation in favor of measuring cycle time for like-sized items.
Do your teams have a strong culture of continuous improvement and self-organization?
If so, score 1 for Kanban. The lightweight framework method that Kanban provides works very well in a culture of continuous improvement. They will determine the right times to hold a retrospective. For teams new to this practice, a regular cadence of a retrospective ceremony will help teams establish this practice.
Do your teams need to improve their discipline with technical practices and craftsmanship, such as TDD, Continuous Integration/Delivery, Shared Ownership, etc.?
If you answered yes, score 1 for Scrum. Both approaches excel in an environment of strong technical practices. Scrum can help teams iterate through improving their technical practices and delivery, by focusing on production worthy increments, as well as Sprint Reviews and Retrospectives.
Is your team’s top priority to optimize responsiveness to customer needs?
If so, score 1 for Kanban. Kanban has a strong focus on optimizing flow, while Scrum has a stronger focus on incremental delivery. Both can be tuned to provide similar outcomes, but Kanban offers the flexibility to lower batch size to reduce cycle time at the potential cost of productivity.
Is your team’s top priority to focus on predictability and productivity for larger projects?
If so, score 1 for Scrum. Again, you can achieve predictability and a high level of productivity with both approaches. For new teams, Scrum provides more guidance and resources for how to handle release planning and progress tracking.
What is the team’s appetite for process change?
If low, then score 1 for Kanban. Kanban is a method we apply to our existing process, whereas Scrum introduces a few events that may be new to the team. So, Kanban may be easier to introduce into your organization.
Does your organization / culture demand a higher degree of ceremony and artifact?
If so, score 1 for Scrum. Not that Scrum has a high level of ceremony, but it can integrate well into a culture requiring more structure and documentation. From a Lean perspective, we may question the need for these as potential waste. The reality is that sometimes we have to fit within a certain culture and incrementally work ourselves out of it.
Both Kanban and Scrum require strong discipline and rigor to be sustainably effective. Kanban doesn’t have as many rules, which is good, but it also can be ineffective with an undisciplined team. For example, undisciplined teams may constantly carry over unfinished work with Scrum or ignore WiP (work in progress) limits with Kanban. Scrum’s Sprint time box and Kanban’s WiP Limit both challenge teams to figure out how to break work down into smaller pieces to get them to a true state of ‘done’.
Teams most commonly successful with Kanban fit into two areas:
- Support or Shared Services teams – These teams are focused on serving the organization to keep the production systems running or other critical business services. Their priorities can change on a daily basis. These teams need to be ultra-responsive. Kanban can enable these teams to optimize flow.
- Mature, disciplined, self-organizing teams. They are engaged, have well-defined processes, understand how to break down work, and are constantly swarming to solve problems and get things done.
Choosing an approach that best suits your team’s needs can be greatly enhanced by providing formal training, supported by coaching.
2 Responses to “Kanban vs. Scrum – How to Choose?”
I appreciate all of the feedback. I think this is a great discussion topic which is why I felt compelled to write about it.
Discussion happening on AgileAustin Yahoo Group:
Apples and Oranges are not the same, but they are both fruits
One of the points I would like to discuss is the statement, “Kanban is not a software development process.” I agree and neither is Scrum. Both are frameworks that can be used to help us do our work better.
As Ken Schwaber documents in the Scrum Guide: (http://www.scrum.org/scrumguides/)
“Scrum is not a process or a technique for building products; rather, it is a
framework within which you can employ various processes and techniques. Scrum makes clear
the relative efficacy of your product management and development practices so that you can
Both frameworks are tools to help us bring visibility to our process, limit our work in process and focus on improvement. Neither is mutually exclusive. And neither will be very successful without other practices.
Implementing by the book is tough
One response talks about how difficult it is to convert a team to Scrum by the book. As Michael DePaoli points out in his article that underlying issue may be a challenge regardless of if you are implementing Kanban or Scrum.
“Usually it isn’t that the agile software teams are unable to execute under Scrum; the fundamental issue is that the business isn’t willing to accept a “pull-based” execution model (required for Kanban and Scrum).”
Kanban and Scrum have many things in common
Both are Lean and Agile
Both use pull scheduling
Both limit WIP
Both use transparency to drive process improvement
Both focus on delivering releasable software early and often
Both are based on self-organizing teams
Both require breaking the work into pieces
In both, release plan is continuously optimized based on empirical data (velocity / lead time)
Here are other articles on the topic:
Thanks foг sharing superb informations. Уour website іs νery cool.
Ι ɑm impressed by the details that you’ve on this website.
It reveals һow nicely yoᥙ understand thiѕ subject.
Bookmarked tһiѕ web ⲣage, will come Ƅack for extra articles.
Уou, my pal, ROCK! Ӏ found simply tһe infߋrmation І alгeady searched eveгywhere and јust couldn’t
come aｃross. Whɑt a greаt site.