When the Scrum Master Role is Set Up to Be an Anti-Pattern

Sometimes an organization struggles to understand the value proposition of a Scrum Master. The role of Scrum Master is quintessentially a team coaching and service leadership focused job. A good Scrum Master helps a new Scrum team quickly get to a point of stable performance and realistic planning. They help the team embrace the patterns of small scale, experimental adaptation that will eventually lead to high performance. But in a real-world sense, the bulk of the Scrum Master’s work is done by talking to people and asking questions. It doesn’t show up as tasks on the team’s Scrum board, or as deliverables that can be claimed on some end-of-month Status report to some far-flung client.

If you’ve never experienced what a good Scrum Master does for a team, it’s easy to misunderstand the role as being administrative: scheduling team meetings, taking notes on impediments, nagging people to update the status of things. When that happens, it’s natural for decision makers to feel that the role of Scrum Master is not a real job, and therefore decide not to invest time or money into it. At that point, one of several anti-patterns typically happens. Here are the ones I see most often:

Scrum Without ScrumMasters

If you don’t know what a Scrum Master is for, then why pay for one? Wouldn’t we get more value from funding another Developer? Unfortunately, no.

First off, adding more people to a team is no guarantee that the team will produce more output (to say nothing of more value, which is a separate consideration altogether!). Every time we add a person to a group, the between-person communication channels on that team increase exponentially. That means that larger teams are typically worse at delivery than smaller ones because they have a harder time self-organizing and collaborating. Beyond considerations of team size, it’s not trivial for a new team to figure out the day-to-day mechanics of functioning as a team.

With a good Scrum Master, it typically takes anywhere from 5-7 sprints to go through Tuckman’s phases of “forming” and “storming” before they enter a state of “norming.” Without a Scrum Master? That’s going to take a lot longer, if at all. More likely, they stay in a continual state of “storming.” That is, bouncing around on fundamental practices like estimating and planning without getting to a place that will eventually let them bridge from “norming” into “high performing.” And what if the group is not only new to being a team, but also new to Scrum? And new to the organization they work within? That’s so many complications and impediments to manage in a workday. How will they have the time to build anything?

Scrum Masters with Too Many Teams

Imagine an organization that thinks Scrum Masters are just schedulers and task chasers, but feels they need to have a named person in the role for sake of appearance. So they designate a person as Scrum Master, but require them to span multiple teams. If all they do is book meetings, then they can easily do that for two, three, or even four teams, right? Anyone person taking that role has been set up to fail, because they’ll never have the time and attention have a meaningful impact on any of those teams.

You can’t coach if you aren’t around enough to understand team members on a human level. When impediments arise, you’ll be so caught up in the tactical aspects of resolution that you won’t have the focus to step back, understand the systemic causes of impediments, and then work to keep them from popping up again. And, honestly, it’s optimistic to think that a Scrum Master spanning several teams would even have time to resolve impediments. Most likely, the ‘job’ would be reduced to cataloging impediments and nagging teams to update the status of tasks.

Combining the Scrum Master and Product Owner Role

Generally I see this pattern come up about from one of two directions. The first is an official decision to combine the Scrum Master and Product Owner role for reasons like economy. For example, the thought that Scrum Masters just book meetings, so the Product Owner can do that in their spare time. Then we only have to pay one person.

The other is an unofficial realization that the official Product Owner isn’t doing any actual Product Ownership, and the Scrum Master steps into the gap by becoming some kind of ‘proxy Product Owner.’ They try to cover the mechanical aspects of behavior like backlog refinement without the authority to make choices about vision or priority. Either way, the effect is the same: one person with too many jobs and an innate conflict of interest.

The Scrum Master role typically delivers the most value when it’s set up as a full-time job per Scrum team. The Product Owner role is typically at least a full-time job per product (and potentially more than that, depending on things like scaling and the complexity of the product domain). So, how would one person have the hours in a day to both reasonably well? In my experience, they don’t.

And beyond the time issue, both roles are supposed to represent points of view that are fundamentally in tension. In the interest of delivering maximum value, Product Owners are constantly requesting ‘more stuff’ from their teams. As coaches, Scrum Masters are constantly asking questions like “are we planning and working at a sustainable pace?” If one person represents both sides of those conversations, at least one point of view is sacrificed.

Combining the Scrum Master and Developer Role

The most common structural anti-pattern I see with the Scrum Master role is when it is combined with that of Developer. Sometimes this is done with the best intentions. “We know the Scrum Master role is important, so you’re a Scrum Master first and a Developer with whatever time you have left over in the sprint.”

However well-meaning, this creates a with a time-conflict problem and another conflict of interest issue. Starting with the time issue, for a good Scrum Master, there isn’t a lot of leftover time in the sprint for them to do Developer work. For the rest of the Developers on the team, it’s like getting a part-time, unplannable teammate. And then there’s the conflict of interest if two team members are arguing about the best to solve a problem, the Scrum Master is focused on issues like, “Is this pattern of conflict constructive or destructive?” It’s really hard to do that if you also advocating one side of the dispute at the same time.

Sometimes this happens because the institution has decided that the role doesn’t deliver value but tagging a Developer to do both jobs is their way of checking a box that Scrum Masters exist. This creates the same two problems discussed above and adds a new one. Whoever gets tagged as the Developer/Scrum Master has just been unofficially told that Developer is their real job, because the company doesn’t think Scrum Master is a real thing. That means the person probably shouldn’t invest a lot of time in to trying to be good at it, right? Their performance reviews, compensation, and career advancement are still going to be focused on what they do as a Developer, and it’s not possible for them to fulfill the Scrum Master responsibilities meaningfully.

So Then What Happens?

The net effect of any of these options is the same: the organization has created a self-defeating loop.

This creates an institutional inertia that resists ever fostering an environment where Scrum Masters can deliver value. Imagine trying to argue from the inside that the solution is to make a meaningful investment in the role. “Why? There’s all this internal data that shows the position doesn’t contribute to value.” That becomes a very tough case to make.

So, how can you do it? In my experience, there aren’t any magic bullets. The easiest way to cut through this kind of entrenched misunderstanding is with external perspective. Skilled and experienced Scrum Masters who’ve done the job for real somewhere else. Expert Agile coaches with the stories and data to show what’s happened elsewhere when the position of Scrum Master is understood and valued. People who can show that coaching and service leadership focus of Scrum Masters is a crucial part of how Scrum teams form, grow, and thrive.

If you’re looking for someone who can help you make these arguments, our amazing Agile coaches have got you covered. For more information, contact visit nextupsolutions.com/coaching.