3.2 Developing Stances: Teacher, Mentor & Coach
Key Takeaways
The Teacher stance imparts foundational Scrum concepts, empirical mechanics, and the underlying rationale during onboarding or when core rules are misunderstood.
The Mentor stance guides through shared experience, contextual storytelling, and pragmatic advice built on historical successes and hard-won failures.
The Coach stance is non-directive, relying on active listening, mirroring, and powerful open-ended questions grounded in the belief that the team possesses its own answers.
The GROW framework (Goal, Reality, Options, Will) structures coaching conversations to build long-term problem-solving autonomy rather than dependency.
Advanced practitioners choose fluidly between teaching, mentoring, and coaching based on team maturity, urgency, and the presence of underlying knowledge gaps.
3.2 Developing Stances: Teacher, Mentor & Coach
A central tenet of the Professional Scrum Master II mindset is understanding human development. Teams and individuals do not achieve self-management through mandate; they evolve through structured capability building. To foster this maturation, the Scrum Master draws upon three distinct developmental stances: Teacher, Mentor, and Coach.
While novices frequently conflate these terms, each stance embodies a unique philosophical orientation, communication style, and pedagogical objective. Misapplying these stances can cripple a team: coaching someone who lacks basic knowledge causes paralysis and frustration, whereas teaching an experienced team that needs coaching fosters resentment and learned helplessness. Mastery lies in diagnosing the human context and fluidly selecting the appropriate developmental stance.
The Teacher Stance: Pedagogical Clarity and the Empirical "Why"
The Teacher stance involves the direct transfer of knowledge, principles, mental models, and operational mechanics. In this stance, the Scrum Master occupies the position of an expert instructor who helps learners understand what Scrum is, how its components interact, and the empirical logic behind its rules.
When to Teach
- Team Formation and Onboarding: When a team is newly formed, introducing new team members, or transitioning from traditional predictive workflows (Waterfall) to iterative, empirical development.
- Fundamental Misconceptions: When framework accountabilities or events are misunderstood—such as when the Daily Scrum is treated as a managerial status update, or the Definition of Done is conflated with acceptance criteria.
- Introducing New Practices: When exposing the team or organization to complementary agile practices, such as user story mapping, test-driven development, continuous integration, or WIP (work-in-progress) limits.
Effective Agile Pedagogy
Effective teaching in agile environments is not passive lecture; it is experiential and interactive. Drawing on modern instructional methodologies—such as Sharon Bowman's Training from the Back of the Room—the Scrum Master:
- Emphasizes the "Why" behind the rule: Explaining that a timebox is not an arbitrary constraint, but a mechanism to limit risk and force prioritization.
- Uses multimodal learning: Utilizing visual diagrams, collaborative simulation games (e.g., the Penny Game for batch size demonstration), and real-world case studies.
- Keeps instruction bounded: Teaching in micro-doses followed by immediate practical application, rather than overwhelming teams with exhaustive theoretical manuals.
The Teacher Trap: An overused Teacher stance produces the Professor anti-pattern. If a Scrum Master constantly lectures experienced professionals, they patronize the team, stifle organic exploration, and foster intellectual resistance.
The Mentor Stance: Guiding Through Experience and Storytelling
The Mentor stance bridges theoretical knowledge and practical reality. A mentor is an experienced practitioner who shares personal wisdom, real-world war stories, and pragmatic advice accumulated across years of navigating organizational complexity.
Characteristics of Effective Agile Mentoring
- Vulnerability and Authenticity: A great mentor does not present themselves as infallible. They openly share past failures, architectural miscalculations, and organizational blunders, explaining what they learned from those setbacks.
- Contextual Wisdom: Rather than offering dogmatic prescriptions, the mentor frames advice contextually: "In a similar payment processing environment with legacy monoliths, our team encountered severe regression defects when we delayed integration. We found that shifting automated regression tests into our Definition of Done dramatically stabilized our releases. Here is how that unfolded, though your architecture may have different constraints."
- Bi-directional Respect: Mentoring honors the agency of the mentee. The mentor provides insight, but the mentee retains full ownership over whether and how to apply the recommendation.
Mentorship is particularly valuable when individuals step into new accountabilities. A Scrum Master frequently mentors a novice Product Owner on stakeholder negotiation techniques, or mentors aspiring Scrum Masters across the organization's agile community of practice.
The Coach Stance: Non-Directive Inquiry and the GROW Framework
The Coach stance represents the highest evolution of agile facilitation. Grounded in the principles of professional coaching—as defined by the International Coaching Federation (ICF)—coaching is fundamentally non-directive. The coach operates from the conviction that the coachee (whether an individual, a team, or an executive) is naturally creative, resourceful, and capable of generating their own solutions.
In the Coach stance, the Scrum Master offers no advice, provides no answers, and shares no personal anecdotes. Instead, they act as an objective, empathetic thinking partner who helps the team explore their reality, challenge hidden assumptions, and design their own actionable experiments.
Core Competencies of Agile Coaching
- Active Listening: Listening beyond the literal words to discern emotional undertones, unvoiced anxieties, energy shifts, and recurring behavioral patterns.
- Mirroring: Reflecting the team's words and dynamics back to them without distortion: "I notice that when automated testing is mentioned, the room goes silent and eyes look down. What is happening in that silence?"
- Powerful Open-Ended Questions: Inquiries that disrupt established cognitive patterns and provoke creative reflection. Effective coaching questions begin with "What" or "How" and avoid the accusatory tone often embedded in "Why" (e.g., asking "What factors contributed to the build breaking?" rather than "Why didn't you test the code?").
The GROW Model in Practice
The GROW model, developed in the 1980s by Graham Alexander, Alan Fine, and Sir John Whitmore and popularized by Whitmore's Coaching for Performance, provides a structured empirical architecture for non-directive coaching conversations:
- Goal (G): Establish the coachee's desired outcome. "What does success look like for our team by the end of this quarter?" or "What specific outcome do you want from this conversation?"
- Current Reality (R): Anchor in empirical facts and current dynamics. "What data do we have about our current cycle time?" "What have you already tried, and what were the observable results?"
- Options & Obstacles (O): Explore diverse possibilities without immediate evaluation. "If there were zero technical constraints, what approach would you take?" "What other avenues haven't we explored yet?"
- Will / Way Forward (W): Crystallize concrete commitment and accountability. "Which of these options will you implement first?" "When will you begin?" "How will we inspect whether this experiment is working?"
Stance Selection Matrix: Situational Agility
Choosing the appropriate stance requires situational assessment. Applying the wrong stance at the wrong moment creates immediate organizational friction. The table below illustrates how to match the developmental stance to situational factors:
| Situation / Context | Dominant Need | Best Stance | Scrum Master Action | Danger / Failure Mode |
|---|---|---|---|---|
| Developers argue whether Product Backlog items must have story points to enter a Sprint. | Knowledge & Framework Clarity | Teacher | Teach that story points are a complementary estimation technique, not a Scrum rule. Clarify empirical readiness. | Coaching the team to "discover" framework rules leads to confusion and invalid Scrum. |
| A newly appointed Product Owner struggles to balance technical debt items against commercial feature requests. | Practical Wisdom & Applied Insight | Mentor | Share real-world case studies and patterns on how balancing technical debt sustains long-term delivery velocity. | Lecturing on theory without acknowledging political stakeholder realities. |
| The team consistently fails to complete work within the Sprint, but possesses all necessary technical and framework knowledge. | Ownership, Self-Reflection & Commitment | Coach | Use powerful open-ended questions and the GROW model to help the team identify root causes and formulate their own commitments. | Dictating solutions or giving advice, which relieves the team of accountability and breeds dependency. |
| An executive demands an immediate answer on why a team is adopting cross-functional pairing. | Strategic Education | Teacher | Present empirical research on defect reduction, knowledge redundancy, and cycle time improvements. | Asking open-ended coaching questions to a hostile executive who requires clear business facts. |
Announcing the Stance Shift
Because switching between developmental stances can confuse team members, an advanced Scrum Master frequently makes their stance explicit. By signaling transitions verbally—e.g., "Stepping out of my coaching stance for two minutes, let me share a mentoring story from a previous team..." or "Putting my teacher hat on to clarify the Scrum Guide rule on Sprint cancellations..."—the practitioner maintains psychological safety and role clarity.
A mature Scrum Team with high technical competence has missed their Sprint Goal for two consecutive Sprints due to internal conflicts over code refactoring standards. The team approaches the Scrum Master and asks, 'Tell us exactly which coding standard we should adopt so we can stop arguing.' Which stance should the Scrum Master adopt?
The Teacher stance: Deliver a detailed technical presentation outlining industry-standard Clean Code principles and then mandate their adoption across the team.
The Mentor stance: Share personal code examples from past successful projects and select the best standard on behalf of the team so the conflict ends quickly.
The Manager stance: Author a formal coding guidelines document and enforce compliance through mandatory pull request approvals.
The Coach stance: Decline to pick, and use open questions to help the team define its own shared quality criteria.
During Sprint Planning, a newly formed Scrum Team debates whether the Product Owner has the authority to assign individual backlog items to specific Developers. Several Developers believe this is standard practice. Which developmental stance should the Scrum Master take first?
The Teacher stance: teach the fundamental Scrum rule that the Developers are self-managing and decide among themselves who does what, when, and how, so no one assigns them tasks.
The Coach stance: Ask open-ended questions like, 'How do you feel when tasks are assigned to you by someone else?' and let the team reach its own conclusion.
The Mentor stance: Tell an inspiring story about an autonomous team from a previous organization that achieved high morale without task assignments.
The Facilitator stance: Conduct a silent dot-voting exercise to let the team democratically decide whether the Product Owner should assign tasks from now on.
A Scrum Master observes that while a Scrum Team conducts Retrospectives diligently, the resulting action items are vague, unfocused, and rarely implemented during the following Sprint. The team expresses frustration that 'nothing ever changes.' How can the Scrum Master utilize the GROW model to coach the team?
Define the Goal and Reality for the team during the Retrospective, and assign specific Will action items to individual Developers so accountability is clear.
Guide the team through a specific improvement Goal, its current Reality, actionable Options, and a firm Will step that puts a concrete improvement into the Sprint Backlog.
Postpone the GROW coaching session and replace the Retrospective with a lecture on the five Scrum Values.
Advise the Product Owner to deduct time from the Sprint capacity to personally complete the unaddressed improvement items.
Sections you finish are checked off in the contents.