7 reasons your Scrum Master may be underperforming

What do you need to have a great and effective scrum master on a team?

The Scrum Master is, I think, one of the most misunderstood roles on the scrum team. It’s a critical role to ensure your team will perform at their best.

An effective Scrum Master is not just anyone who wears the Scrum Master hat for a few hours per week. I think an effective Scrum Master should have (at least) these three things:

  1. An understanding of what it means to be a Scrum Master (it sounds obvious, but evidently sometimes it’s not). A Scrum Master course is the minimum here, I think. It also includes understanding the agile manifesto, understanding lean principles and the mechanics of software development.
  2. An innate, natural desire to learn, improve and be better.
  3. The support of colleagues, the team and the organisation to be able to do the job.

I’ve seen a lot of different kinds of scrum teams, and some common themes appear when thinking about under-performing Scrum Masters. Here are some sings that you might not have the most effective Scrum Master:

  1. Your Scrum Master is responsible for 7 different teams.
  2. Your Scrum Master is just one of the developers who has the responsibility to send the calendar invites to the standups and take notes in the retrospective.
  3. Your Scrum Master is just someone from your QA team who puts cards for bugs on the story wall.
  4. Your Scrum Master cannot describe the Agile Manifesto.
  5. The only contact your Scrum Master has had with scrum or agile is the two-day CSM course (or worse, none at all).
  6. Your Scrum Master is not able to realistically change the process within which your team works in order to respond to feedback in retrospectives or improve the way of working for the team.
  7. The Product Owner or business owners ultimately responsible for the team and the product are the kind who want all the benefits, such as predictability, increased output and accountability, without changing any of their entrenched, old-school, waterfall processes.

I’m sure there are others, but if you see any of these in your scrum team, you might want to take a look at your setup. Note that these things are not always a problem with the person acting in the role, per se – many of these issues stem from organisational misunderstanding of the role as well.