Scrum Guide Sliders

It was Monday afternoon on her first day of work at a new company and Sarah was feeling anxious. Having studied Scrum over the last few months, Sarah had been hired to serve as a Scrum Master and she was eager to begin applying her new skills, however nothing she had been told today seemed congruent with her lessons. As Sarah listened to her new manager explain why the company’s software required the organization to field a “UI team,” “service team,” and “back-end team,” she felt especially troubled by the phrase she’d heard multiple times on this day: “No one does Scrum by the book.”

“If no one actually follows the design of Scrum,” she wondered to herself, “why did my Scrum trainer teach it to me?”

There’s plenty more to this short anecdote; it’s a brief introduction to a true story. And while Sarah eventually found a great deal of success, her experience with coercion to dysfunction in the name of “no one does Scrum by the book” is shared by far too many practitioners. I argue what passes for “Scrum,” more than twenty years since conception, is so commonplace that we’ve started accepting all of it (results, outcomes, experiences) as factual Scrum.

While distressing, this reality is also quite understandable. In a terrific blog post, Ashok Singh said, “When people are not able to solve organizational problems, they come down to tweaking the framework to accommodate the dysfunctions.” Meanwhile, we fear the dogmatic, prescriptive Scrum zealot, yet often find ourselves trapped in a downward spiral in the name of pragmatism. At the core of this pattern lies questions we might first ask ourselves: Before altering the Scrum framework for potential improvement, shouldn’t we first achieve the maximum results from the framework itself? Without a baseline, how do we know we’re tweaking the essence of Scrum for a competitive advantage?

Therefore, to help mitigate these risks for companies using Scrum—“the Inevitable Avoidance Principle” and false conclusions—I’ve been experimenting with (and enjoying wonderful success with) an exceptionally simple visual technique over the past year. I call it, “Scrum Guide Sliders.”

The idea for “Scrum Guide Sliders” came from the mind of Neil Killick and his work in assisting organizations with agile-guided change. While mentoring Sarah and exploring ways to detangle the impact of “no one does Scrum by the book,” I serendipitously stumbled onto a Twitter dialogue between Neil and Bob Marshall. As I considered how traditional “risk sliders” were used here to call attention to values, Neil’s method for facilitating conversation and shared understanding of organizational mindset triggered an idea: What if we harnessed the same visual power for companies learning Scrum?

Therefore, the goal of the technique is threefold: reduce (or eliminate) false conclusions, create shared understanding of the behaviors needed for Scrum’s success, and make visible what is often hard to see.

So, what exactly does “Scrum Guide Sliders” look like? Well, it might look like anything, as I hope you’ll appreciate the simplicity and ease of customization… however, here’s an introduction to the tool as I’ve been using it:

Download a spreadsheet version here – this is my personal version and it’s free to download a copy, use, and enjoy! (Note: this version uses circle objects to create the “marker” for each slider. The circles don’t work well with Google Sheets; try downloading a copy and using Excel for a better experience!)

Using Neil’s dashboard as a model, ‘Scrum Guide Sliders” extracts the contents of the Scrum Guide and organizes the essential components (and behaviors) into four sections:

• The Development Team
• The Product Owner
• The Scrum Master
• The Sprint

Within each segment, a series of “sliders” are housed that create a spectrum of behavior which might be described as:

“Scrum in Name Only” on the left <—-> “Scrum by the Book” on the right

Given the context of my story about Sarah–and other stories you might have heard about “no one does Scrum by the book”–for the destinations on the right (“by the book”), I intentionally use verbiage directly lifted from the Guide wherever possible. For example, when describing The Development Team, the Guide states: “They are self-organizing; No one (not even the Scrum Master) tells the Development Team how to turn the Product Backlog into increments of potentially releasable functionality.” I retain much of the phrasing here to reinforce the shared understanding of what Scrum is… and what it is not!

A few sliders I’ve included in my version are not explicitly stated in the Scrum Guide, however. For example, regarding The Scrum Master, one slider asks us to consider whether we have enough SMs to ensure the “process” occurs–versus–having enough SMs to ensure teams get the coaching and mentoring they want. The Scrum Guide doesn’t explicitly state how many teams a Scrum Master can work with; it simply points out that a Scrum Master is a required role. Therefore, I’ve added this slider based on my experiences and interpretation of the Guide, believing that this is a meaningful mindset change that helps us become successful with Scrum.

That last part is important: you’re free to use my version of “Scrum Guide Sliders” as I’ve defined it, however this technique offers you an invitation to customize and add, change, or remove sliders. See something missing? Perhaps some of these sliders are unimportant to you? Experiment with sliders to fit your context, goals, and culture!

Use of this technique is exceptionally straightforward: In whatever way facilitates an appropriate conversation for the people you’re working with, let people see the Scrum Guide Sliders visual and have dialogue over where a marker should be placed for each slider. In facilitating the discussion, you’ll discover people begin to reveal their assumptions, share their feelings about the current working environment, and tell stories that hold a mirror to reality… and offer insight into what might improve if the slider moved closer to guide.

Lastly, I’ve found “Scrum Guide Sliders” have excellent synergy with a variety of methods to help decide on actions and experiments. In particular, three methods have proven to be very useful:

• Force Field Analysis: Setting an objective from the sliders (e.g., the “by the book” outcome of Sprint Review resulting in a revised or prioritized product backlog), use Force Field Analysis to uncover what’s supporting and working against the objective.
• Social Cause Mapping: I learned this technique from Dan Greening and it should feel familiar to anyone using Ishikawa diagrams or “five whys”. With Social Cause Mapping, extract the “problem” or thing of interest from the sliders and, one person at a time, uncover possible causes that might be holding you back.
• Perspective Mapping: What might you discover about your organization when multiple groups (e.g., Managers, Scrum Masters, and Teams) place their own markers for each slider? Do the groups of people converge or diverge in their perception? What might improve if perceptions became more aligned?

It’s important to reiterate the goal isn’t to move every slider 100% to guide; the goal is to create shared understanding. I’ve found this technique enables us to easily have a conversation about “why?” When we say, “no one does Scrum by the book,” this technique helps us see just how far away we are… and encourages us to ask what might be different if we were closer “to guide.”

Geoff Watts summarizes this principle far more eloquently than I:

“…while measuring how strictly you are adhering to the rules and principles of Scrum is not the point, if you believe that an agile approach, such as Scrum, is a viable means of becoming successful then assessing yourself against the application of that framework or process as a proxy metric of success might not be a bad idea.” – Geoff Watts, Scrum Mastery: From Good to Great Servant Leadership (71)

Good luck, have fun, and feel free to contact me (zbonaker@gmail.com) with comments, questions, or ideas for using “Scrum Guide Sliders!