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 to up his or her agile game.
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.
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.
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 itscontext.
- 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.
- 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 the Scrum Master. Note, that the Scrum Master cannot solve this issue by herself or himself. This is an effort of the whole Scrum Team.
- 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 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 be 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 dedicates his or her work to 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 & 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 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 Sprint Retrospectives to address those openly. This behavior is often a sign of bowing to politics and instead 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. A level of 100% utilization always reduces the team’s long-term productivity. A utilization rate of 100% 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 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 improving your customers’ life. Perhaps, Kanban would be a good choice.
- Unrefined 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 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 that either stakeholders or managers 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:
- 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.) li>
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 is currently available as a Kindle ebook. Shortly, the paperback version will be available, too.
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.
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
27 Sprint Anti-Patterns Holding Back Scrum Teams
28 Product Backlog and Refinement Anti-Patterns
The post Scrum Master Anti-Patterns — 20 Signs Your Scrum Master Needs Help appeared first on Age of Product .