What Makes Scrumban, Scrumban?

The same, even though they’re different.

I got into a discussion recently about what make Scrumban, Scrumban.  I was discussing the concept with two other Scrum Masters whose teams were using Scrumban.  The problem?  The two implementations looked nothing like each other.  One had two week sprints and the other had no sprints, but rather featured continuous delivery.  Both of my friends are convinced they are doing Scrumban.  And they both are correct.

Scrumban is a hybrid creation that combines Scrum and Kanban.  There are very few rules that say that which attributes of each technique must be present to be one or the other.  Any combination of the two techniques can be called Scrumban.

Kanban to Scrum

Here are some the of similarities and differences between Scrum and Kanban:

Scrum	Scrumban	Kanban
Partial Visualization (Input, Output and In Process)	Full visualization	Full Visualization (Granular Process)
Backlog	Backlog	Backlog
Time boxed Iterations	Depends on Iteration Decision	Continuous Flow
Sprint Planning	Depends on Iteration Decision	Dynamic Planning
Work Sized To Sprint	Depends on Iteration Decision	Work Minimally Size (Sized for Flow)
Board Reset After Sprint	Depends on Iteration Decision	Board Persistent
Burn-down (Burn-up) Charts	Depends on Iteration Decision	Cumulative Flow
Management As Outsiders	Depends on Iteration Decision	Management As Insiders

The one (huge) requirement for any Scrumban implementation is the need to fully visualize the steps in the workflow.  The biggest hybridization decision is reflected in the decision of whether to leverage sprints or continuous flow as the central mechanism to control work.  A decision to use iterations will cause the team to leverage a number of other techniques from Scrum – making the version of Scrumban more Scrum like.  For example, if you choose iterations, then some form of sprint planning will be required and work will need to be sized so that it can be completed within the sprint. On the other hand, focusing on a continuous flow of sprints will require the team plan dynamically so that work can be added as capacity dictates and to use cumulative flow diagrams to monitor progress rather than burn-down charts.  The choice of sprints or continuous flow becomes a decision of how you are using process to influence behavior.

Scrum has an expectation of bounded, well-formed teams.  Scrum teams are cross-functional with members playing many roles depending on the need.  Teams are also expected to be self-organizing and self-managing.  Some organizations either can’t commit to this this type of structure or need time to transition.  Hybridizing Scrum by de-empathizing use of well-formed, cross-functional teams for specialists may make it easier to begin the transition towards a more Agile structure.  Is this an optimal solution? No. However it isn’t an equilibrium solution; left to its own devices no organization be able to hold this solution for long. In my experience, as teams learn how to interact within an Agile environment they will find innovative ways to embrace the Agile values and principles. Embracing these ALWAYS leads to an environment with stronger teams.