Ten dysfunctional Scrum Master patterns

There's a lot of material out there on what a Scrum Master allegedly is and does, although many of the tips are indeed antipatterns that will keep the team from ever reaching top performance. So let's take a look at what a Scrum Master is NOT. Here are ten dysfunctions in the Scrum Master role - and better alternatives!

The nurturing parent

A recurring theme with Scrum Masters who think they're doing a good job while actually achieving the opposite is that they take the role of a parent for the development team. The term "Scrum Mom" has been coined as an antipattern, although the issue goes much further and deeper.

Brief detour into psychology
Let me refer the unaware reader to Eric Berne's book, "Games People Play" for the full mechanics of Parent-Child dynamics. For brevity sake:

Eric Berne suggests that people are always in one of three so-called "ego states" - Parent, Adult or Child. Transactions among adults or between parent and child are "stable". Others are "crossed" (i.e. broken / unstable). Consequently, by assuming a "parent" role, one pushes others into a "child" role and vice versa.
The more frequent this happens, the stronger a parenting Scrum Master will instill childish behaviour and attitude within the organization!

The blue transaction among adults is "stable".
The crossed brown transaction is unstable - the trigger doesn't match to the response!

The Pamperer

To paraphrase Atlassian, the Scrum Master may want to do any kind of thing that's required to get the team to hum - fixing hardware, changing room temperature, bringing coffee and whatnotever.
This brings us into the "I'm only trying to help" game described by Berne: Team members get used to absolving themselves of taking care of their own basic necessities.
This eventually brings the Scrum Master in a defensive position: They constantly have to guess what other people need, and if anything goes wrong, developers might turn against the Scrum Master with blame.

Adults find taking care of their basic needs part of their own identity, and will enjoy an environment where they can do this by themselves: It instills a sense of autonomy and control.
The Scrum Master should get NEAR to the team, help them become aware of their own needs and build an environment where people can meet their own need with little effort.

The Protector

A common misconception is that the Scrum Master should cotton-wrap the team in a cozy little bubble, safely protected from "the mean outside world" so that developers can focus on writing software. This creates two separate issues: First, developers lack the interactions and understanding to figure out what's going on around them. Second, it creates another unhealthy mechanic: Dependency. Developers become unable to cope with the surrounding organization, relying on the Scrum Master.
Again, the Scrum Master ends up fighting a losing battle: If they do a perfect job, everyone will push organizational issues on them - and if they make the slightest mistake, they will be blamed for inadequacy.

The Scrum Master's responsibility is to educate people - both within the team and around - which interactions are helpful and which aren't. Avoid the trap of buffering these interactions. Unhelpful interactions cause conflict, and defusing this conflict is part of the growth process. Learn conflict resolution techniques.

The Facilitator

Yet another common misconception is that the Scrum Master has to organize things for the team - such as, when meetings take place, who is invited and what the agenda is, then to facilitate the show. This is just a specific form of pampering - developers assume that the Scrum Master knows best (sly "Tangled" reference) about meetings.  Continuously organizing or facilitating meetings is not a Scrum Master responsibility, lest we fall into the "TAGAWI" game where meetings won't be held if not for the Scrum Master. Especially new Scrum Masters will not realize that they're falling for a game and thus are very likely to lose.

The Scrum Master's responsibility is educating developers initially why and how to conduct Scrum events like a Retrospective, so that they can learn the importance of these meetings and how to make them valuable. Instead of organizing meetings, the Scrum Master is well advised to let developers take this responsibility and help them sustain this practice.

The decision maker

In many organizations, a Scrum Master may make decisions either as a surrogate manager, a spokesperson or as representative of the team. While it's valid that the Scrum Master represents a decision that has already been made, the Scrum Master is not a decision maker!

The Surrogate Manager

When teams move to self-organization, they may occasionally feel lost, because decisions that were made by others for them now lie with the team. As such, they might look to the Scrum Master to fill this decision gap. It does provide a sense of safety and comfort to let others make decisions in times of turmoil - even if that decision is wrong, the responsibility rests elsewhere. Long story short, if the Scrum Master caves in, they fall for a parent role, stopping the team from becoming truly self-organized.

The Scrum Master might want to explore with the team "Why" the team wants the Scrum Master to make this decision and "What" will happen as an outcome. By facilitating the right discussions, the Scrum Master empowers the team to make their own decisions and live up to it - propelling self-organization!

The Spokesperson

Developers may also ask the Scrum Master to fetch a decision that rests elsewhere in the organization. Terrible Scrum Masters will assume that they can make a decision instead, which will put them into the worst possible position: if they get it right, they still usurped another person's position, if they get it wrong, everyone will blame them.
Bad Scrum Masters will run off diligently to find out from the decision maker. They just fell for a game: the team plays the "helpless child" and looks to the Scrum Master for a solution.

Rather than acting as an intermediary, the Scrum Master should build networks of people, connecting others directly. If needed, the Scrum Master may need to act as a facilitator in meetings so that a mutually acceptable solution can be worked out.

The representative

In a video by Atlassian, they suggest that the Scrum Master should represent the team in backlog refinement. While it's okay for the Scrum Master to represent a specific decision the team has already made, the Scrum Master lacks the understanding of content and technical background to communicate details on behalf of the team. As such, the Scrum Master is always guessing and still likely to make mistakes.
It's very misguided to believe that a non-technical person can decide on technical details, and the details are what makes or breaks the outcome. This sacrifices effectiveness in the name of "efficiency", turning teams into "delivery factories" (another parent-child dynamic).

When teams keep out of meetings which provide an opportunity to acquire essential information and provide essential feedback, there is probably a strong parent-child dynamic at work - either developers are being pressed into a "child mould", or they are themselves in child mode and press others (for example, management or the Product Owner) into a "parent mould".

The Scrum Master should carefully examine why this is happening - oftentimes due to fear or negative organizational culture.

The bouncer

I cringe whenever I hear that a Scrum Master should act as bouncer, shooing people away from the team. Why? Because people have needs. When others feel the need to interact with the team and get called off, this will most likely trigger resentment and other negative emotions which will eventually have a backlash. Acting as a bouncer, the Scrum Master creates two separate parent-child dynamics: Towards the team (sheltering) and towards the outsider (controlling communication).

The Scrum Master should get NEAR to the approaching person, then learn why this need exists and how it can be met. One-on-one interaction can build a more positive working environment and may lead to different solutions than what the approaching person originally intended.

It's incredibly important for the Scrum Master to help others, irrespective of whether within or outside the team, to find ways to meet their needs on an "Adult" level.

The Ambassador

Occasionally, the Scrum Master may be asked or feel tempted to represent the team towards outsiders, so that the team doesn't get interrupted. This makes the Scrum Master a filter of information and a translator, both of which can become incredibly dangerous.

What a Scrum Master may do is have first discussions to see if the interaction is indeed helpful for the team and the organization, and if this is the case, they should bring people together directly in the most effective way.

Further reading

I have hinted at the book "Games people play" by Eric Berne.

Other books in this context are:

• TA Today by Ian Stewart and Vann Joines.
• Transactional Analysis in Psychotherapy by Eric Berne.
• I'm OK, You're OK by Thomas Harris.

Note that the reading of these books will not make you a professional therapist or psychoanalyst, and I strongly encourage you to stay out of trying to do therapy or wielding this knowledge as a tool - although understanding these things gives you a much better understanding of what's going on. 
Do NOT, and I can't emphasize this enough, do not start calling out transactional dynamics within your team or use TA interventions loosely. You're going to leave a trail of devastation.
Much rather, I invite you to silently reflect on how you are contributing to the situation and what you yourself can do to improve.