How to Sabotage a Scrum Master

How to Sabotage a Scrum Master: 44 Anti-Patterns From the Trenches To Avoid

One of my favorite exercises from my Professional Scrum Master classes is how to best sabotage a Scrum Master as a member of the middle management. The exercise rules are simple: You’re not allowed to use any form of illegal activity. Therefore, outsourcing the task to a bunch of outlaws is out of the question. Instead, you are only allowed to use practices that are culturally acceptable within your organization.

Read on and learn more on how to best sabotage a Scrum Master from the exercise results of more than ten PSM I and PSM II classes. (I slightly edited the suggestions for better readability.)

The Exercise: Consider How To Best Sabotage a Scrum Master

The exercise is based on a Liberating Structure microstructure called TRIZ.

Here is the briefing for the participants: typically, there is a five-minute timebox to come up with suggestions and observations in a workgroup of three to five people.

• You are a middle manager in the IT organization, and you believe this Scrum thingy is a fad and will go away—with a little help from your side.
• Your task: As a team, come up with ideas on how to best sabotage the new Scrum Master of the first Scrum Team in your organization.

Please note that only legal and culturally accepted practices qualify as a good outcome.

Once we accomplish the first part of the exercise—aggregating sabotaging practices—the workgroup then identifies those practices to sabotage Scrum Masters they have already witnessed, followed by identifying possible ways to counter these practices.

You can categorize the results from the before-mentioned classes into six groups:

1. Messing With the Scrum Framework in General

The first category of how to best sabotage a Scrum Master is generally about disqualifying Scrum itself as a helpful framework or introducing changes to conflict with the first principles of Scrum:

• Place the blame on Scrum whenever you can, even if it is technically unrelated.
• If Scrum uncovers an obstacle in the organization, blame that on Scrum.
• Find examples of where Scrum failed in other companies to spread around.
• Talk disrespectfully in the coffee breaks with developers and the other middle managers about Scrum and the role of the Scrum Master.
• Challenge anything the Scrum Masters try to say or do.
• Ignore the Scrum Master’s offer to learn about Scrum.
• Create an ego-centric incentive system.
• Install multiple Product Owners in a Scrum Team.
• Place a proxy Product Owner in the Scrum Team and overrule all decisions.

2. Metrics and Reporting

The next bucket of useful sabotage practices are metrics, OKRs, KPIs — you name it. Just turn your Scrum Master into a glorified data-entry clerk with a challenging reporting burden:

• Ask the Scrum Master to prove their value with metrics.
• Create performance KPIs for each team member.
• Ask the Scrum Master to collect all working hours of the team members.
• Ask for individual performance metrics for every Sprint.
• Tie team member performance reviews with their average story points per Sprint using the Bell curve.
• Calculate a Scrum team budget and insist that the utilization rate of team members needs to be higher.
• Demand estimates and treat them as commitments.

3. Scrum Team Building and Management

If a challenging reporting burden does not help, sabotage your Scrum Master by actively undermining their activities to turn a group of people into a cross-functional Scrum Team:

• Only add members to the Scrum team that don’t live any Scrum values.
• Recommend the most bull-headed senior developer as the engineering team lead.
• Constantly switch Developers from one project to another, claiming emergencies that require swift action.
• Have Scrum team members regularly work on multiple different Scrum teams.
• Add in new people to the Scrum team without prior consultation.
• Alternatively, slow down the hiring or replacement processes.
• Promote a member within the Scrum team to act as a proxy manager.

4. Work Organization

If you are already messing with the Scrum Team team-building process, why not place a few obstacles into the Scrum Team’s way of working? Sabotage your Scrum Master by creating unachievable objectives while meddling with the very foundation of Scrum:

• Define unachievable objectives for the Scrum Team.
• Overload the Scrum team with requests, then complain to others that you do not get results on time.
• Hand over only fixed price, time, and scope projects to Scrum Team.
• Change requirements during the Sprint.
• Insist on hard deadlines.
• Ask the Scrum Master to provide a product roadmap with deadlines.
• Make the Scrum Master responsible for accomplishing deadlines.
• Outsource part of the product roadmap creation to an off-site team in a completely different timezone.
• Request work that would switch focus away from the Sprint Goal directly to Developers.
• Assign tasks directly to Scrum team members.
• Don’t allow Scrum Team members to speak to the customer; act as the single point of contact.
• Create unnecessary organizational bottlenecks outside of Scrum, for example, approvals gates, etc.
• Only provide inadequate equipment and tools to the Scrum team.

5. Flow of Information

Does your Scrum Master have an insatiable appetite for data, information, and knowledge? Well, keep them out of the loop then. What could be an easier way of sabotaging Scrum:

• Claim that everyone already knows what to do. There is hence a need for alignment or a Scrum Master.
• Restrain from sharing essential or valuable information with the Scrum Team.
• Encourage silo thinking by promoting a strict “need to know” basis for sharing information and knowledge.

6. Scrum Events and Other Meetings

Finally, ensure that everyone on the Scrum Team understands that your events are more important than theirs:

• As a manager, claim that there are too many Scrum events that require too much time. Instead, suggest skipping some of them.
• Require to be present at every Scrum event.
• Exclude Scrum Master from important meetings outside the Scrum Team’s events.
• Constantly pull Scrum team members into long unnecessary meetings during their Scrum team events.
• Be very understanding of the needs of the Scrum Team; for example, that stakeholders shall participate in the Sprint Review. However, never join any Scrum event yourself.

Conclusion

Every middle manager has ample opportunity to sabotage Scrum Masters. Moreover, most of the time, it will be unlikely that others will identify these practices as deliberate obstruction. Providing the benefit of the doubt and assuming positive intent, they probably get away with it. Therefore, reading these signals early in the process is vital to us agile practitioners.

What practices to sabotage Scrum Masters have you observed? Please share your learnings with us in the comments.