While I was writing an article about the stances of a Scrum Master, I was at first a bit confused about the differences between the roles of coach, mentor and teacher. Not confused in a damaging way. More the kind of confusion you get when you realise you’ve been treating three distinct things as interchangeable. This article zooms in on where the lines are.
Coaching: the answer is already in the room
Coaching is a one-on-one relationship between a coach and a coachee. The coach’s job is not to provide the answer. It’s to help the coachee find their own. That means helping them identify their goals, surfacing the obstacles they haven’t yet named, and building the self-awareness they need to make progress.
In ‘Coaching Agile Teams’ (2010), Lyssa Adkins defines agile coaching as requiring the practitioner to shift fluently between coaching, mentoring, teaching, and facilitating based on situational need. She is explicit that defaulting to mentoring or teaching when coaching is needed denies the coachee the chance to develop their own capability.
The defining characteristic of coaching is that the intelligence stays with the coachee. The coach does not fix the problem. The coach creates the conditions in which the person can fix it themselves. When a Scrum Master acts as a coach, the goal is not to produce a team that depends on the Scrum Master’s answers. It’s to build the team’s capacity to answer its own questions.
A coach who jumps to answers (even correct ones) is training the coachee to wait for the next answer. That’s a different outcome than the Scrum Master’s accountabilities call for.
That takes discipline. It requires sitting with someone’s discomfort without rushing to dissolve it.
Mentoring: drawing on the road already travelled
Mentoring is different. A mentor has been through something similar (the same role, the same kind of organisation, the same type of challenge) and they draw on that experience deliberately. They share wisdom. They offer the insight that comes from having made the mistakes already. They act as a role model and help the mentee develop their own leadership style.
According to Tuckman, mentoring is most valuable in the early stages of a team member’s development, particularly during Forming and Storming when experience gaps are widest. As capability grows and teams move toward Norming and Performing, coaching becomes more appropriate: the goal shifts from “let me show you what I know” to “what do you already know that you haven’t used yet?”
The key distinction is that the mentor’s experience is the asset. Where the coach stays out of the content, the mentor brings their content deliberately. They say: when I was in a similar situation, here is what I found. That’s not a failure to coach. It’s a different kind of help, and sometimes it’s exactly what’s needed.
This is often the stance that newer Scrum Masters most want from senior practitioners: not probing questions, but a map. Something to orient by. That’s legitimate. The mistake is when the mentor gives their map but the mentee is navigating entirely different terrain.
Teaching: transmitting what someone doesn’t yet have
Teaching is more formal still. A teacher imparts knowledge, skills, and understanding to a student through structured methods: lectures, discussions, exercises, workshops. The premise is that the student doesn’t yet have something the teacher has, and the teacher’s job is to transfer it.
According to the Scrum Guide, the Scrum Master accountabilities explicitly include “teaching and coaching the organisation to understand and enact empiricism.” The Guide uses both terms but leaves their distinction to practitioners, which is precisely the gap this article addresses. For reference: the 2020 update removed the Development Team as a named role (replaced by Developers), reframed the three prescribed Daily Scrum questions as optional examples, and shifted the Scrum Master framing from servant leadership toward supporting self-management and accountability.
Teaching has a clear directionality: knowledge flows from teacher to student. That’s appropriate when the gap is one of knowledge rather than confidence, autonomy, or awareness. When a Scrum Master trains a team on a new technique, explains the purpose of a Sprint Review to stakeholders who’ve never encountered Scrum before, or walks a new developer through what the Definition of Done actually means in this context, that’s teaching, and it’s the right call. The goal is explicit: to close a knowledge gap that currently blocks the work.
The limit of teaching is that transmitting knowledge doesn’t guarantee its application. A team can understand the theory of self-management perfectly and still default to waiting for instructions every morning. Teaching creates the conditions for change. It doesn’t guarantee it.
The Scrum Master needs all three, and needs to know which one they’re using
A Scrum Master who only coaches will frustrate the team member who genuinely needs direction. A Scrum Master who only mentors will produce a team shaped in the Scrum Master’s image rather than the team’s own. A Scrum Master who only teaches will build knowledge without building capacity.
The skill is reading the situation and switching. Is this person stuck because they don’t have the knowledge? Teach. Are they stuck because they lack experience and frame of reference? Mentor. Are they stuck because they haven’t yet trusted their own judgment? Coach.
This is not as obvious in practice as it sounds. Often the person in front of you wants to be told the answer, and giving them the answer feels like helping. Sometimes it is. Sometimes it’s the wrong move entirely: it confirms that the Scrum Master is the one who knows, and the team member is the one who doesn’t, and that relationship becomes a ceiling rather than a floor.
Which stance you choose in any given moment is a diagnostic decision. And like most diagnostic decisions, you will occasionally get it wrong. The interesting question is whether you notice when you do.