Scrum Master Anti-Patterns: 20 Signs Your Scrum Master Needs Help

Scrum Master Anti-Patterns: The reasons why Scrum Masters violate the spirit of the Scrum Guide are multi-faceted. They run from ill-suited personal traits and the pursuit of individual agendas to frustration with the team itself.

Read on and learn in this final post on Scrum anti-patterns how you can identify if your Scrum Master needs support from the team to up his or her Agile game.

The Scrum Master According to the Scrum Guide

Before we start dissecting probable reasons and manifestations of Scrum Master anti-patterns let us revisit how the Scrum Guide defines the role of the Scrum Master:

The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.

The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

Source: Scrum Guide 2017.

The keystone of the definition of the scrum master role is the servant leadership aspect. In most cases of scrum master anti-patterns, it is precisely this part that the individual is not living up to.

Possible Reasons Why Scrum Masters Leave the Agile Path

The reasons why Scrum Masters violate the spirit of the Scrum Guide are multi-faceted. They run from ill-suited personal traits via the pursuit of own agendas, to frustration with the team itself. Some often-observed reasons are:

• Ignorance or laziness: One size of Agile fits every team. Your Scrum Master learned the trade in a specific context and is now rolling out precisely this pattern in whatever organization he or she is active, no matter the context.
• Lack of patience: Patience is a critical resource a successful Scrum Master needs to field in abundance. Of course, there is no fun in readdressing the same issue several times, rephrasing it properly, if the solution is so obvious—from the Scrum Master’s perspective. So, why not tell them how to do it ‘right’ all the time, thus becoming more efficient? Too bad, that Agile cannot be pushed but needs to be pulled.
• Dogmatism: Some Scrum Masters believe in applying the Scrum Guide literally which unavoidably will cause friction. 
• Laissez-faire turned into indifference: Pointing the team in a direction where the team members themselves can find a solution for an issue is good leadership. Letting them run without guidance, however, quickly turns into indifference, or worse, into an I-do-not-care mentality.
• Dolla, dolla bills ya’ll—the Scrum Master imposter: Secretly, the Scrum Master is convinced that this Agile/Scrum thingy is a fad, but recognizes that it is a well-paid one: “I will weather the decline in demand for project managers by getting a Scrum Master certificate.” This conviction will, inevitably, bring out his or her true colors over time.
• Pearls before swine — the frustrated Scrum Master: The Scrum Master has been working his or her butt off for months, but the team is not responding to the effort. The level of frustration is growing. There are a lot of potential reasons for a failure at this level: the lack of sponsoring from the C-level of the organization, a wide-spread belief that ‘Agile’ is just the latest management fad, and thus ignorable. The team composition is wrong. There is no psychological safety to address problems within the team, and the company culture values neither transparency nor radical candor. Or individual team members harbor personal agendas unaligned with the team’s objective — just to name a few. If the Scrum team does not manage to turn the ship around the team will probably lose the Scrum Master. Note, that the Scrum Master cannot solve this issue by herself or himself. The cooperation of the team is required.
• Lastly, the rookie: If you apply Occam’s razor to the situation, you may also conclude that your Scrum Master has not yet defected to the dark side. He or she might merely be inexperienced. Given that we all need to learn new skills regularly, cut him or her some slack in this case, and reach out to support the effort.

The Scrum Master as Agile Manager

In my eyes, ‘agile management’ is an oxymoron. The primary purpose of any Agile practice is empowering those closest to a problem with finding a solution. In other words, the team shall become self-organizing over the course of time. Self-organizing teams need coaches, mentors, and (servant) leaders, however, not a manager in the Taylorist meaning of the word. 

Watch out for the Scrum Master anti-patterns corresponding to this ‘agile manager’ attitude:

• Agile management: Self-organization does not mean the absence of management: why would a Scrum team assume, for example, responsibility for pay-role? Would that help with creating value for the customer? Probably not. Hence, being a self-organizing team does not mean the absence of management, per se. It does mean, however, that there is no need for micromanagement comparable to practices at a General Motors assembly plant in 1926. The Scrum Master is not a supervisor.
• Running meetings by allowing someone to speak: When team members seek eye-contact with the Scrum Master before speaking out, the Scrum Master already left the facilitation role in favor of the supervisor mode.
• Burn-down chart enforcer: The Scrum Master focuses his or her work on producing a daily update to the burn-down chart. If the team considers a burn-down chart useful and the Scrum Master accepts to update it, so be it. I still believe, though, that a current Sprint board serves the same purpose at a glance without adding a new administrative layer. However, if the burn-down is solely maintained to track the output for reporting purposes the team needs to challenge this attitude. 
• Pursuing flawed metrics: The Scrum Master keeps track of individual performance metrics such as story points per developer per Sprint, probably to report to that person’s line manager. That is a classic supervisor hack to reintroduce command and control through the back door. It inevitably leads to cargo-cult Scrum.
• Escalating under-performance: The Scrum Master reports to higher levels that the Scrum team will not meet the current Sprint commitment or forecast. I took this from a job offer I received: “You will coordinate and manage the work of other team members, ensuring that timescales are met and breaches are escalated.” Perhaps, we should also reintroduce running the gauntlet for underperformers while we are at it?
• Focusing on team harmony: The Scrum Master sweeps conflict and problems under the rug by not using retrospectives to address those openly. This behavior is often a sign of bowing to politics and instead using manipulation to meet organizational requirements that oppose Scrum principles and values. If the organization values its underlings for following the ‘rules’ instead of speaking the truth, why would you run effective retrospectives in the first place? A ‘Scrum Master’ participating in cargo-cult Agile is again more of a supervisor than an Agile practitioner.

Scrum Master Anti-Patterns by Scrum Ceremony

Scrum Master Anti-Patterns During the Sprint Planning

The following anti-patterns focus on the Sprint planning:

• Oversized Sprint backlog without objection: The team regularly accepts more issues into the Sprint backlog than it can stomach without the Scrum Master's intervention. If at the end of a Sprint, 50% of all issues spill over to the next Sprint and this becomes a pattern then your team is not practicing Scrum. Probably, it is a sort of time-boxed Kanban—which would be okay, too. Just make up your mind on how you intend to improve your customers’ life. Perhaps, Kanban would be a good choice.
• Unrefined stories accepted into the Sprint backlog: The Scrum Master does not address the acceptance of issues into the Sprint backlog, thus violating the team’s definition of ready. This is a sure way that the Scrum team will not deliver the Sprint goal, rendering a Scrum principle useless: providing a potentially shippable product increment at the end of the Sprint (this refers to regular work, not emergencies).
• 100% utilization: The product owner squeezes additional (functional) work into the Sprint Backlog, and the Scrum Master does not address the necessity of slack time. (The scrum team’s effectiveness will be significantly impeded if the team does not address technical debt every Sprint. It will also suffer if there is no time for pairing, for example. A level of 100% utilization always reduces the team’s long-term productivity. A utilization rate of 100% is classic Taylorist line management thinking.)

Scrum Master Anti-Patterns During the Sprint

The following anti-patterns focus on the mishandling of the Sprint itself:

• Flow disruption: The Scrum Master allows stakeholders to disrupt the flow of the Scrum team during the Sprint. There are several possibilities of how stakeholders can interrupt the flow of the team during a Sprint. Any of the examples will impede the team’s productivity. The Scrum Master must prevent them from manifesting themselves: 
  • The Scrum Master has a laissez-faire policy as far as access to the development team is concerned. 
  • The Scrum Master does not oppose line managers taking team members off the team and assigning them other tasks.
  • The Scrum Master does not object when the management invites engineers to random meetings as subject matter experts.
  • The Scrum Master turns a blind eye to mid-Sprint changes of the Sprint Backlog lacking the approval of Scrum team.
  • Lastly, the Scrum Master allows either stakeholders or managers to turn the Daily Scrum into a reporting session. 
• Assigning sub-tasks to developers: The Scrum Master does not prevent the product owner—or anyone else—from assigning tasks directly to engineers. (The development team organizes itself without external intervention. And the Scrum Master is the shield of the team in that respect.) 
• Defining technical solutions: The engineer turned Scrum Master and is now ‘suggesting’ how the Scrum team is implementing issues.
• Lack of support: The Scrum Master does not support team members that need help with a task. Often, development teams create tasks an engineer can finish within a day. However, if someone struggles with such a job for more than two days without voicing that he or she needs support, the Scrum Master should address the issue. By the way, this is also the reason for marking tasks on a physical board with red dots each day if tasks do not move to the next column.

Scrum Master Anti-Patterns During the Retrospective

The final set of anti-patterns addresses the Sprint retrospective:

• Groundhog day: The retrospective never changes in composition, venue, or length. There is a tendency in this case that the team will revisit the same issues over and over again – it’s groundhog day without the happy ending, though.
• Let’s have it next Sprint: The Scrum Master postpones the retrospective into the next Sprint. Beyond the ‘inspect and adapt’ task, the retrospective shall also serve as a moment of closure that resets everybody’s mind so that the team can focus on the new Sprint goal. That is the reason why we have the retrospective before the planning of the follow-up Sprint. Postponing it into the next Sprint may interrupt the flow of the team. It also delays tackling possible improvements by up to a Sprint.
• #NoRetro: The Scrum Master does not gather data during the Sprint that supports the team in the upcoming retrospective. This could also be a sign of frustration, see above.
• #NoDocumentation: The Scrum Master does not take minutes for later use. A retrospective is a substantial investment, and the Scrum team should take it seriously. Taking notes and photos supports this process.
• No psychological safety: The retrospective is an endless cycle of blame and finger pointing without intervention from the Scrum Master. The team wins together, and the team loses together. The blame game documents both the failure of the Scrum Master as the facilitator of the retrospective as well as the team’s lack of maturity and communication skills.
• Bullying is accepted: One or two team members are dominating the retrospective. This communication behavior is often a sign of either a weak or uninterested Scrum Master. The retrospective needs to be a safe place where everyone–introverts included–can address issues and provide his or her feedback free from third-party influence. If some of the team members are dominating the conversation, or even bullying or intimidating other teammates, the retrospective will fail to provide such a safe place. This failure will result in participants dropping out of the retrospective and render the results obsolete. It is the primary responsibility of the Scrum Master to ensure that everyone will be heard and has an opportunity to voice his or her thoughts. By the way, equally distributed speaking time is according, to Google, also a sign of a high-performing team. Read More: What Google Learned From Its Quest to Build the Perfect Team.
• Stakeholder alert: The Scrum Master permits stakeholders to participate in the retrospective. There are plenty of Scrum ceremonies that address the communication needs of stakeholders: the Sprint review, probably the product backlog refinement, the Daily Scrums, not to mention the opportunities to have a conversation at water coolers, over coffee, or during lunchtime. If that spectrum of possibilities still is not sufficient, feel free to have additional meetings. However, the retrospective is off-limits to stakeholders, and the Scrum Master needs to enforce this rule.

Scrum Master Anti-Patterns: The Conclusion

There are plenty of possibilities to fail as a Scrum Master. Sometimes, it is the lack of organizational support. Some people are not suited for the job. Others put themselves above their teams for questionable reasons. Some Scrum Masters simply lack feedback from their Scrum teams and stakeholders. Whatever the case may be, though, try and lend your Scrum Master in need a hand to overcome the misery. Scrum is a team sport.

What Scrum Master anti-patterns did I miss? Please share with me in the comments.

Download the Scrum Anti-Patterns Guide

This ebook covers over 160 Scrum anti-patterns, and it is available for free right here. Download the “The Scrum Anti-Patters Guide” now!