Seven sins of a Scrum Master
The Scrum Master will never be responsible for the success of the product. However, they have an important role in helping those who are, the product owner and the team.
A good Scrum Master can significantly increase the odds of success. Similarly, a bad Scrum Master can derail everything, causing disastrous failure. In this article, I will look at seven bad characteristics or behaviours of Scrum Masters I have witnessed.
- Not understanding Scrum
- Mixing or not understanding the Scrum Master role
- The curling parent
- Not understanding the work of the team
- Not being there
- Being busy doing the wrong thing
- Ignoring the bigger picture
Some of these, I’ve seen in other Scrum Masters but in other cases, I must admit, I have been the culprit myself.
Either way, the result wasn’t good!
1. Not understanding Scrum
The Scrum Guide introduces the role of the Scrum Master as follows:
The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.
It should go without saying but to be able to do that, a Scrum Master must have a solid understanding of Scrum. Unfortunately, someone being a Certified Scrum Master (CSM) is no guarantee they will have more than a very basic understanding of Scrum. After all, there is only so much you can learn during a two-day course.
Becoming a Scrum Master requires a big mindset-switch for many people. I know from my own experience, starting as a project manager, that this can take time.
Bad Scrum Masters lead to bad Scrum
As is sometimes pointed out: Scrum is simple but not easy. If the Scrum Master doesn’t have a deep understanding of Scrum and why the different parts are important, one of the following is likely to happen:
- It becomes very hard to coach someone you don’t understand yourself. Scrum risks turning into process for process’ sake, causing the team to experience the overhead of the framework without getting all of the benefits.
- The Scrum Master and the team end up taking shortcuts or making damaging changes to the framework. Yes, there may be cases when it makes sense to break the rules of Scrum but if we do so, we need to make sure the spirit of the framework is followed.
When reading blog posts claiming that Scrum sucks or that Scrum doesn’t work, the arguments are in many cases built on a misunderstanding of what is or isn’t Scrum. With more than 400,000 Certified Scrum Masters out there, I think it’s fair to say that some of those are guilty of creating such misunderstandings.
A Scrum Master must always strive to learn more
Someone being a certified master at something may make it sound as if they know it all. To be successful as a Scrum Master, we need to realise as soon as possible that’s not the case. There are endless possibilities to increase our knowledge.
Sharing experiences with other Scrum Masters is a great way to learn. You may also be fortunate enough to live in a city with a thriving Meetup scene, with lots of free talks. The internet is full of blog posts, such as this one, just waiting to be read and there are lots and lots of books too.
However, experience comes from doing. That’s how we learn. Some things we do work well and others much less so. Whatever happens, don’t let valuable learnings go to waste!
2. Mixing or not understanding the Scrum Master role
The Scrum Master role is new to many companies. Often, it doesn’t even exist in the organisation chart. This can easily lead to the role getting misunderstood, diluted or combined with other roles. Either through the organisation having the wrong expectations on what a Scrum Master does or through the Scrum Master being hungry for more responsibility.
A couple of such unfortunate combinations are those of the Project Manager Scrum Master and the Deputy Product Owner Scrum Master.
The Project Manager Scrum Master
A project manager is responsible for the planning and execution of a project. This includes things like managing objectives, scope and dependencies, as well as people (often referred to as “resources”). In Scrum, however, this particular role doesn’t exist. Instead, the product owner is responsible for making sure the right product is being built, through setting objectives, managing the backlog and collaborating with the team to make sure their solutions meet the intentions of the product. The team decides how to deliver the work. This includes the technical approach as well as who does what and how to respond to day to day issues.
If a Scrum Master mixes their role with that of a project manager, there is a big risk they will interfere with the other Scrum roles, preventing the framework from working as intended. One such pitfall (and trust me, I’ve been there) is when the Scrum Master starts micro-managing the team, assigning tasks and thereby preventing their self-organisation.
The Deputy Product Owner Scrum Master
On some teams, the Product Owner doesn’t have enough time available to fulfil their responsibilities. Some may not have time to attend the sprint planning meeting or the sprint review. Others don’t have time to keep the backlog up to date or to get into the details of the features.
It may feel necessary for the Scrum Master to step in and take on the responsibilities that don’t get fulfilled. The problem, however, arises when these responsibilities start conflicting with those of the Scrum Master role. For example, if the Scrum Master will be the person getting the heat from the stakeholders when some feature isn’t finished in time, it is very easy for them to end up paying less attention to the team keeping a sustainable pace.
When the product owner is not sufficiently available, the solution should not be for the Scrum Master to take on a bigger responsibility for the product. Instead, they need to find ways to help the product owner to make more time available for the team.
3. The Curling Parent
Being a Scrum Master can sometimes feel like being a parent. The same way a parent wants their offspring to do well in life, we want our teams to succeed. And that is a very good thing! However, it can easily go too far.
In Sweden, we have an expression for a certain kind of parents: curling parents. Just like curling players sweeping the ice in front of the stone, they do everything to remove all obstacles so that their kids can go through life without a bump. While well-intended, this prevents the children from developing their necessary life skills and make them ill-equipped to deal with problems.
The Scrum Master equivalent is the one who spots and removes all impediments for the team. And whatever the team does, the Scrum Master accepts it or even encourages it.
The over-protective Scrum Master prevents learning
When a Scrum Master shields the team from reality too effectively, they will prevent the team from performing as well as they can.
Kids are tougher than some give them credit for and so are team members. For instance, if there is a deadline, the team needs to know. They also need to understand the consequences of missing the deadline. I don’t mean in a “You will be sacked” kind of way but in a “We’d miss important business from the such-and-such tradeshow” one. Don’t hide from the team that what they do is important! Likewise, while it is probably not useful for the team to be shouted at by a stakeholder, they need to know if stakeholders are frustrated or disappointed.
Just like in the point above, where I pointed out that Scrum Masters learn through doing, so does the team. If they don’t have to deal with problems, we limit how much they can learn. And whenever a Scrum Master steps in to save the day, they prevent the team from self-organising.
Mind you, this is not to say the Scrum Master should watch silently if the team is about to walk into an unrecoverable disaster. After all, letting a child walk out in front of an approaching lorry is unlikely to teach them much.
Don’t remove all the impediments
The goal of a Scrum Master shouldn’t be to remove all the impediments for the team but rather that the impediments get removed. Otherwise, there will be a single point of failure; if the Scrum Master isn’t there, the impediments won’t get removed. Also, and equally important: the Scrum Master won’t be the best-equipped person to deal with every impediment that comes up. Often, peers talking to peers is much more effective!
A Scrum Master needs to coach and mentor the team
A Scrum Master is not just a facilitator. They also need to coach and mentor the team. When the team is inexperienced with Scrum and agile, they won’t magically know how Scrum is supposed to work. In these cases, the Scrum Master will need to be more directive when it comes to processes than on an experienced team. Sometimes, the team needs to get a chance to see things in practice by the Scrum Master directing the process.
This can admittedly be tricky with an unconvinced team. A Scrum Master has no power to force anyone to do anything. Instead, they need to make their case and get the team on-board. When making suggestions, being able to share stories like “one team I worked with solved a similar problem by…” will be much more powerful than “according to the Scrum Guide…”. Another way to convince people to do something is to suggest it as an experiment for a sprint and see how it goes.
Another part of coaching the team is to help them hold themselves accountable. A Scrum Master should not be afraid to point out when something is wrong if other team members don’t. For example:
“I’ve noticed that you’ve missed the sprint goal you set yourselves for the last three sprints. Why is that? What are you going to do about it?”
Or:
“Guys, delaying the testing until the next sprint means you don’t deliver anything shippable. That would be bad as blah blah blah”
4. Not understanding the work of the team
A Scrum Master doesn’t have to come from a developer background. However, I’ve certainly found it useful to understand on some level what the team are doing when I’m trying to help them. Both from a technical perspective and what the product is aiming to achieve. I wouldn’t be able to do the job of a developer these days but I strongly believe that having some developer skills makes me better at my job as a Scrum Master.
Understanding what the team are working on helps me spot issues and better grasp what causes them. Being a Scrum Master also requires an amount of respect. Being knowledgeable is one way of building that respect. Otherwise, I’d risk being just a process guy.
Scrum doesn’t work in isolation
Not everyone is a developer, tester or designer and very few are skilled at everything. That’s fine! That’s why we’ve got those people on the team.
However, as Scrum Masters, we should strive to understand as much as we can of what’s going on:
- We need to take an interest in the work of the team. That includes spending time with them so we can see and hear what’s going on.
- When there is something we don’t understand, we should try to learn more. Either we can get someone to explain or we can make a note and look it up on the web later.
- Talk to the Product Owner to understand the product and its goals better (I also find I learn a lot about the product when I get a chance to go along to user testing).
And if you feel particularly brave, and if it’s not too disruptive to the work of the team, how about a bit of pairing?
5. Not being there
The first rule of being a Scrum Master is to be present. While I might have just made that rule up, a large part of the job is to hear and see what is going on. Much of the communication in a team will be verbal and that requires the Scrum Master to be there to hear it.
If the Scrum Master spends too much time away from the team, whether it is meeting stakeholders, working from home or attending conferences, they won’t be able to do their job as well as they could.
In my opinion, it is overly strict to say that every team needs their own, dedicated Scrum Master. Often, they do in the beginning but when the team and their process is working well, their Scrum Master may well have some spare capacity. However, even so, Scrum Masters should not be spread too thinly. For me, the limit tends to be two teams. Beyond that, there are just too many meetings to be able to do much else.
6. Being busy doing the wrong thing
The purpose of a Scrum Master isn’t taking meeting notes or creating timesheet reports. Neither is it to keep the task board or Jira up to date. If a Scrum Master becomes the go-to person for everything or if a large part of their time is taken up by admin duties, it will limit how well they will be able to do fulfil their Scrum Master responsibilities. A Scrum Master spending their time doing the wrong things is troublingly similar to the previous point, not being there at all.
Some of these activities may be forced upon the Scrum Master. Others they happily take upon themselves. For instance, I can find it quite satisfying to create nice-looking charts or well-structured wiki-pages with lots of information. It is up to us as Scrum Master to ask ourselves frequently: is this really the most valuable thing I could be doing right now to help the team succeed?
7. Ignoring the bigger picture
Issues outside of the team may have a significant impact on what the team can achieve. However, it is often temptingly easy (and more comfortable!) for a Scrum Master to just focus on the team. They are the people we work with every day and we’ve hopefully had the chance to build up a certain amount of respect for each other. The factors outside of the team are harder to deal with, so we accept them as that’s how it’s always been.
The reach of a good Scrum Master goes far beyond the team
When solely focusing on improving things directly within the team’s control, the result likely result is sub-optimisation. The team ends up spending a lot of effort to achieve very small improvements, as they are only able to work around the problems rather than solving them. For instance, imagine a project needs to meet a fixed functional specification. Such a specification is in direct conflict with the concept of emerging requirements that are at the heart of Scrum. Sure, it is possible to optimise how to deliver what is asked for, but that won’t necessarily deliver the desired outcome of the project.
For an inexperienced Scrum Master or within a very hierarchical organisation, it can be easier said than done tackling problems outside of the team. It may take a lot of tools and techniques. Some examples:
- Talk to people. Yes, it can be that easy – or hard, depending on how you look at it! Talking directly to someone can achieve things much quicker than a potentially contentious email. And sometimes a casual chat by the coffee machine is much easier than arranging a formal meeting.
- Team up with other Scrum Masters. If an issue is affecting a lot of people in the company, chances are it will get more attention.
- Use hard numbers to make the case, e.g. “The team lost a man-week just in the last sprint working around this problem”.
- Coach people outside of the team, too. It’s not just the team who need to understand how and why Scrum works!
- Find allies. Find the people we can make understand what we’re trying to achieve and make use of their support. Maybe the line manager of the team members? Or the product owner’s boss?
The good news is that sometimes, once we dare to take that step outside of our comfort zone, the change isn’t even that hard after all! Just because something has always been in a certain way doesn’t mean there is a good reason for it.
Conclusion
Does showing these behaviours make someone a bad Scrum Master? Well, they certainly won’t contribute as much to the team’s success as they should and could. However, in my opinion, the only genuinely bad Scrum Master is the one who doesn’t learn. Just like the processes in the teams, we need to continuously improve ourselves. That’s how we get great.
♻️ I republished this blog post here 22 November 2019 with minimal changes. The date below is when it was originally published on my old blog.
Back to blog
This work by Magnus Dahlgren is licensed under a Creative Commons Attribution 4.0 International License.