Kanban or Scrum?

Scrum is the most widely used agile framework, where most teams begin their agile journey.  But should a Scrum team move to Kanban? Let’s take a closer look.

Agile teams are self-organizing and own their process to complete work the best way that best fits their situation.  Although many teams are successful using scrum, it is somewhat prescriptive and may not be the best fit for every team.  Being agile is all about experimenting and trying different approaches.  There is nothing wrong with trying something new in order to continuously improve value delivery to stakeholders.  So the question is:  Can kanban be a better alternative?  Let’s take a look.

How can a team benefit from Kanban?

Kanban is very flexible and focuses on improving workflow.  It allows bottlenecks to be identified and exposes areas for improvement.  The software development workflow is looked at as a value stream, where work is visualized on a kanban board and pulled through the system.  Each stage in the value stream is limited to an agreed upon number of items to be worked on at one time.  This is called Work In Progress or WIP.  Once that limit is reached new work cannot be pulled into the value stream until something moves along the next step.  This immediately exposes bottlenecks and forces the team to resolve issues that block their work from progressing.  As bottlenecks are exposed, the development team has opportunities to look at ways to continuously improve and evolve their process to make it more efficient.  This will also allow the team to eventually work at a sustainable pace.  

How is Kanban different from Scrum?

Scrum uses a Push/Pull system.  Work is planned in iterations or sprints that are time-boxed from 1-4 weeks.  The team plans what can be completed in that timeframe and capacity is determined by their average velocity or the number of user stories they feel they can complete.  At the end of each sprint, work is reviewed and the team holds a retrospective, making any needed adjustments for the next sprint.  The cycle continues.  

Limitations with Scrum

Scrum is not as flexible.  Scrum uses timeboxed sprints and there is little flexibility to change scope once the sprint begins.  Kanban is more flexible in that work can be pulled in at anytime as long as there is capacity to take it on.

Scrum is prescriptive.  Scrum is more structured and has certain rules to be followed.  We mentioned scope should not change once a sprint begins.  Team members are supposed to be cross-functional and not specialists.  Scrum also only recognizes 3 roles: The Product Owner, Scrum Master and Development Team.

Before you move to Kanban

For teams considering a change to kanban, make sure to do some homework and preparation.  Moving to kanban isn’t a major shift like moving from waterfall to agile.  However, there are a few things o be recognized:

  1. Understand why scrum isn’t working. Make sure you are not placing a bandaid over a larger issue.  Switching to a different process is not a magic bullet that will fix a dysfunctional team or organization.  If it’s a matter of the team being unable to commit to sprints or maybe a team that is not 100% committed to the project, then kanban may be the way to go.  If your team works as a maintenance team where work can be unpredictable, then kanban may be a viable option.  However, it’s possible your team has other issues like team dynamics, morale, or lack of discipline.  
  2. Educate your team on kanban.  You will need to spend time understanding the difference between scrum and kanban, preparing yourself for the changes that will take place.  Educate your team on the principles of kanban such as visualizing work, limiting WIP, managing flow and making policies explicit.
  3. Start with where you are and what you know:  Since your team already uses scrum they should have a board in place which is essentially a kanban board.  Start with what’s already there and make adjustments to your workflow.  Kanban works very well with the processes your team already has in place. 
  4. Don’t expect kanban to solve all of your problems all at once.  Kanban helps to force the discussion of problems which leads to the discovery of solutions.  This will not happen overnight and requires patience and experimenting.

What changes when you move to Kanban? 

Moving to kanban is not a radical change.  Below are some of the key differences between scrum and kanban:

ScrumKanban
Iterations1-4 WeeksNone, continuous flow
Work routinePush and pull systemPull system
CeremoniesSprint Planning, Daily Scrum, Sprint review, RetrospectivesNo specific ceremonies, Daily Standup is still needed
MetricsVelocity, Burndown ChartsLead Time, Cycle Time, Cumulative Flow Diagrams
RolesProduct Owner, Scrum Master, Development TeamNo specific roles

Wrap Up

In conclusion, should a Scrum team move to Kanban? First and foremost, the team should decide how they want to work. Scrum is a great agile framework and many teams find great success using it.  However, it’s not for every team and it really depends on the context of your situation.  It’s ok for agile teams to be flexible and experiment with different approaches.  Moving to Kanban may be a more viable option for continuous improvement.  

Please share this article:

2 Comments

  1. Thanks Steve! My current team has taken more of a Kanban approach. It’s worked for our small team size without a dedicated Scrum master. At times I’ve felt guilty about not doing all the Scrum ceremonies, but glad to see the approach is OK if it works for the team!

    1. Author

      Hi Adam. No problem. Kanban is a great approach for your situation. It’s great that you’re experimenting. The nice thing about Kanban is it’s very flexible and not as prescriptive as Scrum. Good luck!

Leave a Reply

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