7 Tips to Be a Successful Scrum Master [In-Depth Post]

How can you be a more successful Scrum Master? To answer this question, we spoke to Heather Sills. Heather started her career in Scrum as a Product Owner, but in the past three years she’s worked as a Scrum Master in a couple different companies, such as TomTom and Marlon. 

In this post, we go over Heather’s 7 tips for becoming a better Scrum Master:

  1. Confirm That the Scrum Ceremonies Are in Place
  2. Be a Coach
  3. Make the Scrum Ceremonies More Engaging
  4. Look for Answers Outside of Your Team
  5. Develop a Good Relationship with the Product Owner
  6. Don’t Become the Go-To Impediment Solver
  7. Engage with Your Team Individually

Note: Throughout the article, you’ll see an emphasis on keeping up with Scrum ceremonies, such as daily standups and retrospectives. Click here to learn about Geekbot, our asynchronous software that is used by Scrum teams looking to run quicker and less disruptive standups, retrospectives, and other remote work check-ins in Slack. 

1. Confirm That the Scrum Ceremonies Are in Place

While it may sound obvious, it’s critical for a Scrum Master to confirm that all Scrum ceremonies are being utilized by the Scrum team. 

“With new teams, it’s important to focus on the basics. Follow the Scrum Guide by the book and inspect and adapt from there, because it’s a lot harder to develop strong processes if you don’t know where you’re starting from.” 

“With more seasoned teams, it’s important to ensure that they haven’t given up on ceremonies.”

For example, Scrum Masters may encounter a development team who have collectively decided to stop doing daily standups because they think they’re a waste of time. But daily standups have value and it’s the job of a Scrum Master to make sure they’re being held properly so developers can see the value. 

Another example is running a Sprint Retrospective. If your Sprint Retrospectives don’t lead to changes and improvements in future sprints, your Scrum team will slowly “check out” and eventually stop doing retrospectives altogether. But the answer isn’t to quit the ceremony, but to weed out the anti-patterns that are undermining the effectiveness of your processes. 

If ceremonies aren’t in place, a good Scrum Master finds out why. 

“One of the core components of Scrum is inspecting and adapting,” Heather says. “If Scrum ceremonies aren’t being used, the first thing I do is try to figure out why.”

Note: We know from firsthand experience that standups, retrospectives, and other Scrum ceremonies can be inefficient (i.e. take too much time or disrupt the team’s workflow). That’s why we created Geekbot, an asynchronous meeting tool that lets agile teams run faster and less disruptive standups, retrospectives and other remote work check-ins in Slack. Learn more here and sign up for a free 30 day trial.

2. Be a Coach

“Scrum Masters are sometimes described as the facilitator of a team,” Heather says, “and that’s true, but you’re often running into team members who are either inexperienced in Scrum matters or know Scrum but aren’t actively buying into the processes and meetings.”

This is where, as a Scrum Master, you need to actively coach your team. 

“A good Scrum Master is proactive in helping your team members understand the value of Scrum ceremonies and meetings. For example, a developer may complain, calling the standup a waste of time. An ineffective Scrum Master caves in — perhaps to avoid confrontation — but a good Scrum Master engages with the developer, understands why they think the standup is a waste of time, identifies the problem, and works to resolve it.”

3. Make the Scrum Ceremonies More Engaging

You don’t need to reinvent the wheel to make Scrum ceremonies more engaging, and simple things can go a long way. For example, if you’re holding in-person, collocated standups, consider holding them outside if the weather is nice. 

If you’re holding asynchronous standups that rely on text-based responses, add another question for your team to answer, such as “What’s your favorite movie?”, or “What’s the best book you’ve read recently?”

But also don’t be afraid to think out of the box. Heather was once part of a scrum retrospective where participants had to draw, not write, how they’d describe the previous sprint.

“Someone drew a relaxing beach with cocktails. Another person drew a rainy, cloudy day. This is not only fun and new, but revealing and it lends itself to the purpose of the retrospective — which is identifying things that need to change or keep going forward.”

Plus, by having your team draw instead of write, you’re breaking up the normal pattern, and when you break up patterns, you learn new things. A soft-spoken developer who is used to feeling like sprints are overwhelming might just say “the sprint was fine” or “the sprint was normal” but by drawing out how the sprint went, they may reveal more information than usual. 

Note: If you’d like to get more ideas on how to make Scrum Ceremonies more engaging, we’ve published two articles that could help: 

4. Look for Answers Outside of Your Team

“When you’ve been a Scrum Master on a team for a substantial length of time,” Heather says, “you can struggle to see outside of your team, which limits the solutions available to you.”

To keep your edge — and to find valuable insights that can help your team — Heather recommends:

  • Listening to podcasts or reading blogs and books about Scrum leadership
  • Shadowing another Scrum team for a sprint
  • Having meetings with other Scrum Masters and comparing notes or anecdotes

Heather adds, “you can also ask your organization to send you to Scrum conferences or enroll you in training courses.”

5. Develop a Good Relationship with the Product Owner

Scrum Masters and Product Owners have clearly defined roles in the Scrum Guide.

A Scrum Master is in charge of leading the Agile development team. They are responsible for establishing Scrum practices and processes within a team, helping everyone understand how Scrum works and the value it brings. 

Product Owners are personally accountable for maximizing the value of the final product developed by the Scrum team. So they often manage the product backlog and are working with both the team and its customers.

But the reality is more complicated, especially when it comes to delegating out smaller responsibilities and deciding who has final say in certain areas.

“There’s different interpretations of the two roles, so you need to be clear: what is the Scrum Master’s responsibility? What is the Product Owner’s responsibility? The last thing you want is a Scrum Master and Product Owner arguing over whose job is what.”

By clearly defining roles, two things happen.

  1. You alleviate a lot of the burden a Product Owner may feel. Product Owners can often get delegated (or take on) more tasks than they ought to. By being an actively involved Scrum Master — and by discussing which tasks you’re going to be responsible for — you provide a valuable relief to your Product Owner.
  2. You remove any ego from the relationship. After discussing each other’s roles, it’s easier for both parties to reach out and help make each other more effective in their jobs. 

6. Don’t Become the Go-To Impediment Solver

“One of my more controversial tips is making sure you don’t become a go-to impediment solver,” Heather says. 

She explains that sometimes Scrum Masters want to improve processes so much that they’ll feel obligated to solve problems for their team, so their developers can stay focused on tasks related to building a better product. 

“But you could get to the point where that’s all you’re doing as a Scrum Master (running around and fixing problems). As a result, the team becomes overly reliant on you, and they’re not actually learning how to solve those problems themselves”. 

Heather is a firm believer that the sign of a really good Scrum Master is being able to disappear (i.e. go on holiday for a few weeks) while the team carries on without noticing you’re gone. If that’s the case, it means that when a problem comes up, the team has already gotten into the habit of fixing it themselves and being more self-reliant. 

7. Engage with Your Team Individually

While processes are critical, Heather talked to us about how a good Scrum Master doesn’t overlook the people who make the team. 

“Sometimes there’s a misconception that a Scrum Master is only a managerial role where you tell people what to do, instead of taking the time to get to know the team as a group of individuals. This isn’t true and it’s counterproductive. A rookie mistake for Scrum Masters is to start focusing on building better products faster without getting to know the personalities and characters of the individuals on their team.”

The risk of overlooking people is substantial. You can end up with a team that isn’t happy; a team that’s just doing their job without fully engaging with the product, and therefore you’re not getting the best out of them. 

But if, as Scrum Master, you engage and connect with your team as individuals then they’re much more likely to engage back, which leads to improved processes, as well as a much more enjoyable work culture. 

For example, let’s say you started as a Scrum Master for a new team. If you don’t take the time to engage with everyone on a personal level, you may overlook developers who aren’t as comfortable speaking their mind in a public setting, but have a lot of valuable things to say. But if you better understand their personality, then you can take the necessary steps to alleviate that problem (i.e. actively encourage them and give them motivation to express themselves). 

Final Thoughts

We’d like to thank Heather Sills for helping us craft this post! To sum it up, her 7 tips for becoming a better Scrum Master are:

  1. Confirm That the Scrum Ceremonies Are in Place
  2. Be a Coach
  3. Make the Scrum Ceremonies More Engaging
  4. Look for Answers Outside of Your Team
  5. Develop a Good Relationship with the Product Owner
  6. Don’t Become the Go-To Impediment Solver
  7. Engage with Your Team Individually

Leave a Reply

Your email address will not be published. Required fields are marked *