Scrum Master Misunderstandings
Scrum Master Misunderstandings
As Agile and Scrum methods become more widely adopted, there's bound to be some confusion. In this post, we look at what a Scrum should, and shouldn't be.
Join the DZone community and get the full member experience.Join For Free
Currently, I'm preparing my presentation and workshop for Scrum Day London and Scrum Day Warsaw. The topic will be "The 8 Stances of a Scrum Master," based on the related white paper. During these sessions, I'll share my view on the 8 preferred stances of a Scrum Master. However, I also want to discuss the misunderstandings. In this blog post, I'll share the preferred and misunderstood stances. If you've experienced any other misunderstandings, feel free to share them. It's highly appreciated!
The 8 Preferred Stances of a Scrum Master
The Scrum Master acts as a...
- Servant Leader whose focus is on the needs of the team members and those they serve (the customer), with the goal of achieving results in line with the organization’s values, principles, and business objectives.
- Coach who coaches the individual with a focus on mindset and behavior, the team in continuous improvement, and the organization in truly collaborating with the Scrum Team.
- Facilitator by setting the stage and providing clear boundaries in which the team can collaborate.
- Teacher to ensure Scrum and other relevant methods are understood and enacted.
- Mentor that transfers Agile knowledge and experience to the team.
- Manager responsible for managing impediments, eliminating waste, managing the process, managing the team’s health, managing the boundaries of self-organisation, and managing the culture.
- Impediment Remover who solves issues blocking the team’s progress, taking into account the self-organizing capabilities of the Development Team.
- Change Agent that enables a culture in which Scrum Teams can flourish.
How the Scrum Master Role Is Misunderstood
The Scrum Master role is often misunderstood and considered as someone acting as a...
- Scribe. Taking notes during every Scrum event. Writing down the entire Sprint plan, daily plan, refinement discussions, and Retrospective commitments. I've actually experienced a customer that expected the "Scrum Master" to act as a scribe for 4 hours per week.
- Secretary. Planning all the Scrum events on everyone's agenda. Responsible for keeping the team's schedule with holidays and days off up-to-date.
- Scrum police officer. Rigorously following the rules of Scrum without any empathy for the team's current situation and context. If you're not acting according to the Scrum Guide you're doing it wrong. Period.
- Team boss. The so-called "servant-leader," but actually just the boss of the team. The boss who hires and fires. The boss who decides if someone deserves a salary increase.
- The tool administrator. If you need a change in JIRA, TFS, or any other tool, the Scrum Master is your friend. He (or she) knows every workflow by heart.
- The Scrum Board Owner. Hurray! The team uses a physical whiteboard for the Sprint Backlog and other team related information. Unfortunately, there's only one person using and updating it: the Scrum Master. The other team members update their progress in a digital tool.
- Chairman of the daily Scrum. Every morning the team provides a status update to the chairman of the daily Scrum. This offers the Scrum Master the necessary information to write the daily status report to his/her superiors.
- Hero. It's a bird. It's a plane. It's the Super Scrum Master! Solving all your impediments before they actually even were impediments. The hero is addicted to the adrenaline of solving "problems." It's not about the team, is about increasing his status as a hero.
- Coffee clerk. There's nothing wrong with getting coffee for your team members. That's even very collegial. But if you're main purpose during the day is providing the team with coffee than you're missing the point of being a Scrum Master.
In this blog post, I've described the preferred stances of a Scrum Master but also the most common misunderstandings. Both will be part of the presentation and workshop I'll be providing at Scrum Day London and Scrum Day Warsaw (and probably other seminars as well).
My questions to you are:
- What do you think of these misunderstandings? Do you recognize them?
- If you know a better description, what would that be?
- What are other misunderstandings that you've experienced?
As always your feedback is highly appreciated!
Published at DZone with permission of Barry Overeem , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.