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.
Do you want to get this article in your inbox? You can sign up here and join 26k 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.)
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.
Download the ’Scrum Anti-Patterns Guide’ for Free.
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 invention. 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.) 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.)
The Retrospective
The final set of 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.
- 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.)
- 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.)
✋ 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.
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