What Does a Scrum Master Do?
When I was a kid, I was obsessed with the book, What do People do All Day? by Richard Scarry. Though Lowly Worm was my favorite, I loved discovering the wide array of characters, and their jobs. It gave options for the question: “What do you wanna be when you grow up?” More than anything, I wanted become a marine biologist, specifically studying great white sharks. Jaws wasn’t an age-appropriate movie for a kid to watch, but I did, and of course it terrified me. To this day, I still look over my shoulder in swimming pools — you can’t be too careful.
Though the movie terrified me, I found it fascinating. It piqued my curiosity about sharks, and fueled my interest in studying the oceanic predators. To this day, many of our assumptions about them are misunderstood, or simply incorrect. I didn’t end up becoming a marine biologist, but as a Scrum Master (SM), I run into similar misconceptions about what I do.
The powers-that-be wanna measure things. Outputs. It’s usually, “How many widgets did we make?” They’re in love with metrics because it’s simple to measure, and familiar; it’s what they’ve always done in the past. But what happens when you ask questions like, “How well did we make our widgets? What did we learn while making ‘em? How can we make them better?” Those difficult-to-measure, subjective questions are met with blank stares. That is, until someone suggest implementing an Agile Maturity Model (AMM).
If you’ve never seen one before, it’s an assessment using criteria to measure against. Outputs again. I’ma play devil’s advocate for a moment. If you check off all the things that it says you hafta do in order to be “Agile,” does that mean a fundamental, cultural organizational shift has occurred? Are people fully empowered to make decisions, or advise on policy? Can a line item in an AMM guarantee that a product owners comprehend the discipline behind prioritization, and backlog management?
A ways back, The Scrum Guide (TSG) scrubbed the word priority when referring the backlog, but people still insist it’s supposed to be prioritized. It’s not like Scrum is fresh out of the box; it’s been around the block a few times. But I’ve lost count how many times I hear people refer to this “new Scrum process.”
Speaking of misunderstanding, take the role of Scrum Master. Think of everything that’s been piled onto it over the years, and take a look at job descriptions posted on LinkedIn. After you’re done, look at how the role is actually defined:
- Promote, and support Scrum.
- Help everyone understand what the hell Scrum is.
- Advise folks which interactions with the team are helpful, and which aren’t.
- Help people change how they interact, so the team can regularly knock it outta the park.
I’m paraphrasing, but there’s three whole sections on the role. Others only get one. Must be important. My main issue with AMMs is the ill-advised focus on outputs, a set of by-the-book measurable criteria. Sadly, the focus isn’t on a attaining a fundamental understanding, or making meaningful changes throughout an organization. When companies are sold on Agile (Scrum in most cases), at some point leadership complains that they’re not seeing the promised benefits. So, they’re sold on another concept: measuring how agile they are.
Here’s a crazy idea. Rather than collect a series of responses to a one-size-fits-all assessment, why not ask people what they think?
So I did.
Before closing out my teams’ last retrospectives, I asked them to do me a solid.
“I’ma try an experiment, and I need your help,” I said. “There’s no right, or wrong answer; I only want your honest opinions. I have a question I’d like you to answer by writing down your replies on an index card. Don’t sign your name. Let’s keep it anonymous, and only put one answer per card. If you have multiple answers, put ’em on separate cards. So here’s the question: What does a Scrum Master do?”
I wasn’t surprised by most of the answers. Based on previous conversations, it’s relatively simple to foretell people’s levels of understanding, or lack thereof. There’s a ton of information out there on Scrum — some good, some bad. That being said, lots of things have been added to the collective understanding, becoming intermingled as part of the actual framework (story points, for example). A few answers did catch me off guard, however. Here’s a few, and why they gave me pause:
- Backlog Grooming— Two things about this card bothered me: 1) They referred to it as “Grooming,” yet the Scrum Guide changed it up to “Refinement” between 2011-2013. You may think I’m nit-picking, but it speaks to the last time they looked at the guide, and calls out that their definition is deprecated. 2) Whoever wrote this card thinks this event is the primary responsibility of the Scrum Master, and not the Product Owner.
- Organizes the team — One of the very first things the guide says about development teams is that they’re “…structured, and empowered by the organization.” How they’re organized is well outside the scope for an SM.
- Facilitate all sprint ceremonies — This one’s fairly common, and people tend to forget about TSG’s bit on self-organization. If the SM facilitates everything, how’s the team supposed to become self-sufficient? All of the ceremonies? Beyond the ire I have for the word ceremonies, everyone on the team should be able to adequately facilitate Scrum events.
- When velocity is good, should treat us with food — I put it simply: “Velocity is how much sh*t teams can get done in a set time frame, on average.” Whether that’s measured in story points, cycle time, story counts, or whatever, velocity should never be viewed as good, or bad.
- Keeps backlog correct in Jira — This goes back to my earlier point of contention about “grooming,” but let’s pretend there’s a worldwide Jira outage. After the massive cheers of elation died down, due to companies’ ungodly reliance upon the product, would work come to screeching halt? If we take Jira out of the picture, does that mean we suddenly can’t manage the flow of work?
So, what was the point of this experiment? To see if folks knew what a Scrum Master does? Partly, but the main reason was to determine the underlying perceptions people have. If a random assessment suggests you’re killing it a high level, but people throughout your organization think a Scrum Master is the equivalent of a Project Manager, you’re probably way off in your actual maturity. The point is, don’t assume. Ask.
So, what does a Scrum Master do? I challenge you to pose the same question to your teams. The results might surprise you.
