Scrum Master Anti-Patterns

The reasons Scrum Masters violate the spirit of the Scrum Guide are multi-faceted. Typical Scrum Master anti-patterns run from ill-suited personal traits to complacency to pursuing individual agendas to frustration with the team itself.

Read on and learn in this post on Scrum anti-patterns how you can identify if your Scrum Master needs support from the team.

The Scrum Master 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 accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.

The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework.

Scrum Masters are true leaders who serve the Scrum Team and the larger organization.

Source: Scrum Guide 2020.

The keystone of the definition of the Scrum Master role is the leadership aspect. (Too bad, it is no longer called “servant leadership;” I found that description to be better suited.) Unfortunately, in most cases of Scrum Master anti-patterns, it is precisely this idea that an individual is not meeting. (See also the detailed lists of services rendered to the Product Owner, the Developers, and the organization by the Scrum Master as defined by the Scrum Guide.)

Possible Reasons Why Scrum Masters Leave the Path

The reasons Scrum Masters violate the spirit of the Scrum Guide are multi-faceted. They run from ill-suited personal traits to pursuing their agendas to frustration with the Scrum team. Some often-observed reasons are:

• Ignorance or laziness: One size of Scrum fits every team. Your Scrum Master learned the trade in a specific context and is now rolling out precisely this pattern in whatever organization they are active, no matter the context. Why go through the hassle of teaching, coaching, and mentoring if you can shoehorn the “right way” directly into the Scrum team?
• Lack of patience: Patience is a critical resource that a successful Scrum Master needs to field in abundance. But, of course, there is no fun in readdressing the same issue several times, rephrasing it probably, 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 Scrum cannot be pushed but needs to be pulled—that’s the essence of self-management.
• Dogmatism: Some Scrum Masters believe in applying the Scrum Guide literally, which unavoidably will cause friction as Scrum is a framework, not a methodology. Nevertheless, teaching Scrum that way feels good:
  • Team members come and ask for help; now, the Scrum Master has a purpose.
  • When Scrum team members follow the rules, the Scrum Master has influence or authority.
  • Being among the chosen few who interpret the Scrum Guide “correctly” secures status and respect among teammates and the broader organization.
  • The Scrum Master may easily attribute the Scrum team’s progress or success to their teaching; now, they also have proof regarding their mastery of Scrum.
  • Finally, their mastering of Scrum is a convincing argument for the organization to keep the dogmatic Scrum Master on the pay role; apparently, the Scrum teams need an interpreter of the Scrum Guide to reap the framework’s benefits.
• Laissez-faire turned into indifference: Pointing the team in a direction where the team members can find a solution for an issue is good leadership. However, letting them run without guidance probably turns into indifference, or worse, into an I-do-not-care mentality.
• Dolla, dolla, bill ya’ll—the Scrum Master imposter: Secretly, the Scrum Master is convinced that this 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. How hard can this probably be—the manual is merely 13 pages?” This conviction will bring out their true colors over time inevitably.
• Pearls before swine — the frustrated Scrum Master: The Scrum Master has been working their butt off for months, but the team is not responding to the effort. The level of frustration is growing. There are many potential reasons for a failure at this level: the lack of sponsoring from the C-level of the organization, a widespread belief that ‘Agile’ is just the latest management fad, and thus ignorable. The team composition is wrong. There is no psychological safety to address the team’s problems, 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 its ship around, it will probably lose its Scrum Master. Please note that the Scrum Master cannot solve this issue by themselves. Fixing this issue is an effort of the whole Scrum Team.
• The tactical Scrum Master: These Scrum Masters drank HR’s cool-aid that Scrum Master is a position, not a role. Moreover, there is a career path from Junior Scrum Master to VP of Agile Coaching. Consequently, they constrain their work strictly to the Scrum Team level until being promoted.
• Lastly, the rookie: If you apply Occam’s razor to the situation, you may conclude that your Scrum Master has not yet defected to the dark side. They might merely be inexperienced. Given that we all need to learn new skills regularly, cut some slack in this case, and reach out to support the learning effort. Remember, it is a journey, not a destination, and you do not travel alone.

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 time, thus contributing at an appropriate level to the business agility of the organization. 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 Master or Scrum team assume, for example, responsibility for pay-role? Would that help with creating value for the customer? Probably less so. Hence, being a self-organizing team does not mean the absence of management per se. However, it does mean that there is no need for micromanagement comparable to practices at a General Motors assembly plant in 1926. The Scrum Master is neither a supervisor nor a dispatcher.
• Running meetings by allowing someone to speak: When team members seek eye contact with the Scrum Master before speaking out, the Scrum Master has already left the facilitation role in favor of the supervisor mode.
• Keeping the Scrum team dependent: In this scenario, the Scrum Master pampers the Scrum team to a level that keeps the team dependent on their services:
  • Organizing meetings.
  • Purchasing stickies and sharpies.
  • Taking notes.
  • Updating Jira—you get the idea of this service level.
    
    (More critical, however, is when the Scrum Master decides to keep the team in the dark about principles and practices to secure their job. This behavior is only a tiny step away from the dark side.)
• Pursuing flawed or dangerous metrics: While utilizing predefined Jira reports is probably a sign of ignorance or laziness, keeping track of individual performance metrics—such as story points per Developer per Sprint and reporting those to that person’s line manager—is a critical warning sign. That is a classic supervisor hack to reintroduce command & control through the back door. It inevitably leads to cargo-cult Scrum.
• Escalating under-performance: During the Sprint, the Scrum Master reports to the management whether the Scrum team will meet the current forecast or not. 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.”
• Focusing on team harmony: The Scrum Master sweeps conflict and problems under the rug by not using Sprint Retrospectives to address those openly. This behavior is often a sign of bowing to politics. Instead, the Scrum Master uses manipulation to meet organizational requirements that oppose Scrum values and principles. If the organization values its underlings for following the ‘rules’ instead of speaking the truth, why would you run Retrospectives in the first place? (A ‘Scrum Master’ participating in cargo-cult Scrum is again a supervisor than an agile practitioner.)

Scrum Master Anti-Patterns by Scrum Events

The Sprint Planning

The following anti-patterns focus on the Sprint Planning:

• 100% utilization: The Developers regularly bow to the hard-pushing Product Owner: “Last Sprint, you delivered 25 story points, and now you are choosing only 17?” Consequently, they accept more issues into the Sprint Backlog than they can stomach without the Scrum Master’s intervention. They do not address that this is a disrespectful behavior, negating the Developer’s prerogative of self-management and ignoring their need for 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, or supporting each other. A level of 100% utilization always reduces the Scrum team’s long-term productivity; it is classic Taylorist line management thinking. If 50% of all issues spill over to the next Sprint at the end of a Sprint, and this is a pattern, then your Scrum team is not practicing Scrum. Probably, it is a sort of time-boxed Kanban—which would be okay, too. Just make up your mind about how you intend to improve your customers’ life. Perhaps, Kanban would be a good choice.)
• Unrefined Sprint Backlog items: The Scrum Master does not address accepting “unrefined” Product Backlog issues into the Sprint Backlog. This choice is a sure way the Developers will probably not accomplish the Sprint Goal, rendering a core Scrum principle useless: reliably providing valuable, potentially shippable Product Increments every single Sprint. (This refers to regular work, not emergencies.)

The Sprint

The following Scrum Master 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 for how stakeholders can interrupt the team’s flow during a Sprint. Any of the following examples will impede the team’s productivity and might endanger accomplishing the Sprint Goal:
  • The Scrum Master has a laissez-faire policy as far as access to the Developers is concerned. Notably, they are not educating stakeholders on the negative impact of disruptions and how those may endanger accomplishing the Sprint Goal. Note: I do not advocate that Scrum Masters shall restrict stakeholders’ access to team members in general.
  • The Scrum Master does not oppose line managers taking team members off the Scrum Team, assigning them to other tasks.
  • The Scrum Master does not oppose line managers adding members to the Scrum Team without prior consultation of the team members. (Preferably, the Scrum Team members should decide who is joining the team.)
  • Lastly, the Scrum Master allows stakeholders or managers to turn the Daily Scrum into a reporting session. (This behavior will impede the Developer’s productivity by undermining their self-management while reintroducing command & control through the backdoor.)
• Assigning work to Developers: The Scrum Master does not prevent the Product Owner—or anyone else—from assigning tasks directly to Developers. (They organize themselves without external intervention. And the Scrum Master is the shield of the Scrum team in that respect.)
• Defining technical solutions: An engineer turned Scrum Master is now ‘suggesting’ how the Developers implement issues. (Alternatively, the Product Owner or an outsider is pursuing the same approach, for example, a technical lead.)
• Lack of support: The Scrum Master does not support team members that need help. Often, Developers create tasks an engineer can finish within a day during their planning sessions. However, if someone struggles with such a job for more than two days without voicing that they need support, the Scrum Master should address the issue and offer their support. Making this issue visible is also the reason for marking tasks on Sprint boards with red dots each day if work items do not move to the next column. (In other words: we are tracking the work item age.)

The Retrospective

The final set of Scrum Master anti-patterns addresses the Sprint Retrospective:

• Waste of time: The Scrum team does not collectively value the Retrospective. (If some team members consider the Retrospective to be of little or no value, it is most often the Retrospective itself that sucks. Is it the same procedure every time, ritualized and boring? Have a meta-retrospective on the Retrospective itself. Change the venue. Have a beer- or wine-driven Retrospective. There are so many things a Scrum Master can do to make Retrospectives great again and reduce the absence rate. And yes, to my experience, introverts like to take part in Retrospectives, too, if appropriately facilitated.)
• Groundhog day: The Sprint Retrospective never changes in composition, venue, or length. There is a tendency in this case that the Scrum team might revisit the same issues repeatedly–it’s Groundhog Day without the happy ending, though.
• Let’s have the retro next Sprint: The team postpones the Retrospective to the next Sprint. (Beyond the ‘inspect & adapt’ task, the Retrospective shall also serve as a moment of closure that resets everybody’s mind so that the Scrum team can focus on the new Sprint. Additionally, the Scrum team shall inspect their way of working and identify opportunities to make the next Sprint more effective and fun. This is why we have the Retrospective before the Sprint Planning of the upcoming Sprint. Moreover, postponing the Retrospective into the next Sprint may interrupt the team’s flow and leave one or more critical team issues unattended for the length of a Sprint. Also, it is a slippery slope. If postponing Retrospectives becomes an acceptable approach, why have them in the first place?)
• #NoRetro: There is no Retrospective as the team believes there is nothing to improve, and the Scrum Master accepts this notion. (There is no such thing as an agile Nirwana where everything is perfect. As people say: becoming agile is a journey, not a destination, and there is always something to improve.)
• #NoDocumentation: No one is taking minutes for later use. (A Retrospective is a substantial investment and should be taken seriously. Taking notes and photos supports this process.)
• No psychological safety: The Retrospective is an endless cycle of blame and finger-pointing. (The team wins together; the team fails together. The blame game documents both the failure of the Scrum Master as the facilitator of the Retrospective and the Scrum team’s lack of maturity and communication skills.)
• Bullying is accepted: One or two team members dominate 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 their feedback free from third-party influence. If some of the team members dominate the conversation and probably even bully or intimidate 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 less valuable. It is the primary responsibility of the Scrum Master as a facilitator to ensure that everyone will be heard and has an opportunity to voice their 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: Stakeholders participate in the Retrospective. (Several opportunities in Scrum address stakeholders’ communication and information needs: the Sprint Review, listening in at the Daily Scrum, probably even the Product Backlog refinement, not to mention opportunities of having a conversation in Zoom, at water coolers, over coffee, or during lunchtime. If that spectrum of possibilities is not sufficient, consider having additional meetings if your team deems them necessary. For example, there is the opportunity to have a meta-level Retrospective, explicitly including the Scrum team’s stakeholders. However, the Retrospective as a Scrum team-internal event is off-limits to stakeholders.)

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 it with us in the comments.

Watch the Replay of the Webinar on Scrum Master Anti-Patterns

The video of the webinar is available now:

Note: If the browser will not start the video automatically, click here to watch the replay of the webinar Scrum Master anti-patterns directly on Youtube.