Hold my Beer: We Are Going Scrumban!

At the beginning of Agile, there was a tendency to aim at “pure” Agile, following the Scrum rules by the book. Even if there might be still Scrum cargo cult implementations, many Agilists have realized that Agile is more about continuous improvement and value delivery in a specific context than staying stand-up in daily status meetings. In this article, Mark Haynes discusses the Scrumban approach that borrows tools from both Scrum and Lean Kanban.

Author: Mark Haynes

First, full disclosure. I don’t like hybrids. I think they usually implement the worst features possible. They create indecision. Without a set of guiding principles your actions, will tend to whipsaw back and forth, providing no clear direction. Picture the conversation. Oh yes, our group is a mixture of Waterfall and Scrum. Today we are Scrum but tomorrow we will be Waterfall. You see we are flexible. No, you’re confused. Pick one.

What is Scrumban? This question is implementation-specific, so it begs the question of what are the key considerations when blending these two approaches? Is it just adding a Kanban board to an existing Scrum Team or is it aligning Scrum ceremonies with Lean Kanban? It depends on the needs of your team and their focus, but it goes deeper than that.

Scrum is a light management framework, with short fixed-length sprints and a focus on team dynamics. Lean Kanban embraces the continuous flow of work through a queue and the elimination of waste, mostly in terms of excess inventory. Scrum is characterized by its ceremonies and Lean Kanban is methodology agnostic. Most Scrum and Lean Kanban features are not mutually exclusive. On the contrary, they are very complimentary. I would like to make a few suggestions for your blending.

If you are still using a Scrum board, replace it with a Kanban board, configured with columns for To-Do, Work-In-Progress (WIP), and Done. I hear you cry, but we have already done that. It is in the tool. We don’t have a choice. You need to go a bit farther.

Add WIP limits to the Kanban board. These will help regulate the flow of work through the queue. Set them initially based on your team’s capacity. Modify the WIP limits to help control the accumulation of work. If you have columns for Development & QA then think in terms of the capacity for those individual columns. One behavior being modified is the tendency of teams to take on too much work simultaneously. This is a form of waste.

Create a Pull system. Individual columns under WIP should also have a Done column. If you have a column for Development and QA, they would also have a Done column associated with them. The idea is once work is finished it’s moved to its Done column and signals that it’s available to be pulled to the next column. This creates a “true” Kanban board with message cards that trigger replenishment.

Modify your Kanban board to manage requirements as well as Work-In-Progress. Scrum typically has two backlogs. One for all partially defined work and one for the Sprint’s To-Do category. This leads to shortages or excessive inventory build-up. How are your team’s requirements managed? Consider creating a second board for User Story Elicitation, Modification, and Validation. Your goal should be to only have enough requirements inventory to satisfy the needs of your developers. As they Pull the next requirement, another one needs to be added to the To-Do column. It’s all about the flow!

The Scrum Master’s job will need to change slightly from focusing on removing impediments to managing the work-flow as well. These are very similar. Maybe that’s why team leads for Lean Kanban teams aren’t called a Scrum Master. I like Agile Team Facilitator. They need to monitor inefficiencies in inventory as it flows through the work queue.

Now consider what metrics you need to help your team?

Briefly:

Key Scrum metrics:

• Velocity
• Burn-down/Burn-up charts
• Story Points

Key Lean Kanban metrics:

• Lead Time
• Cycle Time
• Throughput
• Work in Progress

In Scrum Velocity and Burn-down/Burn-up charts are aggregate measures of throughput. While Lead Time and Cycle Time are specific to the behavior of individual User Stories. You need to do both.

How does your team view the concept of a potentially shippable work product? In Scrum, this is work that can be shipped but doesn’t have to be released to production immediately. Has this morphed into inventory batched into Release packages and shipped at the end of the Sprint? That may lead to dependencies between User Stories, inefficiencies in the Sprint, and waste due to excessive inventory build-up. Have you considered building a Continuous Delivery / Continuous Integration (CD/CI) pipeline and releasing User Stories once they are completed?

Finally, consider how your Sprint ceremonies can become more like Lean Kanban. They can stay intact for the most part, but you might want to review Lean Manufacturing concepts and see how they might apply.

Think how you can enhance your Sprint closing ceremonies, like the Sprint Retrospective or additional sessions to consider how well the client was served by the team’s output; how operations can be improved overall, and what factors put the work delivery at risk.

My intention is not to provide a definitive analysis or a detailed explanation. The approach here is to start with Scrum and move closer to Lean Kanban. You of course could do it the other way. I always like to go back to foundational principles. For that, I suggest you pursue additional readings.

My recommendation is to choose one approach and include selected attributes from the other. I think a lot of Scrum Masters instinctively do that. The question is which attributes? Since one is about continuous flow and the other is about a light schedule with fixed ceremonies your approach will eventually shift one way or the other. I really don’t recommend building a hybrid. After all, the whole alien-human hybrid thing never really works out well.

References

Scrum The Art of Doing Twice the Work in Half the Time by Jeff Sutherland and J.J. Sutherland, 2014

The Toyota Way Management Principles from the World’s greatest Manufacturing by Jeffrey K. Liker, January 7, 2004

About the Author

I’m a renaissance man trapped in a specialist’s body. I started out as a biologist and that’s why I became an IT guy. I love science, but it doesn’t pay the bills. I’ve been an IT professional for many years. I used to be a software developer with an elegant language for a more civilized age. I became a Quality Assurance guy because it’s better to give than receive. I have been a process improvement specialist because it’s easier to negotiate with a terrorist than a Methodologist. But lately, I’ve been working as a Scrum Master and Agile Coach. I have drunk the Kool-Aid and it tastes good. Agile is a philosophy, not a methodology. In interviews, people often ask how long you’ve been agile? My answer is always. I just didn’t know what it was called before.

Mark Haynes on LinkedIn: https://www.linkedin.com/in/donald-mark-haynes-csm-745a609/

Mark Haynes website: https://dmarkhaynesconsulting.godaddysites.com/