Scrum adoption is growing, and not just in the software industry. Known for its simplicity, it’s an increasingly popular framework for organizing teams to deliver complex products. Scrum guidelines are just that— guidelines, not a complete methodology — perhaps that’s why there’s some confusion over what, exactly, the Scrum Master is supposed to do.

The Scrum Master Role

When it comes to keeping things moving and on task, the Scrum master plays a pivotal role. They’re responsible for making sure everyone understands the theory behind Scrum — as well as the rules, values, and practices that make Scrum work. Acting as both servant and leader for the team, the Scrum Master is also one of the most misunderstood positions on the Scrum Team. Here, we’ll address six of the most stubborn myths that surround the role of Scrum Master.

Let’s Tackle The Myths

Myth # 1: The Scrum Master is a Clerk

The Scrum Master role is an evolutionary role. A team’s first attempt at filling the role might be choosing someone from the development team who’s good at organizing things. Maybe they’ll start out as a sort of administrator, relieving the rest of the team from some of the more mundane, everyday tasks like preparing the Spring Planning or updating the Sprint Backlog.

But if a team stopped there with this limited definition of the Scrum Master, they’d really be missing out on the benefits of having someone playing the fully-developed role. A clerk simply documents things — which is only a tiny part of what the Scrum Master does.

Myth #2: The Scrum Master is an Assistant

Which is worse: thinking the Scrum Master just documents things and keeps things organized, or thinking the Scrum Master is a personal assistant to everyone on the team? Like myth 1, this myth also involves a very limited definition of the Scrum Master’s duties. Scheduling all the events in everyone’s agenda might sometimes be part of the role, but again, it’s not under the guise of a personal assistant. Rather, it’s to facilitate the Scrum values, highlighting dysfunction, and guiding improvement.

When people believe that the Scrum Master is just an assistant, it sometimes stems from the fact that they don’t respect non-technical Scrum Masters. It’s not necessary to have a technical background to perform the kind of guidance that people in this role are supposed to provide. They don’t need to be writing code — they just need to help the team understand and follow the Scrum framework, using an evidence-based approach and enabling collaboration.

But of course, working in software development, they should really know about technology. They should understand some basics if they’re going to help the team. Again, they don’t need to know how to code, but they do need to understand what’s involved (like what it means to refactor, for example) and how good code can affect the speed and cost of making changes in the future).

Myth #3: The Scrum Master is the Scrum Police

Scrum Masters are supposed to be fully cognizant of Scrum Values described in the manifesto, and how certain Scrum techniques help the team achieve these values. But they’re not there with a clipboard and a copy of the manifesto, checking to see whether Scrum is followed exactly by the “rules”.

Scrum is about values. Once learned and absorbed, these values will begin to change the way each team member thinks and acts during Scrum events. In other words, “doing” Scrum right means living the values, not simply performing the right actions under the watchful eye of a misguided Scrum Master playing the role of Scrum Police.

Myth #4: The Scrum Master is the Team Boss

Hiring and firing team members is somebody’s role, but it’s not part of being a Scrum Master. Or at least it’s not the most important part — simply because the Scrum Master isn’t the boss. In fact, the person chosen for the role is quite often one of the development team members, not even a former team leader. And obviously as such, they’re not in charge of people’s salaries, either, which is a boss role and has nothing to do with Scrum values get carried out.

Myth #5: The Scrum Master is the Tools Admin

Adding configurations and setting permissions in JIRA, TFS, or any other tool needs to be done by someone, but again, that’s nothing to do with being a Scrum Master.

Myth #6: The Scrum Master is the Organization President

Does the Scrum Master ask everyone’s status during the Standup? Well, it could happen but Standups are self-organized by the team, not led by the Scrum Master. In fact, the Scrum Master doesn’t even need to be present at the Daily Scrum or the Standup. They can show up and participate, but they’re not there to lead.

But, What Exactly is a Scrum Master?

Truth #1: The Scrum Master is a Servant-Leader

If you think the term “servant-leader” sounds a little confusing and very much like an oxymoron, don’t worry: you’re not alone. What does is mean? No worries, it is a common question! The main goal of a servant-leader is to enhance and increase teamwork and personal involvement. As a Scrum Master, you must create a participative environment, empowering team members by sharing power and decision-making.

Truth #2: The Scrum Master is a Facilitator

Being a facilitator involves skills that are complementary to being a servant leader. As a scrum master, you can bring dynamics to help your team make decisions, remove impediments, resolve conflicts, and generally create a space where every team member can give opinions and add value.

Truth #3: The Scrum Master is the Agent of Change

It is possible that you’ll find some organizations out there that work with no Agile methodology. It’s up to the Scrum Master to help and encourage a culture shift to provide the proper environment in which a team can really thrive.

What’s Next?

As you can see, being a Scrum Master is far and away different from being a secretary, a clerk, or a team boss. So don’t be one of those — work hard as you evolve toward the expert Scrum Master level. And finally, do your best to be a good example and help bust these myths!