The servant-leader
The most foundational stance, and the one most frequently performed rather than practised. A servant-leader shares power and puts the needs of the Scrum Team first. Not as a warm gesture. As a structural commitment about where authority actually lives.
The Scrum Guide is unambiguous on this point: “The Scrum Master is a true leader who serves the Scrum Team and the larger organization.” Importantly, the 2020 revision repositioned the Scrum Master from a “role” to an “accountability,” a shift that clarifies the SM’s organizational standing without granting traditional management authority.
The facilitator
The Scrum Master serves as a facilitator to both the Product Owner and the Developers, helping the Scrum Team understand their shared objectives and find a path toward them. A facilitator stays neutral: they do not take positions in discussions. I’ve always thought of it this way: the Scrum Master is the person of the questions, not the answers.
That means more than running Scrum Events with purpose and structure. It means attending to the larger dynamics: work atmosphere, communication patterns, the silences that reveal more than the arguments.
The coach
Sir John Whitmore’s definition still resonates: “Coaching is unlocking a person’s potential to maximize their own performance. It is helping people to learn rather than teaching them.” A coach doesn’t fill the gap with their own expertise. They create the conditions for someone else to find theirs.
Barry Overeem identifies three coaching perspectives: the individual (mindset and behavior), the team (continuous improvement), and the organization (genuinely collaborating with Scrum Teams rather than merely tolerating them). Each level requires different attention, different patience, and a different read on what is actually blocking development.
[AE: Amy Edmondson’s research on psychological safety belongs directly here. Her central finding is that teams perform best when members feel safe to voice uncertainty, admit mistakes, and challenge assumptions without fear of reprisal. Coaching questions land in silence when that safety is absent. Edmondson argues this dynamic operates at all three of Overeem’s levels: individual, team, and organizational. You cannot coach your way through a psychologically unsafe environment (“The Fearless Organization,” 2018).]
The manager
In a traditional sense, managing means control: over people, output, and information flow. That is not what a Scrum Master manages. In agile organizations, what Overeem calls “horizontal management,” the Scrum Master manages impediments, the process, team health, the boundaries of self-organization, and culture. No direct reports. No performance reviews.
This is harder than it sounds. Managing the boundary of self-organization requires constant judgment about when to intervene and when to wait. Managing culture requires naming patterns nobody else is naming. Managing team health means noticing what isn’t being said in a room.
Dave Snowden’s Cynefin framework is useful here. In complex domains, where Scrum teams operate by definition, the appropriate management response is to create conditions for emergence rather than prescribe outputs. The Scrum Master as horizontal manager is working the system conditions, not the deliverables. Authority that looks nothing like authority.
The mentor
Mentoring is the transfer of experience at the moment it becomes relevant. Not a curriculum. A conversation. The prerequisite is that the Scrum Master has accumulated something worth sharing: actual knowledge of Scrum theory, actual experience of what happens when it meets organizational reality.
This is distinct from teaching, which is systematic, and from coaching, which draws out rather than puts in. A mentor says: “I have been here before. Here is what I learned.” That requires earned credibility, not just a certificate on the wall.
The teacher
A teacher ensures Scrum is understood: by the Scrum Team, by the organization, by stakeholders who interact with the team. This is more demanding than it appears. The gap between understanding the framework intellectually and actually operating inside it is significant, and narrowing that gap is the Scrum Master’s job.
Overeem’s instruction to allow failure as a teaching mechanism is worth taking seriously: “Don’t try to teach the team everything upfront, give them the opportunity to fail and learn from their own mistakes. Remember: mistakes are the portals of discovery.” The urge to prevent failure in advance is understandable. It is also counterproductive.
The impediment remover
The Scrum Guide is precise on this: the Scrum Master “causes the removal of impediments to the Developers’ progress.” Causes. Not removes. The distinction matters. The Scrum Master’s job is not to fix everything that goes wrong. It is to address what genuinely exceeds the self-organizing capability of the Developers, and to create an environment where impediments can surface safely and freely.
Step in too early and you undermine the team’s capability to handle things themselves. Step in too late and a solvable problem becomes a Sprint-killing blocker. The judgment about when to move is as important as the ability to move well.
The change agent
Where the stances blur
The coach, mentor, and teacher stances are frequently confused because they all involve some form of knowledge transfer. What they transfer, and how, is where they diverge. A teacher explains: here is what a Sprint Retrospective is, here is its purpose. A mentor draws on experience: when I encountered a team that refused to inspect their way of working, here is what I tried. A coach asks the questions that help the team articulate what they already know but haven’t connected yet.
The confusion usually comes from reaching for the wrong stance at the wrong moment. Teaching when the team needs to discover something for themselves. Coaching when they need actual information. Mentoring when what they need is their own experience rather than someone else’s accumulated version of it.
Mastering the change agent stance is, I think, the eventual horizon of this work. The Scrum Master who can genuinely shift organizational conditions is doing something qualitatively different from the one who runs tight events and clears blockers within a team. Both matter. They are not equivalent.
Stay tuned for the follow-up: the eight misunderstood stances, and my take on the Scrum Master vices.
Burn, baby, burn. Thanks for the article and keep up the good work!