Scrum or Kanban… Which do You Like Better?

scrum or kanban

tl;dr: (from Karl Scotland)

  • Scrum focuses on being agile which may (and should) lead to improving.
  • Kanban focuses on improving, which may lead to being agile.

Kanban and Scrum are two different flavors of Agile development workflow.  This post covers similarities and differences between the two approaches as applied to software development projects – as opposed to “change management” – an important distinction. (Hopefully you don’t have to choose between Scrum and Kanban and instead can find application for both!)

Scrum

Scrum is a form of agile that optimizes the estimation and execution of work. Scrum teams work in fixed intervals, known as sprints, which means they iterate on the product frequently. This allows the team to get feedback about each release, and to ensure maximum value back to the customer in the next sprint.

Kanban

Kanban is a flavor that emphasizes the flow and continuous delivery of work. Limiting the number of items in flight creates an elegant workflow that lets kanban teams manage quality closely and deliver work to the customer continuously. A pull model makes the flow of work visible across the team, and exposes bottlenecks so the team can address them quickly.

Similarities

  • Both Kanban and Scrum focus on ‘getting to done’ for tasks in progress, reducing context switching
  • Both at their core are summarized by the premise: Stop Starting, Start Finishing.
  • Both limit WIP.
  • Both use visibility and transparency to drive continuous process improvement.
  • Both focus on delivering value (releasable software) early and often to minimizing risk
  • Both are based on self-organizing and highly-collaborative teams who make their own decisions, strive for predictability, and a sustainable pace of development
  • Both require breaking the work into pieces.
  • Both embrace change as an opportunity, not a hindrance
  • Both continuously optimize the release plan based on empirical data (velocity / lead time).

Differences

Kanban
Scrum
  • No prescribed roles.
  • Cross-functional teams optional. Specialist teams allowed.
  • Pre-defined roles of Scrum Master (heat shield/bulldozer), Product Owner and Team Member.
  • Cross-functional teams prescribed.
  • Continuous Delivery.
  • Commitment (timeboxed) is optional.
  • Can have separate cadences for planning, release, process improvement.
  • Can be event driven, instead of timeboxed.
  • Timeboxed sprints are prescribed.
  • Team commits to a specific amount of work per iteration.
  • Work is ‘pulled’ through the system (single piece flow)
  • Work is ‘pulled’ through the system in batches (the sprint backlog)
  • Changes can be made at any time, whenever capacity is available.
  • A kanban board is persistent
  • No changes allowed mid-sprint.
  • A Scrum board is reset between each sprint
  • Uses Lead time (or Cycle time) as default metric for planning and process improvement.
  • No particular type of diagram is prescribed.
  • Uses Velocity as default metric for planning and process improvement.
  • Burndown chart prescribed.
  • More appropriate in operational environments with a high degree of variability in priority
  • More appropriate in situations where work can be prioritized in batches that can be left alone
  • No particular item size is prescribed.
  • Estimation optional
  • Items must be broken down so they can be completed within 1 sprint.
  • Estimation prescribed.

Core Values

scrum_teamIlan Goldstein has a great image from his book Scrum Shortcuts without Cutting Corners that nicely describes the power of Agile when discipline is maintained and teammates work together as one. I feel it applies to both Kanban and Scrum.

For sponsors and the business, the interlocking shields provide:

  • Risk mitigation
  • Visibility, transparency
  • Continuous organizational improvement
  • The opportunity for change as the result of frequent feedback loops
  • Faster and predictable delivery of value

For the agile team they provide:

  • Reduced context switching
  • A sustainable pace of development
  • The ability to make their own commitments
  • No more “just me”
  • And no more “us and them”

The ancient Spartans would fully understand the core values of this approach

Focus

Because the team focuses on only a few things at a time, they work well together and produce excellent work. They deliver valuable items sooner.

Courage

Because they work as a team, they feel supported and have more resources at their disposal. This gives them the courage to undertake greater challenges and overcome adversity.

Openness

As they work together, they express how they’re doing, what’s in their way, and any concerns so they can be addressed.

Commitment

Because the team has great control over their own destiny, they are more committed to success.

Respect

As they work together, sharing successes and failures, they come to respect each other and to help each other become worthy of respect.

Some Tools for the Journey

When you create an Agile board in JIRA (Agile > Manage Boards > Create Board), you get to choose between one of two type – Scrum or Kanban – depending on how we want to run the project.

Screen Shot 2015-04-25 at 12.22.00 PM

What kind of board am I looking at?

If you have an existing JIRA Agile board (previously known way back as Greenhopper), you can tell by looking at the top right if you’ve got a Kanban or Scrum version.

Scrum boards will have the “backlog” button enabled:
Screen Shot 2015-04-25 at 12.22.32 PM

Kanban boards will look like this:
Screen Shot 2015-04-25 at 12.22.21 PM

Note: It is not possible to switch an existing JIRA agile board from one type to another. Fortunately it is easy to create a new agile board of either type and use an existing JIRA filter.

Which is “Better” – Scrum or Kanban?

Really? It depends…

  • Scrum is generally used by development teams who follow a roadmap of planned features for upcoming versions of their product. It sets up a regular cadence.
  • Kanban is often used by teams who deliver maintenance releases. Kanban is also well suited to WebOps, SysAdmin and IT Support teams where frequent reprioritization is need.

More

One comment

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to Top