Kanban vs. Scrum – How to Choose?

| By David Hawks in Agile Tools, Kanban/ Lean, Scrum | 3 Comments

Kanban vs. Scrum – How to Choose?

apples-and-oranges

My clients frequently ask me when to use Kanban and when they should use Scrum. To form a recommendation, these are some of the questions I ask:

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 will 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 frameworks work best when you break your work down into small incremental pieces. I find 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).

Do your teams struggle with estimation or question its value / overhead?  Can they 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 that Kanban provides works very well in a culture of continuous improvement. They will know the right times to hold a retrospective. For teams new to this practice, the regular cadence of a retrospective ceremony will help teams establish this practice.

Are your teams highly disciplined with technical practices and craftsmanship, such as TDD, Continuous Integration/ Delivery, Shared Ownership, etc.?
If you answered yes, score 1 for Kanban. Note that both frameworks excel in an environment of strong technical practices. However, a Kanban team may be able to reach a higher optimization level by having a constant flow of work.

Is your team’s top priority to optimize responsiveness to customer needs?
If so, score 1 for Kanban. Kanban has a strong focus on cycle time, where Scrum has a stronger focus on Velocity. Both can be tuned to provide very similar output, but Kanban has 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 high level of productivity under both frameworks. For new teams, Scrum provides more guidance and resources of how to handle release planning and progress tracking.

What is the appetite for your team for process change?
If low, then score 1 for Kanban. Kanban has a lower level of Ceremony and may be easier to incrementally 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 in comparison to methodologies such as RUP, PMBOK, and PRINCE2, but it can integrate well into a culture requiring more documentation. From a Lean perspective we would question the need for this potential waste. The reality is that sometimes we have to fit within a certain culture and incrementally work ourselves out of it.

Summary
Both Kanban and Scrum require strong discipline to do well. Kanban doesn’t have as many rules which is good, but it also can be taken advantage of by an undisciplined team. Both can be abused: Scrum teams could constantly carryover unfinished work or Kanban teams could ignore WIP limits. Scrum’s Sprint time box or Kanban’s WIP Limit should force teams to figure out how to break things down into smaller pieces.

I see teams most successful with Kanban fit into two areas:
1. Support the business teams – These teams are focused on serving the business to keep the software running. Their priorities can change on a daily basis with frequent delivery of software. These teams need to optimize to be ultra-responsive. Kanban can enable these teams to optimize flow.

2. Mature, disciplined, self-organizing teams. They are engaged in the process, understand how to break down work and are constantly swarming to get things done.

Where do you see one fit best over the other?

Related:
Agile (Kanban-Scrum) Excel Reporting Templates

David Hawks is an Agile Coach and Trainer based in Austin, TX who helps organizations transition to Agile by implementing either Scrum or Kanban.
Agile Velocity provides Agile Coaching/ Training (Scrum, Kanban, Lean), Agile Technical Practices Implementation and Team Augmentation Services.

Comments

  1. Sandeep

    Great article.

    I see a lot common with below
    http://www.agilechamps.com/should-i-start-thinking-about-switching-to-kanban/

    Reply
    • Minal Sharma

      This is great. Loved reading it.

  2. David Hawks

    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:
    http://tech.groups.yahoo.com/group/AgileAustin/message/1998
    http://tech.groups.yahoo.com/group/AgileAustin/message/2002

    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
    improve.”

    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).”
    http://blogs.versionone.com/agile_management/2012/01/10/2-kanban-vs-scrum-myths-hype/

    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:
    http://blogs.versionone.com/agile_management/2012/01/06/1-kanban-vs-scrum-myths-hype/
    http://blog.crisp.se/2009/04/03/henrikkniberg/1238795520000
    http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf

    Reply

Leave a Comment