Coaching a Scrum Team: asking, observing and handing over

A new Scrum Master has two instincts, and both are wrong. The first is to explain Scrum to the team until everyone understands it. The second is to fix every problem personally. Coaching sits between them. It is slower on the first day and much faster over a year, because the team learns to do what the Scrum Master used to do.

What the Guide asks

Among the ways the Guide says the Scrum Master serves the team, the first is coaching the team members in self-management and cross-functionality. The same list includes helping the team focus on high-value Increments that meet the Definition of Done, causing the removal of impediments, and ensuring events are positive and productive. For the organisation, the Guide adds coaching in its Scrum adoption.

Note what the Guide does not say. It does not say the Scrum Master tells the team how to estimate, or what to put in the Definition of Done. Those belong to the Developers. The coach's contribution is helping the team become the kind of group that can decide them well.

The SBOK® Guide describes the Scrum Master as moderating and facilitating team interactions as team coach and motivator. It also lists a leadership style it calls coaching, which is defined there in a more directive way, with leaders issuing instructions and then monitoring through listening and encouragement. The word is the same, the content differs. When this post says coaching, it means the Guide's sense: building capability so the team can decide for itself.

Teaching, facilitating, mentoring, coaching

The four are easy to mix up, and each is useful in its place.

Teaching transfers knowledge: "here is how the Sprint Backlog works". It is the right choice when a team has never seen the thing before.

Facilitating manages a conversation without steering the content: running a Retrospective so that everyone speaks. It is right when the group has what it needs and needs a structure.

Mentoring shares your experience: "when I faced this, I tried this". It is right when someone has asked for a viewpoint, and you give it as one option.

Coaching helps someone reach their own conclusion through questions, observation and feedback. It is right when the team has the skills and has not yet used them.

A good Scrum Master moves between all four and says which one they are doing. A common failure is to coach when someone wants a fact, which is irritating, or to teach when someone could work it out, which builds dependence.

A working pattern

Observe. Before saying anything, watch what actually happens. Who speaks at the Daily Scrum? Where does work wait? What happens when a Developer is stuck? Notes beat impressions.

Ask. Share what you noticed as an observation, without a verdict, and ask an open question. "I noticed that three items have been in review since Tuesday. What do you make of that?" Questions that begin with "what" and "how" tend to open things up more than "why", which can sound like blame.

Offer an experiment. Teams find it easier to try something for a short time than to adopt it forever. "Would you try for one Sprint a rule that no new work starts until reviews are cleared?" Experiments fit the framework: they are small acts of inspection and adaptation.

Hand over. Decide with the team who will do the next step and when it will be looked at again. The measure of progress is how soon you are no longer needed in that spot.

GOV.UK's guidance on agile principles supports the underlying habit: regularly ask the team what is blocking them or slowing work, agree fixes, and check at stand-ups and retrospectives whether the fixes worked.

A worked example: handing over the Retrospective

This is an illustrative case. A new Scrum Master joins a team that has been running Retrospectives for a year. Every one is led by the Scrum Master, who prepares a format, chooses the topics and writes the action list. Actions are usually forgotten.

Observation: the team contributes freely, but nobody leads, and nobody owns an action once the meeting ends.

Ask: "If I were away for a Retrospective, what would happen?" After a pause, one Developer says, "We would probably skip it." The Scrum Master asks what would need to be true for the team to run it without them.

Experiment: the team agrees that, over the next three Sprints, a different Developer will pick the format each time, and each action will have a named owner and a place on the Sprint Backlog. The Scrum Master attends and stays silent unless asked.

Hand over: in Sprint three the Retrospective runs without the Scrum Master, who joins at the end to hear the actions. By Sprint five most actions are finished by the following Retrospective. The Scrum Master has a freed hour a week for the problem of dependencies on another team.

Nothing complicated happened. The Scrum Master asked, waited, and let the team be slightly worse at first.

What to coach

The Guide's two named topics, self-management and cross-functionality, give you a starting list.

For self-management: how the team picks its work, how it handles disagreement, how it reaches decisions without a leader, and how it deals with an absent or struggling member. See self-managing teams.

For cross-functionality: where skills are missing, how knowledge spreads, and how dependencies on outsiders are reduced. See cross-functional teams.

Beyond those, common topics are the Definition of Done, honest forecasting, running events within the timebox and giving each other feedback.

Common mistakes

• Coaching without being asked. Where there is no invitation, say what you notice and ask whether it is useful.
• Pretending to ask. A leading question is an instruction in disguise.
• Coaching individuals in public. Raise personal matters privately.
• Staying forever. If the same coaching need appears for many Sprints, adjust the approach.
• Never saying what you think. A coach who withholds a clear view when it is needed is not helping. Offer your view as a view.

How to practise it

Choose one habit your team has relied on you for, and plan how you will hand it over in three steps. In the simulator you can play the Scrum Master and see which situations call for an answer and which for a question.