The Scrum to Kanban Method Spectrum: Deciding Which Approach To Use

July 22, 2014 — Posted by Al Shalloway

We often get questions about when development teams should use Scrum or Kanban.  We also are asked about which infrastructure teams should use.  I have found that in order to best answer these questions, one should look at Scrum and the Kanban method, not as different approaches, but as sets of practices within the Lean Mindset.

In a nutshell, I'll define the Lean Mindset as follows:

  • it's based on systems thinking (one should look at the whole, the components of the system affect each other making changes to the system complex, bad systems adversely affect people doing work within the system)
  • the focus is on adding value to the customer
  • since most of the errors are due to or strongly influenced by the system, it is important to continuously improve the system
  • people can best work together when they have complete visibility on what is happening
  • explicit workflows are required for best collaboration
  • to be effective one should remove delays in the workflow ("Just-in-Time")
  • one should manage the amount of work being done with a pull system - managing work in process so as to avoid delay
  • one of management's role is to improve the system within which people work
  • cross-functional teams improve effectiveness and efficiency and should be used to the extent possible

In considering how to answer the above questions, one can lay out the two most popular Agile methods: Scrum and the Kanban Method.  These lie at two extremes, but can be thought of as different implementations of the Lean Mindset.  However, these two partial implementations of Lean are not the only approaches teams can use.   Let's start on one extreme and add or remove practices to create a spectrum of possible Agile approaches and then see which ones are best suited in different situations.

Classic Scrum.  By this I mean the Scrum endorsed by Scrum.org.  It has not changed significantly from the original Scrum.  The main differences are:

  • no longer telling the Chicken and Pigs story (thank goodness)
  • explicit policy on what it takes to get a story into the sprint (have acceptance tests)
  • have an explicit policy on what it takes to get a story to done

Classic Scrum can be thought of as a partial implementation of Lean flow in that cross-functional teams eliminate waste (see Cross-Functional Teams Eliminate Waste and Manifest Lean ). Classic Scrum is not truly Lean, however, because it does not include Lean-Management (their role is delegated to removing impediments for the team), it takes a team-centric view (instead of an holistic one) and it frowns on explicit policies as leading towards following process instead of always thinking about what to do next.

People doing classic Scrum are supposed to write acceptance tests and more and more proponents of it are endorsing XP style engineering practices.

Scrum with Lean. More and more Scrum consultants are acknowledging the value of Lean.  Unfortunately, many look at lean as a collection of practices and not as the true mindset it is.  While claiming "they like Lean" what really happens here is that a few lean practices (managing work in process (WIP) is done, but the mindset is still one of classic Scrum.  Management is not fully included (processes are not made fully visible to outside of the team) and explicit workflow policies are not mandated.

SAFeTM Scrum/XP. SAFe extends Scrum in three ways:

  1. Teams should manage WIP although the method is still more at the sprint level than the work-step level
  2. XP engineering practices such as test-first are explicitly endorsed
  3. the SAFe framework explicitly states that Lean-Management needs to be used to lead the transition to Agile methods

Scrumban with Test-First Methods.  While Scrumban was originally a transition approach for teams from Scrum to Kanban, it can be used as a standalone approach.  In other words, one can do the practices a team transition to Kanban achieve just prior to giving up iterations themselves.  Scrumban can be thought of as Classic Scrum with a Lean Mindset while adding:

  • explicit workflow
  • managing WIP throughout the workflow
  • making all work visible
  • including management

As with Scrum, Scrumban has iterations and therefore requires estimation, velocity and making stories small.  At Net Objectives we've found it to be essential to include test-first methods.

Lean-Kanban by a Team.  If a team simply removes the iterations from Scrumban, they would have Kanban.  Lean Kanban still endorses estimation, velocity and having small stories. The difference between Scrumban and a team doing Lean-Kanban is merely one has iterations and one does not.  Even so, Lean Kanban will have cadence, meaning teams can still do Kanban in SAFe and stay in synch with other teams.

Lean-Kanban across a group of people.  Of course, one of the advantages of Kanban is that it doesn't require a team.   Lean Kanban by a team and Lean Kanban is the same set of practices done under the same mindset, but has the work flow across the people in the value stream.  A cross functional team is not required.   However, an understanding of Lean would have practitioners of Lean Kanban to attempt to create teams to the extent possible.

The Kanban Method. I sometimes refer to this as LKU Kanban to differentiate it from the Lean-Kanban.  The Kanban Method is actually a transition method and not a team process at all.  It suggests starting where one is, creating visibility, making explicit workflow policies and managing WIP to improve things with Kaizen.  It is only a partial implementation of Lean because Lean suggests looking at the workflow hitting the development group, creating teams to the extent possible and improving workflow order prior to implementing a Kanban system.

Of these 6 flavors of frameworks/methods:

  • Classic Scrum
  • SAFeTM/Scrum
  • Scrumban with Test-First Methods (hereinafter just referred to as Scrumban+)
  • Lean-Kanban by a Team
  • Lean-Kanban across a group of people
  • The Kanban Method

Net Objectives endorses Scrumban+ and both flavors of Lean Kanban.  Since Scrumban+ methods has all of the requirements of SAFe Scrum, it is the basic team approach we use.

Answering the Questions

OK, so now we're ready to answer the two questions we original were pondering:

What Method Should Development Teams Use?

If you have the opportunity to form a cross-functional team, one should definitely use either Scrumban+ or Lean-Kanban by a Team.  Cross-functional teams are good, use them when possible.  So the real decision in this case is "should I have sprint or merely cadence."  The key point here is do the teams need the added discipline that a strict time-box provides.  The true value of time-boxing is that it forces completion of work.  It forces small stories, testers keeping up with developers and an accurate computation of velocity.  One can achieve the equivalent of this if one has discipline.  If teams are relatively new to Agile, I strongly suggest using iterations, and hence Scrumban+.  Otherwise, the choice is really not that significant.

What If I Don't Have True Teams?

In this case, one likely needs to use Lean-Kanban.  However, as close to cross-functional teams should still be used - with individuals who have to support different teams being managed with their own Kanban board and WIP limits.

What Method Should Infra-Structure Teams Use?

Infra-structure teams, by their very nature, tend to not be real teams in that different folks are called upon to help different development teams at different times.  Hence, these "teams" typically need to use Lean-Kanban. However, there are times that infra-structure team members can be temporarily placed on development teams to create true cross-functional teams  In this case, the Infra-structure team members should be placed "on-loan" as needed so that the development teams can be truly cross-functional.

Summation

In looking at what practices one should achieve, one must look at what are the outcomes we need to achieve.  Always come from a Lean mindset, look at your context and make an educated guess as where to start.  By using explicit workflow policies, managing WIP and monitoring cycle time, one can make a scientific measure of how well things are working.  Try experiments if needed to see which approach works best for you.  But always attend to flow and work with management to continuously improve your methods..

 

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban