Kanban: The Scrum Master's Not-So-Secret Weapon

We've all seen it: The Scrum Team goes through the motions, implements all the mechanics of Scrum, and still when we look at what's going on, it doesn't feel right.

Steve Porter fondly named it Believably Bad Scrum. I call it Scrum Theater. Barry and Christian call it Zombie Scrum.

You may also like: A Kanban Primer for Scrum Teams

There are many names for this because every experienced Scrum practitioner has seen it way too often. If you're a Scrum Master, I'm sure you've seen it as well.

The Sprint Burndown Chart that looks awesome, but somehow there's still a lot of work dumped on testing towards the end of the Sprint and a scramble to try and get a Done Increment before the Sprint Review.

Some years ago (circa 2007), I found a secret weapon for fighting this sort of behavior. I'm of course talking about Kanban and Flow.

At the time, many agile practitioners were either using Kanban to deal with contexts where they struggled to implement Scrum (think reactive maintenance/support/service/escalation teams) or replacing Scrum with Kanban.

Much of my work with Kanban was focused on helping Scrum practitioners and especially Scrum Masters use Kanban to fight their believably bad Scrum, not to get rid of Scrum altogether.

The Scrum Masters I worked with learned about my perspective towards burndown charts (I hate them), so they started using Kanban boards instead.

For looking beyond a single Sprint, they started to show their teams Cumulative Flow Diagrams (CFDs) to drive discussions about flow, bottlenecks, and WIP. They started to complement metrics like Velocity with Cycle Time and Work in Process (WIP). Some of them organically started to look for aging WIP in their Daily Scrums; some of them I had to point that way.

I started working with some of the Agile/Kanban tool vendors to provide more of these flow-oriented views and metrics that would help these Scrum Masters that wanted to focus on flow.

When I joined Retrospectives and Community of Practice discussions, I was encouraged to hear less discussions about estimation accuracy, what to do with items that weren't finished in the Sprint, and where/how to track them, and how to encourage Dev Team members to track remaining effort in JIRA.

They were spending less time on the mechanics, which freed their time and spirit to care more about the bigger picture: Empiricism, Self-organization, and actual improvement.

They were becoming less of the classical mechanical project manager and more of a coach. They were becoming masters of Scrum.

These days, it's not a secret anymore. A well-rounded professional Scrum Master needs to be a servant leader and a coach. They need to master empiricism as well as flow. Scrum as well as Kanban. Not so they could choose between them, but so they'll be able to help their teams benefit from both at the same time.

Growing your Flow and Kanban competencies are recommended steps in Scrum.org's Scrum Master learning journey. The Kanban Guide for Scrum Teams, for example, is a must-read for any self-respecting Scrum Master. I would start there. (And of course the Professional Scrum with Kanban is a great experiential workshop that is aimed at Scrum Masters and Practitioners exploring this topic.)

Further reading

What Makes a Scrum Master Successful? Insights From 30 of the Best