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

TL; DR: Scrum Master Anti-Patterns

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 post on Scrum anti-patterns how you can identify if your Scrum Master needs support from the team.

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

Update 2019-12-01: Two years after its publishing, I re-edited the article, extended the section on Scrum Master duties according to the Scrum Guide and fixed some minor bugs.

Do you want to get this article in your inbox? You can sign up here and join 24k other subscribers.

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 standard that an individual is not meeting. (See also the detailed lists of services rendered to the Product Owner, the Development Team, and the organization by the Scrum Master as defined by the Scrum Guide.)

Upcoming Scrum and Liberating Stuctures training classes and workshops — Berlin Product People GmbH

Possible Reasons Why Scrum Masters Leave the 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 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 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 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-organization.
  • Dogmatism: Some Scrum Masters believe in applying the Scrum Guide literally which unavoidably will cause friction as Scrum is a framework, not a methodology.
  • 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, 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 18 pages?” This conviction will bring out his or her true colors over time inevitably.
  • 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 its ship around the team will probably lose its Scrum Master. Note, that the Scrum Master cannot solve this issue by herself or himself. This 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 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 learning effort. Remember, it is a journey, not a destination, and you do not travel alone.

Cannot see the form?
Please click here

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, thus providing an appropriate level of business agility to 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 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. 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 neither a supervisor or 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 already left the facilitation role in favor of the supervisor mode.
  • Keeping the Scrum team dependent: In this scenario, the Scrum Master pampers the team to a level that keeps the team dependent on his or her 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 his or her job. This behavior is only a small 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 and instead of using manipulation to meet organizational requirements that are opposing 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 Development Team regularly bows to the hard pushing Product Owner—“last Sprint, you delivered 25 story points, and now you are choosing only 17?”—and accepts more issues into the Sprint Backlog than it can stomach without the Scrum Master’s intervention. He or she does not address that this is a disrespectful behavior, negating the Development Team’s prerogative of self-organization and ignoring its need for slack time. (The 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 team’s long-term productivity; it is classic taylorist line management thinking.)Scrum Master Anti-Patterns: Fight 100% Utilization of the Team If at the end of a Sprint 50% of all issues spill over to the next Sprint and this is 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 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 the acceptance of “unready” Product Backlog issues into the Sprint Backlog. This is a pretty sure way that the Development Team will not deliver the Sprint goal, rendering a core Scrum principle useless: providing a valuable, potentially shippable Product Increment at the end of the Sprint. (This refers to regular work, not emergencies.)

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 for how stakeholders can interrupt the flow of the team during a sprint. Any of the examples will impede the team’s productivity and might endanger the Sprint goal. 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. Particularly, he or she is not educating stakeholders on the negative impact of disruptions and how those may endanger the accomplishment of the Sprint goal.
    • The Scrum Master does not oppose line managers taking team members off the team assigning other tasks.
    • The Scrum Master does not object that the management invites engineers to random meetings as subject matter experts.
    • The Scrum Master turns a blind eye to mid-Sprint changes of priorities by the Product Owner.
    • 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 members of the Development Team. (It organizes itself without external intervention. And the Scrum Master is the shield of the team in that respect.)
  • Defining technical solutions: An engineer turned Scrum Master is now ‘suggesting’ how the Development Team is implementing 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 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 and offer his or her support. By the way, this is also the reason for marking tasks on a physical Sprint board with red dots each day if tasks do not move to the next column. (In other words: we are tracking the work item age.)
Scrum Master Interview Question: free download of the most popular ebook on Scrum Master job interviews — by Age-of-Product

The Retrospective

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

  • Waste of time: The 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.)
  • Groundhog day: The Retrospective never changes in composition, venue, or length. There is a tendency in this case that the Scrum team might revisit the same issues over and over again–it’s groundhog day without the happy ending, though.Scrum Master Anti-Patterns — Retrospective Groundhog Day — Age-of-Product.com
  • Let’s have the retro next Sprint: The team postpones the Retrospective into 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 team can focus on the new Sprint. Additionally, the Scrum Team is supposed to pick at least one important action item for the upcoming Sprint. This is why we have the Retrospective before the Sprint Planning of the following Sprint. Postponing it into the next Sprint may interrupt the flow of the team and will probably leave one or more important team issues unattended for the length of a Sprint.)
  • #NoRetro: There is no Retrospective as the team believes there is nothing to improve. (There is no such thing as an agile Nirwana where everything is just 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 as well as the team’s lack of maturity and communication skills.)Scrum Master Anti-Patterns — Blame Game — Age-of-Product.com
  • 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, and probably 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 less valuable. It is the main 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: Stakeholders participate in the Retrospective. (There are several opportunities in Scrum that address the communication and information needs of stakeholders: the Sprint Review, the Daily Scrum, probably even the Product Backlog refinement, not to mention opportunities of having a conversation at water coolers, over coffee, or during lunchtime. If that spectrum of possibilities still is not sufficient, consider having additional meetings if your team deems them necessary. However, the Retrospective is off-limits to stakeholders.)

📕 Now Available: ‘How to Get Hired as a Scrum Master’

Scrum Master Career: How to Get Hired as a Scrum Master: From Job Ads to Your Trial Day — Learn How to Pick the Right Employer or Client details how Scrum Masters and Agile Coaches can systematically identify suitable employers or clients to avoid mismatches and disappointments at a later stage. If you are planning a career move into the Scrum Master profession, don’t miss out on these tips.

Scrum Master Career: How to Get Hired as a Scrum Master by Age-of-Product

Scrum Master Career: How to Get Hired as a Scrum Master is available as a Kindle ebook or as a paperback.

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

The video of the webinar is available now:


Scrum Master Anti-Patterns — (Hands-on Agile Webinar #8)

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.

✋ Do Not Miss Out: Join the 6,300-plus Strong ‘Hands-on Agile’ Slack Team

I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.

Join the Hands-on Agile Slack Group

If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.

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.

The Scrum Master Anti-Patterns — Related Posts

Product Owner Anti-Patterns — 31 Ways to Improve as a PO

27 Sprint Anti-Patterns Holding Back Scrum Teams

28 Product Backlog and Refinement Anti-Patterns

11 thoughts on “Scrum Master Anti-Patterns — 20 Signs Your Scrum Master Needs Help”

  1. I have observed most of the anti pattern mentioned with Retrospectives.

    One of the team where I worked with, product owner was not interested at all with retrospectives and no matter what we talked to him, he somehow ignore to attend and worst case scenario, not much inputs shared even joins.

  2. Hi,
    I just detected a little typo. at least it looks to me like a typo
    “…without the Scrum Master’s invention…”

    I guess it should be “intervention”

  3. Hi Stefan,

    How would a scrum master working as a contractor and handling a client team deal with the following when after objecting there is no support from the client:
    1> Line managers taking team members off the team assigning other tasks.
    2> Management invites engineers to random meetings as subject matter experts

    What are the best ways to make the client management realize the impacts of not listening to the objections for the above?

  4. Åkos,

    If team members truly can’t say no, my suggestion is to track and make visible the cost. Then plan the subsequent Sprints with a set-aside for the moving average of actual. This is similar to what I do for ops support.

  5. Hi Stefan – very enjoyable post! Here is another anti-pattern – coordinating/leading a daily scrum. When first teaching the team there is transition period where you are teaching what is done and how to make it an effective daily planning event. That needs to quickly change to the team running it with the SM listening for coaching opportunities later and understanding what anti-patterns that you need to help address directly or indirectly. Other times you can join a team that is already mature enough and you just observe and let it continue looking for many of the patterns you already listed.

  6. The worst scrum master Ive ever seen went to extremes to protect herself and the team from management. She defined the BA as product owner and had them report to her. She persuaded exec’s that the work was so confidential that it had to be kept secret from the product team. The cards on the scrum board were all in code. No-one was allowed to access the JIRA board or team folders. There were no written progress reports. No-one was allowed to talk to the team. If anyone in the business tried to go to a scrum ceremony the meeting was mysteriously moved or cancelled. If anyone started asking questions she would undermine them aggressively with the Sponsor to get rid of them. She got herself a 40% bonus and complete protection from accountability all in the name of agile self management.

  7. Hello Akos, my first question is, of course, why can’t you say ‘no’ to immediate conference calls? Isn’t dealing with customers the job of the support engineers? (They are supposed to shield the development team(s) exactly from this disturbance.)

    When dealing with internal stakeholders, the following process worked for me in the past: Firstly, collect data on who is how often interrupting the flow. A great tool for this purpose is the interruption bucket from Jimmy Janlen, see: http://www.barryovereem.com/toolbox-for-the-agile-coach-visualization-examples/. Secondly, attach costs of delay to these interruptions. (Include the necessary time to get back into the flow as well.) Then kindly confront the perpetrators with the damage they are producing.

  8. Dear Stefan,

    Do you have any idea how to protect my team members from being invited to random meetings as area experts? My first idea was to make such meetings a part of baclog grooming but it wouldn’t work. We have many impatient customers from various timezones who demand ASAP clarifications on technical issues via conference calls. And we simply can not say ‘no’.
    It really destroys the flow and the team became so resignated that they stopped objecting it on retrospectives… I feel helpless about it.

Leave a reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.