I read article on Scrumban that caused me to look more closely. The author advocated implementing every aspect of Scrum when standing up any Scrumban team. In that author’s opinion all three roles and all four ceremonies of Scrum were needed if a team used Scrumban. Scrum is a widely accepted and (mostly) understood Agile practice so it makes sense that people will gravitate to what they know and lean upon practices that they both understand and feel comfortable with.
However, as Agilists we should always be pushing the envelope of what’s known and experiment with techniques that can help us relentlessly improve. Looking at the 6 practices of Kanban, we can see many aspects of Kanban that have already made their way into common Scrum practices:
- Visualize Workflow
- Limit Work-in-Progress (WIP)
- Measure and Manage Flow
- Make Process Policies Explicit
- Implement Feedback Loops
- Improve Collaboratively (Using Models/Scientific Method)
The Scrum board imitates a Kanban board and helps teams visualize the workflow, often with WIP limits so that teams can optimize the flow. The Review and Retrospectives create a mechanism for timely feedback. Many Scrum practices find their origin from the Lean processes that birthed Kanban. So implementing all the roles and events of Scrum and calling it Scrumban in my mind says you just want to merge the two more.
But when I consider the values and principles of the Agile manifesto, I tend to go a different direction. Think of processes and tools the way we think of documentation and product: what is the minimum that’s necessary to deliver the desired value. Keep the processes lightweight and implement the minimum practices needed to achieve the desired result, adjusting as necessary with each iteration. Understanding all the Lean and Agile tools that are available is good but trying to implement them all in tandem without a clear need is not something I would recommend.
I think of Kanban as a tool that can be used in a more responsive fashion than Scrum, where classes of service are understood and continuous flow is desired. Scrum techniques can be applied where the class of service is less defined and timboxes applied to keep focus and to adjust course in small increments. Some teams deal with challenges that neither tool by itself is fully prepared to address, so they blend the two in order to strike the right balance between the Scrum and Kanban.
Rather than trying to implement everything, I suggest trying to implement the minimum that is needed with a hypothesis for how the techniques that will deliver results for the team. Then assess the outcome in a planned retrospective where the team can further tweak and hypothesize their practices. In this fashion, a team may discover that they really have a new class of service and no need for the other Scrum structure. Likewise, they could also find out that they do in fact need all the overhead of Scrum with a mechanism for addressing ad hoc requests. More likely, they will simply land at a lightweight set of practices that wouldn’t work for any other team but optimizes the value delivery for them using a blend of Scrum and Kanban.
In short, think of Scrumban as Spectrum that may lean toward Scrum or Kanban, borrowing practices from both. Every Scrumban team will find themselves somewhere along the spectrum, and the really nimble Scrumban team will adjust where they are on that spectrum to meet their evolving needs.
I’d like to hear your thoughts or experiences with this. Reach out to me either through with website or via my LinkedIN profile. https://www.linkedin.com/in/mitchellmalloy/