List of Anti-Patterns of a Scrum Master

Product Owner maximizes value, and Developers deliver it, so what does the Scrum Master do besides facilitating and setting up events? It is the most common question I happen to hear in my classes and many other forums. This thought process typically leads to many anti-patterns for the Scrum Master role. Often, many people who tend to pick up this role do not understand the responsibilities (I will talk about it in another post) of the role and only look at the superficial aspects of the role and then get caught in the myriad of anti-patterns. I was one of them at the start of my career as a Scrum Master. 

To me, Scrum Master is probably the underdog in the Scrum Team. As in one of his videos, Jeff mentions, it is Scrum that makes work happen, it is the team that does the work, but you still need the Scrum Master. In this post, I explore a few of the common anti-patterns which I have observed with this role. Guilty as charged, I had a couple of them.

Anti-pattern: The Bridge Scrum Master

The Scrum Master here typically acts as a bridge between the developers and other parties involved. It could be the Product Owner, stakeholders, or management. The Scrum Master becomes the messenger, relaying the information to and from the team. Any clarification that the Developers have is relayed via the Scrum Master, or if the PO/Stakeholders have any concerns, the Scrum Master is the person answerable.

Typical Pitfalls:

1. Scrum Master becomes the bottle-neck.
2. No empowerment to teams.
3. Teams do not tend to self-manage but are Scrum Master driven.
4. Collaboration is impacted.
5. Delays in value delivery.

Anti-pattern: The Tech Lead Scrum Master

The Scrum Master is a technical expert with vast experience in the domain and technology. As a result, the Scrum Master provides technical inputs to solving problems. 

They make decisions for teams on the technical front, which impacts/influences the estimations of developers.

Typical Pitfalls:

1. Lack of trust and transparency.
2. Developers have no/little say on estimations.
3. Developers typically wait for Scrum Master to provide technical solutions.
4. Developers do not own the solution and may have little commitment.
5. Impacts the self-management of the team

Anti-pattern: The Release Manager Scrum Master

The Scrum Master is less of a Scrum Master and more of a release coordinator. He is focused only on release management. Getting in escalation calls, reviewed CRQ documents, working with external parties for smooth release, connecting with stakeholders to get “Lead time exceptions” approved, and so forth.

In a nutshell, the Scrum Master has very little time to focus on making the team effective.

Typical Pitfalls:

1. Disengaged teams.
2. No or little focus on improvements.
3. Teams might not even have a clear picture of how to work with Scrum.
4. Teams may struggle with product development in an empirical environment.

Anti-pattern: The Jira Admin Scrum Master

The only work that this Scrum Master does is to maintain the Jira board for the team.

From creating Jira tickets to updating them daily during the Daily Scrum to moving them to “DONE” post PO review, every step is handled by the Scrum Master. If you need any report from Jira, this is the person to reach out for it. From Burndowns to customized filters, the expert can get you all.

Typical Pitfalls:

1. Scrum Master becomes the scrum secretary.
2. Single point of contact about the health of Product or Sprint Backlog.
3. PO and Developers rely highly on the Scrum Master to do simple tasks, such as adding a Story Point to a user story.
4. Transparency is lost.
5. If Scrum Master is unavailable to update the tool, the information becomes stale, further impacting the transparency.

Anti-pattern: The Product Owner - Scrum Master

The Scrum Master is now the Product Owner as well. Thus, at one end of the spectrum, the same person is accountable for making the successful product. In contrast, at the other end, the same person is responsible for creating a “safe” environment to foster creativity. At one end, the focus is on business feature delivery, while on the other end, the focus is on creating a balance so that the team doesn’t burn out.

Typical Pitfalls:

1. Conflict of interest.
2. Lack of trust.
3. Self-management gets impacted as PO opinions take over every discussion.
4. Developers are less confident while sharing any product-related concerns, not sure how the person would respond (as SM or PO).

Conclusion:

Scrum does not prescribe whether one person should have multiple accountabilities or not. Scrum only expresses that within the Scrum Team, there are three accountabilities - the Product Owner, the Developers, and the Scrum Master. In my personal experience, I have observed that the availability of people with a complete, dedicated focus towards specific accountabilities creates a huge difference. Thus, if we are expecting the Scrum Master to improve the team's effectiveness but then the Scrum Master is tied up with all the other aspects, we will not get any impactful results.