The eighth Hands-on Agile webinar Scrum Master Anti-Patterns addresses twelve anti-patterns of your Scrum Master — from ill-suited personal traits and the pursuit of individual agendas to frustration with the team itself.
Companies Mentioned
Coin Mentioned
TL;DR: Webinar Scrum Master Anti-Patterns
The eighth Hands-on Agile webinar Scrum Master Anti-Patterns addresses twelve anti-patterns of your Scrum Master — from ill-suited personal traits and the pursuit of individual agendas to frustration with the team itself.
The Replay of the Webinar Scrum Master Anti-Patterns Is Available
Talking truth to power and shielding the journey—not the team—to become agile
Let us start the webinar Scrum Master anti-patterns with a short refresher from the Scrum Guide. According to it, the “Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand the theory, practices, rules, and values of Scrum. The Scrum Master is a servant-leader for the Scrum Team.” Finally, 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.”
The first Scrum Master anti-pattern covers the agile manager. Self-organization does not mean the absence of management: why handle pay-role as a Scrum Team? Outsourcing of tasks to the management is hence common. However, Scrum is by all means not about exercising command & control; the Scrum master is not a supervisor. Typical signs of Taylorism are: providing working agreements to speed up the getting productive phase of a new or inexperienced team, turning the daily scrum into reporting session, pushing the team to take more on during sprint planning, assigning sub-tasks to developers, or defining technical solutions: The engineer turned SM and is now ‘suggesting’ how the scrum team implements tasks.
The second Scrum Master anti-pattern covers the Scrum team secretary and Scrum parents. The Scrum parent is generally shielding the team from the cold and cruel world, creating a safe & happy agile bubble. Some manifestations are: the Scrum parent deals with all impediments personally, although practically any other team member could act, too. The Scrum parent filters feedback from stakeholders, particularly any negative feedback. Often, she does so by not merely restricting access to the team, but shutting it off. The Scrum parent is pampering the team, for example by running errands, or being the team secretary, sometimes bordering on the helper syndrome. The Scrum parent is also preventing the team from failure whenever possible. This even applies, if failing would be easily fixable and wouldn’t be damaging. (Empiricism is based on learning which is inevitably linked to failure. The Scrum parent is not challenging the team. She seems to be content, once a certain level of proficiency is achieved. (What about Kaizen?) The Scrum parent is maybe setting boundaries but is rarely enforcing them. She tends to tolerate damaging behavior from a team member in the (futile) hope the culprit will be insightful and improve over time.
The third Scrum Master anti-pattern covers the imposter. Dolla, dolla, bill ya’ll — the Scrum Master imposter believes that this agile/scrum thingy is a fad — how hard can it be, the Scrum Guide is just 17 pages. “I will weather the temporary decline in demand for project managers by getting a scrum master certificate.”
The fourth Scrum Master anti-pattern covers Scrum dogmatism. The Scrum Master enjoys teaching (and never leaves the Shu-phase). The Shu Ha Ri model is based on the patterns of achieving mastery. Ultimately, the student shall surpass the master. There are three stages: 1) Shu: Follow the rule (=> teaching by the Scrum Master). 2) Ha: Break the rule (=> Coaching by the Scrum Master). 3) Ri: Be the rule. (=> Advising by the Scrum Master.) The problem is: teaching feels good. The team members come and ask for help (=> purpose), people are following the rules (=> influence or authority), and the Scrum Master can easily attribute the team’s progress or success to his or her teaching. However, to become self-organizing, the team needs to move beyond the Shu-phase. The most prominent anti-pattern in this situation is a mechanical application of Scrum, creating empty rituals which leads to cargo cult Scrum.
The fifth Scrum Master anti-pattern covers failing at the capacity game. The Scrum master does not address the necessity of slack time by fighting the push for 100% utilization. Technical excellence is the route to agility — see the ‘State of DevOps Report’ or ‘Accelerate’ by Nicole Forsgren und Jez Humble. A Scrum team’s effectiveness will be significantly impeded if the team does not address technical debt every sprint. The team will also suffer if there is no time for pairing, mobbing, training, and knowledge sharing. 100% utilization always reduces the team’s long-term productivity. Note: it is not immediately visible, it is deteriorating over time. A utilization rate of 100% is classic, old taylorist line management thinking for the industrial age.
The sixth Scrum Master anti-pattern covers the flow undermining Scrum Master. The Scrum Master allows stakeholders to disrupt the flow of the development team during the sprint. For example, the SM has a laissez-faire policy as far as access to the development team is concerned. Or the Scrum Master does not object that the management invites engineers to random meetings as subject matter experts. Or the Scrum Master allows that either stakeholders or managers turn the daily scrum into a reporting session.
The seventh Scrum Master anti-pattern covers the Scrum Master with a metrics fetish, pursuing flawed metrics. The Scrum Master keeps track of individual performance metrics such as story points per developer per sprint. Even worse, the Scrum Master probably reports the metrics to that person’s line manager. This is a supervisor hack to reintroduce command & control through the back door.
The eighth Scrum Master anti-pattern covers the Scrum Master ignoring Scrum values. As the Scrum Guide puts it: “When the scrum values of commitment, courage, focus, openness, and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone. Successful use of Scrum depends on people becoming more proficient in living these five values.”
The ninth Scrum Master anti-pattern covers the skipped Retrospective. All Scrum events are essential for a team’s success — you cannot skip any event. Junior Scrum teams may be tempted to skip Retrospectives to buy some more time to meet the sprint goal. A Scrum Master accepting this “deal” is a Scrum Master by title only. The proposal is already a sign of how important the team needs a retrospective.
The tenth Scrum Master anti-pattern covers the Groundhog-Day retrospective. The retrospective never changes in composition, venue, or length. In this case that the team will likely revisit the same issues over and over again — it’s groundhog day without the happy ending, though, an empty ritual.
The eleventh Scrum Master anti-pattern covers the manager alert at retrospectives. The Scrum Master permits stakeholders and worse–line managers — to participate in the team retrospective. In this case, the team should refuse to participate. What are alternatives? Run a separate overall retrospective with stakeholders or point at other Scrum ceremonies that address the communication needs of stakeholders: the sprint review, probably the product backlog refinement, the daily scrums. A tricky situation is the line manager also serving on the Scrum team. My tip: avoid this at all costs; a promotion means that you probably also need a new team member.
The twelveth Scrum Master anti-pattern provides food for thought: what if your scrum master is frustrated? The Scrum Master has been working his or her butt off for months, but the team is not responding to the effort. (Pearls before swine?) Good Scrum Masters are in for a purpose; they want to have an impact. There are a lot of potential reasons for 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. There is no failure culture — learning by failure is merely lip service. The company culture does not value transparency. Or individual team members harbor personal agendas unaligned with the team’s objectives. (=> Incentives are based on individuals, not the team.) The Scrum Master cannot solve these issues by herself or himself. The cooperation of the team is required to drag the Scrum Master out of the frustration.