A problem-solving exercise used in Professional Scrum Master training asks participants to sabotage a Scrum Master using only legal, culturally acceptable methods. The results—44 distinct anti-patterns organized into six categories—double as a diagnostic checklist for organizations wondering why their Agile implementations keep failing.
The unsettling finding: most destruction is accidental. Nobody needs to try.
How the Exercise Works
Groups of three to five participants have five minutes to generate sabotage methods, constrained only by legality. The technique borrows from TRIZ, a framework that inverts problems to reveal solutions.
Participants then map these methods to behaviors they have actually witnessed in their own organizations. The gap between the generated list and real experience reveals how invisible these patterns have become.
The Six Categories of Sabotage
1. Framework Disqualification
Undermine Scrum's legitimacy without evidence. Blame the framework whenever obstacles appear—even unrelated ones. Cite failures at other companies. Speak dismissively about the role during casual conversations. Challenge everything the Scrum Master proposes. The goal is spreading doubt, not discovering truth.
2. Metrics Overload
Transform the Scrum Master into a data entry clerk. Request proof of value through metrics. Tie individual performance reviews to story points using bell curves. Demand utilization reports and hour tracking. Calculate team budgets expecting higher utilization. The time spent reporting replaces time spent coaching.
3. Team Composition Disruption
Recruit members who resist Scrum values. Rotate developers between projects for "emergencies." Assign team members to multiple Scrum teams simultaneously. Add people without consultation. Alternatively, slow all recruitment and team changes. Stability collapses; trust follows.
4. Authority Erosion
Install multiple Product Owners with conflicting priorities. Insert proxy decision-makers who undo team agreements. Promote a senior developer to act as shadow manager. Make the Scrum Master responsible for deadlines they cannot control. The role becomes ceremonial.
5. Goal Manipulation
Set unattainable sprint targets. Load the team with requests, then complain about missed deadlines. Transfer only fixed-price, fixed-scope projects. Change requirements mid-sprint. Insist on detailed roadmaps with hard dates. Request work that shifts focus directly to developers, bypassing the sprint goal.
6. Ceremony Disruption
Cancel events when leadership is busy. Shorten planning to fifteen minutes. Treat standups as status reports for management rather than team synchronization. Skip retrospectives when time runs short. Each cancellation signals that the framework is negotiable.
—
Who Should Care About These Anti-Patterns
| Role | Why It Matters | Primary Risks |
|---|---|---|
| Executives | Agile investments fail to deliver ROI | Wasted transformation costs, missed market timing |
| Middle Managers | Accountability without authority | Blame for failures they cannot prevent |
| Product Owners | Conflicting direction fragments priorities | Delayed value, stakeholder confusion |
| Developers | Unstable teams erode trust and morale | Burnout, turnover, skill stagnation |
| Scrum Masters | Cannot coach while fighting organizational friction | Role abandonment, career stagnation |
—
Why This Matters
If you recognize one or two items, the problem is manageable. If you recognize five or more, your Scrum Master is fighting organizational inertia while being held accountable for outcomes.
The patterns accumulate because each decision seems reasonable in isolation. Nobody plans to destroy Agile implementation. The sabotage emerges from a thousand small compromises.
The deeper trade-off: organizations want Scrum's outputs (faster delivery, higher quality) without Scrum's constraints (stable teams, self-organization, empirical process). You cannot have one without the other.
What to Watch Next
The exercise suggests a simple intervention: during retrospectives, explicitly ask whether any of these anti-patterns are present. Naming them reduces their power. The goal is not to eliminate all friction—some is inevitable—but to prevent its accumulation.
Key takeaways
- Most Scrum destruction is accidental, not intentional
- Metrics overload converts facilitators into administrative staff
- Stable team composition is foundational; disruption destroys trust
- Authority erosion happens gradually through proxy roles and conflicting directives
- Naming anti-patterns in retrospectives reduces their impact
Frequently asked questions
Are these anti-patterns common in organizations transitioning to Agile?
Yes. Organizations moving from traditional project management tend to carry old habits into new frameworks. The patterns feel normal until they are named.
Can a Scrum Master succeed despite these patterns?
Possibly for a short period. Sustained success requires organizational awareness and deliberate removal of the underlying causes.
How do I identify these patterns in my own organization?
Run the TRIZ-style exercise with your leadership group. Compare the generated list to what your Scrum Master reports. The gaps reveal invisible friction.
Is metrics overload always harmful?
Team-level metrics can provide useful signals. Individual metrics tied to sprint output create perverse incentives that distort behavior and undermine collaboration.
What is the single most damaging anti-pattern?
Splitting the Product Owner role—having multiple stakeholders with conflicting priorities—creates direction problems that no amount of Scrum Master facilitation can resolve.