The Frustrated Scrum Master — When All the Effort Leads Nowhere

TL;DR: The Frustrated Scrum Master — When All the Effort Leads Nowhere

There are plenty of failure possibilities with Scrum. Given that Scrum is a framework with a reasonable yet short "manual," this effect should not surprise anyone. One failure symptom of a botched agile transformation is the frustrated Scrum Master.

Join me and explore the consequences of a Scrum Master who has thrown in the towel in 92 seconds.

The Job of the Scrum Master According to the Scrum Guide

The Scrum Guide features a humongous list of Scrum Master accountabilities:

The Scrum Master serves the Scrum Team in several ways, including:

• Coaching the team members in self-management and cross-functionality;
• Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done;
• Causing the removal of impediments to the Scrum Team’s progress; and,
• Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.

The Scrum Master serves the Product Owner in several ways, including:

• Helping find techniques for effective Product Goal definition and Product Backlog management;
• Helping the Scrum Team understand the need for clear and concise Product Backlog items;
• Helping establish empirical product planning for a complex environment; and,
• Facilitating stakeholder collaboration as requested or needed.

The Scrum Master serves the organization in several ways, including:

• Leading, training, and coaching the organization in its Scrum adoption;
• Planning and advising Scrum implementations within the organization;
• Helping employees and stakeholders understand and enact an empirical approach for complex work; and,
• Removing barriers between stakeholders and Scrum Teams.

Source: Scrum Guide 2020.

Being a true leader without any authority, a Scrum Master is heavily dependent on support from other people and the "system" itself.

Generally, you can spot four essential success principles for Scrum Masters, all of which require effective collaboration and communication with the other members of the Scrum Team and various stakeholders within the organization:

1. Choose Scrum for the Right Purpose

Choosing the appropriate application area for Scrum is essential. Referring to the Stacey Matrix, applying Scrum to the areas "Chaos" and "Simple" is a waste. Scrum is best used in the "Complex" area. Here, empirical process control thrives, applying transparency, inspection, and adaptation to iteratively, incrementally developing valuable product Increments, thus mitigating risk.

2. Strive for High Product Quality

From day one, keep technical debt small and work continuously on high product quality, reflected in the Scrum Team’s Definition of Done. Achieving business agility requires dedication to product quality and excellence at the technical level. (Learn more: Technical Debt and Scrum: Who Is Responsible?)

3. Create and Maintain an Actionable Product Backlog

Garbage in, garbage out: No matter how your Scrum Team is everything else, a sub-standard Product Backlog will diminish all other team achievements. Hence, it would be best to support the Product Owner and the Developers to maintain a permanently “actionable” Product Backlog. By “actionable,” I am referring to a refinement level of the Product Backlog that would allow a Scrum Team to run a meaningful Sprint Planning at a moment’s notice. (Learn more: 28 Product Backlog and Refinement Anti-Patterns.)

4. Embrace Self-Management and Take It to the Scrum Team

Restrain from solving problems that your teammates can solve themselves. I know it feels good to be helpful; however, it is not your job as a Scrum Master to become the team’s helping hand in all matters. Instead, make self-management our number one priority and ensure that everyone lives Scrum Values. Be a servant-leader at heart and, therefore, a good role model for the Scrum team.

In none of these four areas, a Scrum Master can advance the cause without the deliberate and voluntary support of other people. This is a great challenge many successful Scrum Masters love to address. Unfortunately, however, not all of us are so fortunate to work under these conditions. The frustrated Scrum Master symptom is real; not every Scrum Master who performs below expectations does so because of a lack of competence. Sometimes, former missionaries turn into mercenaries when they see no use to continue fighting inertia, politics, or conflicting agendas.

Possible Reasons Why Missionaries Become a Frustrated Scrum Master

The reasons why able and willing Scrum Masters abandon the spirit of the Scrum Guide are multi-faceted. Probably, the Scrum Master has been working his or her butt off for months, but neither the Scrum Team nor the organization is responding to the effort. There are many potential reasons for a failure at this level, to name a few:

• The lack of sponsoring from the C-level of the organization.
• A widespread belief that Agile is just the latest management fad, and thus ignorable.
• The company culture values neither transparency nor radical candor.
• The company has no failure culture; consequently, everyone plays safe, resulting in short-term orientation as not-failing is more important than innovation.
• The Scrum Team composition is wrong.
• Members of the Scrum Team object to self-management.
• There is no psychological safety to address the Scrum Team’s problems.
• Individual team members harbor personal agendas unaligned with the team’s objective.

These examples can lead an able and willing Scrum Master off the path, resulting in a frustrated Scrum Master either considering leaving for a more supportive environment or turning into a mercenary, trading time for a paycheck.

The Frustrated Scrum Master — Conclusion

There are numerous reasons why a Scrum Master may leave the path and become a frustrated Scrum Master or even a mercenary. However, before you jump to conclusions, try and understand the context of the development. Probably, it does not have anything to do with competence.

How is your organization failing to support its Scrum Masters, thus advancing the problem of the frustrated Scrum Master? Please share them with us in the comments.