Coaching and Mentoring Teams
Coaching vs. Mentoring
Coaching unlocks a person's or team's own thinking through questions, reflection, and accountability; mentoring transfers experience and advice. The Scrum Master leans on coaching for self-management and uses mentoring or teaching when the team lacks Scrum knowledge. Questions frequently test whether an answer builds capability (coaching) or creates dependency (giving answers).
Team Development Stages
Teams move through forming, storming, norming, and performing, with conflict during storming being normal and often productive. A trap suggests the Scrum Master should suppress conflict; instead, facilitate constructive disagreement. Another trap assumes a new team should skip storming - they cannot.
Coaching Models and Feedback
Simple models help: goal–reality–options–will for structuring a conversation, and observation–impact–request for feedback. Coaching focuses on the team's goals, not the coach's agenda. When a team repeatedly misses the Sprint Goal, the coaching move is to help them inspect why - not to add pressure or take over planning.
Worked rule of thumb
If the scenario shows a team capable of solving a problem but unsure, coach with questions. If the team lacks knowledge entirely (e.g., never ran a retrospective), teach or mentor first, then coach. Match the intervention to the gap: skill gap → teaching; will or clarity gap → coaching.
Exam traps
- Coaching is not therapy or performance management by the Scrum Master.
- Advice-giving is sometimes right (knowledge gap) but is overused in answer options.
- Healthy conflict is a sign of progress, not failure.