Scrumban

I’m a fan of Development That Pays videos, and Gary Straughan’s recent explanation of Scrumban got me thinking. He began with some Venn diagrams that I’ve reproduced below, showing how Scrum and Kanban are merged to produce Scrumban.

That’s not been my experience but before I explain that it’s probably useful to quickly clarify some terms:

• Scrum is a framework as defined by the Scrum Guide. It states: “The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.” This means you can do a subset of Scrum – just don’t call it Scrum. Of course you can add things to your ways of working and still call it Scrum as long as you still do everything in the Scrum Guide.
• ScrumBut is a portmanteau word that indicates you’re doing Scrum… But not some part(s) of the Scrum Guide. Given the definition of Scrum, the “But” part means you’re not doing Scrum and should call your way of working something else. (There’s nothing wrong with doing ScrumBut other than calling it Scrum.)
• Scrumban is another portmanteau, but this time it’s Scrum plus Kanban, and because you’re adding to Scrum (not removing part of it) you could still call it Scrum – personally I’d advise calling it something else to avoid confusion with “vanilla” Scrum per the Guide.
• Kanban (aka the Kanban Method) is “a holistic way of thinking about your services with a focus on improving them from your customers’ perspective”. (Source: The Official Guide to The Kanban Method)

I have been lucky enough to coach some teams that have reached a level of maturity with Scrum that means they are doing all of Scrum and are starting to look for other idea that could help them improve the way they work. A team like this is already starting to follow some Kanban practices, even if they’re unaware of Kanban. The fact that they are looking for ways to improve suggests to me that “Improve Collaboratively, Evolve Experimentally” would be a good practice to introduce explicitly. To get to this point they are probably improving collaboratively, but are they treating the changes as an experiment? Are they thinking about how to measure the impact of a change in order to evaluate whether the change is moving them in their desired direction?

With this experimental mindset, the team can consider other Kanban aspects that may already be (partially) in place as a result of following Scrum:

• Visualization: the team will be familiar with their Scrum board but does it provide enough insight? Does it clearly represent the flow of work through their system?
• Limit Work in Progress (WIP): hopefully the team have already adopted a pull system and discovered the inefficiency of multi-tasking, but have they experimented with changing their WIP limits? Have they considered whether there should be minimum WIP limits as well as maximums?
• Manage Flow: are they tracking their cycle time and throughput? If so, have they moved away from team estimation to using forecasting?
• Make Policies Explicit: their team working agreement probably identified some policies, but are they creating new policies / modifying existing ones as they change the way they work? Some policies were imposed by Scrum; do they need to be updated?
• Implement Feedback Loops: Scrum imposed some feedback loops (Daily Scrum, Sprint Review and Retrospective) but there are many more which may be beneficial.

There are many more elements of Kanban, but these general practices will provide the team with a myriad ways of potentially improving how they work. Starting with Evolve Experimentally should dampen the temptation to try multiple changes at once.

So how do I see Scrumban? I think it can be a superset of Scrum, where elements of Kanban enhance it. It’s possible to expand and extend elements of Scrum without dropping anything from the Scrum Guide … but staying within the confines of the Scrum Guide is not the goal.

The goal is to continuously improve the way we work. If that happens to mean not doing something that’s in the Scrum Guide, then so be it – what you’re doing is no longer Scrum, so give it a new name. Make sure you’re documenting your current practices (Make Policies Explicit) so that it’s clear to everyone how you work; there may be things you can share with other teams that might help them improve.

Ultimately it doesn’t matter whether it’s Scrum, Scrumban or something else; just keep experimenting in order to improve how you work. “We are uncovering better ways of developing software by doing it and helping others do it.” So keep uncovering!