5 Pointless Versions of Scrum Masters
Misunderstanding the Scrum Master's accountability sets an undesired fate.
Misunderstanding the Scrum Master's accountability sets an undesired fate.
Originally published in GoRetro
Companies tend to resist the need for dedicated Scrum Masters. It’s hard for leaders to understand what this accountability brings to the team, and it’s easy to imagine a team without it. That’s why many Scrum teams work without a Scrum Master or with a shared one. However, I wonder if leaders have a precise understanding of the role.
Experiences talk louder than anything. For each bad experience, ten good ones are needed to shift the mindset. Please, reflect for a minute on the kind of Scrum Masters you worked with:
How did they help teams grow?
How did they unlock teams whenever they trapped themselves?
How did they help business people improve collaboration with the team?
How did they help the organization live up to the Scrum values?
When I reflect upon these questions, I struggle to come up with clear examples. Although I worked with many great Scrum Masters, I observed many misconceptions that resulted in bad experiences.
During this post, I will share with you five pointless versions of Scrum Masters. Hopefully, you can either avoid them or help people escape from this pitfall.
#1 — Secretary
One of the most common misinterpretations of Scrum Masters is limiting the activities to a kind of secretary. When that happens, the Scrum Master focuses on the following:
Schedule Scrum Events and meetings for team members
Ensure everyone has everything they need to work
Remind people of their commitments
Take notes during sessions, and share them with the team
Act passively and wait until the team asks for something
The secretary version is diminishing and confuses the value a Scrum Master brings to the team. Developers and Product Owners abuse the goodwill of the Secretary Master by frequently asking her to take care of activities they could and should have done on their own.
A Scrum Master is not the team’s secretary.
#2 — Therapist
Another common confusion is behaving as a therapist. The intentions might be good, but offering therapy without proper preparation can be harmful instead of helpful. At best, it will be useless.
The Scrum Master is responsible for coaching the team to become self-managing. And I believe that is where the confusion starts. One thing is coaching, and an entirely different one is providing therapy. Here are the examples you can observe when Scrum Masters fall into this trap:
Schedule frequent one-on-one with every team member to check how they are doing.
Focus on each individual instead of understanding how they function as a team.
Offer advice on a personal level instead of uncovering conflicts and encouraging the team member to solve them.
When Scrum Masters get too busy being a therapist, they have too little time to help the organization benefit from Scrum as a whole.
#3 — Delivery Manager
The background of the Scrum Master has a massive influence on how the person lives up to their responsibilities. If previously the Scrum Master was a Project Manager, then delivering on time, budget, and scope would define success. Yet, the Scrum Master doesn’t have responsibilities over that any longer. A change of mindset is needed to succeed.
You can observe the following signs when the Scrum Master is sliding into a kind of Delivery Manager:
Burndown obsession: Every single day, the Scrum Master wants to see confirmation the team will meet the forecast. If there’s no confirmation, she forces the team to take action.
Create reports for the management: To prove progress, the Scrum Master creates several reports to increase management’s confidence. The attention goes to numbers instead of helping the team grow.
Commitment to releases: The Scrum Master bypasses the Product Owner and takes release responsibilities by agreeing with stakeholders and making a commitment on behalf of the team.
Be careful! The Scrum Master isn’t a delivery manager. This behavior will damage the team’s relationship and reduce the odds of prospering with Scrum.
#4 — Team Representative
Scrum has no hierarchy; everyone in the team is on the same level. However, the accountabilities are clearly defined, Developer, Scrum Master, and Product Owner. When team members mess up with that, confusion is unavoidable.
A typical situation happens when the Scrum Master comes from software engineering. Given the previous hands-on experience, the Scrum Master tries to represent the team many times without asking or informing them. This will create trouble, and the result is anything but good. You can identify this wrong version of a Scrum Master with the following cues:
Attend meetings representing the Scrum Team even when they don’t ask.
Bridge communication between stakeholders and the team, including the Product Owner.
Get highly involved with stakeholders at the content level while forgetting to coach them on how to use Scrum in their favor.
Often create new backlog items based on exchanges with stakeholders. This behavior infuriates the Product Owner.
Constant conflict of responsibilities with Product Owners.
The Scrum Master is supposed to help the team learn how to create value sooner and not to represent them in stakeholders exchanges.
#5 — Gatekeeper
Don’t disturb my developers! They’re busy!
Protecting developers from interruptions is essential to create value incrementally, but there’s a balance. When Scrum Masters overprotect team members, they will get in the way of creating value and slow the team down. The following attitudes can identify the Gatekeeper misconception:
Do not allow any stakeholder to approach team members directly.
Do not allow any team member to exchange with stakeholders.
Controls the communication to avoid distractions.
Ask stakeholders to include the Scrum Master in all e-mails to team members to ensure the communication is related to the Sprint.
Follow processes strictly and is unwilling to adapt to anything out of it.
The gatekeeper is despised by business stakeholders and limits the team’s growth. Great Scrum Masters coach team members on how to avoid distractions but do not block them from exchanging with anyone.
The Real Scrum Master
If a Scrum Master isn’t a secretary, therapist, delivery manager, team representative, or gatekeeper, what is it then?
For me, Scrum Masters are Scrum catalysts. They help teams and organizations master Scrum and benefit from it. I’ve observed the following traits in successful Scrum Masters:
Take the team on a journey by meeting them one step ahead and guiding them step after step on how to master Scrum.
Listen 80% of the time and only speak when needed.
Prepare the team to shine instead of trying to shine in front of influential stakeholders.
Coach business stakeholders to see the advantages of Scrum and be open to trying new ways of working.
Help a group of people grow into a high-performing team.
Final Thoughts
The pointless versions of Scrum Masters come to exist due to a lack of understanding of the role and lack of empowerment. However, that shouldn’t be used as an excuse to accept the status quo as the ultimate result.
To move from a pointless version to a real Scrum Master, the person wearing this hat should:
Step back from daily activities
Reflect on how the responsibilities are lived
Identify anti-patterns
Take small steps to improve gradually
Rinse and repeat as often as needed
Did you like this post? What about becoming a Medium member to benefit from unlimited reading? By doing that, you also support writers like me and thousands of others 😊