Companies tend to resist taking on 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 share one. However, I wonder if leaders have an accurate understanding of the role.
Experiences talk louder than anything. For every bad experience, ten good ones are needed to shift the mindset. Please, reflect for a minute on the kind of Scrum Masters you’ve 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’ve worked with many great Scrum Masters, I’ve observed many misconceptions that resulted in bad experiences.
In this post I will share with you five pointless versions of Scrum Masters. Hopefully, you can either avoid them or help people escape these pitfalls.
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’ role takes away from the value and significance a Scrum Master brings to the team. Developers and Product Owners abuse the goodwill of the Secretary Master by frequently asking him or her to take care of activities they could and should have done on their own.
A Scrum Master is not the team’s secretary.
Another common confusion is behaving as a therapist. The intentions might be good, but offering therapy without proper training 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. Coaching is one thing; providing therapy is entirely different. Here are the examples you can observe when Scrum Masters fall into this trap:
- Schedule frequent one-on-ones 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. But these are no longer the Scrum Master’s responsibilities; 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 that the team will meet the forecast. If there’s no confirmation, he or 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. 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 a software engineering background. 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 by the following cues:
- Attend meetings representing the Scrum Team even when they aren’t asked to do so
- 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.
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 that communication is related to the Sprint
- Follow processes strictly and be unwilling to adapt to anything out of it
The Gatekeeper is despised by business stakeholders and hinders 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 by 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
The pointless versions of Scrum Masters 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