PSM I Facilitation and Coaching: How a Scrum Master Serves Without Directing

Facilitation and coaching are the two main ways a Scrum Master helps people without directing them. Facilitating means guiding a group's process so that the group reaches its own outcome. Coaching means helping a person or a team find their own way forward, mostly by asking questions that prompt reflection. In both, the decision stays with the people who are accountable for it.

The Scrum Guide describes Scrum Masters as true leaders who serve the Scrum Team and the larger organization. Because a self-managing team decides internally who does what, when and how, a Scrum Master does not direct the Developers or assign their work. Influence comes from coaching, teaching, facilitating and making problems transparent instead. The Guide's lists of what the Scrum Master does for the Scrum Team, the Product Owner and the organization (covered in the lesson on Scrum Team accountabilities) are mostly carried out through these two skills.

A useful test for any Scrum Master action: after I do this, will the team be more able, or less able, to handle the same situation without me? Facilitation and coaching aim for "more able". Deciding, assigning and rescuing usually leave the team "less able", even when they solve today's problem faster.

A neutral facilitator owns the process and leaves the content to the group. The facilitator helps the group agree its purpose, keeps the discussion on that purpose and within its time, balances who gets heard, and helps the group converge. The facilitator does not choose the answer, steer towards a favourite option or rewrite what the group produced.

Neutrality matters most when the facilitator has a strong opinion. Opening a session with "here is my preferred option" anchors the group and turns facilitation into persuasion; taking the decision "because time is running out" moves the outcome to the facilitator. A Scrum Master who has relevant information can share it, preferably as a question or an observation, but the group still decides.

Neutrality also means respecting who owns which decision in Scrum. When Developers disagree about a technical design, the facilitator helps the Developers decide; the Product Owner does not pick technical designs, and seniority settles nothing because a Scrum Team has no internal hierarchy. When a refinement session discusses sizing, the Developers who will do the work size it; when it discusses order, the Product Owner decides it.

Facilitation techniques change the structure of a conversation so that more people contribute and the group reaches a decision in the time it has. The common ones, and the problem each solves:

None of these techniques is prescribed by Scrum; they are general facilitation practice. To judge a technique, ask two questions: does it widen participation, and does it leave the decision with the group? A good technique fixes the specific problem in front of the group, such as dominance, anchoring, no decision rule or too little time. A fix that narrows who is heard, or quietly passes the decision to one person, treats the symptom and makes the underlying problem worse.

The Scrum Guide does not name a required facilitator for any Scrum event. What it does say is that the Scrum Master serves the Scrum Team by ensuring that all Scrum events take place and are positive, productive and kept within the timebox. Ensuring is not the same as running: a Scrum Master can meet this accountability by teaching the purpose of each event, helping the team prepare, coaching others to facilitate, or facilitating when asked.

Consequences that follow from this rule:

• An event does not need the Scrum Master in the room to happen. Every event is an opportunity to inspect and adapt, and it belongs to its participants. When the Scrum Master is away, the event goes ahead at its normal point in the Sprint, and anyone in the Scrum Team can facilitate it.
• Events that get cancelled or skipped (for example an event dropped whenever people feel busy) fall directly under this accountability, more than under impediment removal or coaching in general.
• Events that overrun are fixed by helping them meet their purpose in time, by finding out why time runs short and addressing that cause. Common causes are a group that does not know the event's purpose, or work that arrives unprepared (for example Product Backlog items that were never refined). Workarounds that bend the timebox, or that have someone outside the Developers prepare decisions for them, leave the cause in place.

The Scrum Master takes part in Scrum Team events as a member of the Scrum Team, not as a guest, an outside observer or a chairperson with special rights.

The Daily Scrum belongs to the Developers: it is their short event for inspecting progress toward the Sprint Goal and adapting their plan for the coming day. A Scrum Master supports it in a way that makes the Developers need the Scrum Master less over time.

The classic anti-pattern is the status meeting, in which each person reports to the Scrum Master (or anyone else) in turn. Keeping within the 15-minute timebox does not rescue it: the event has become a report instead of the Developers' own planning. The fix is to coach the Developers to run the event themselves, structured around progress toward the Sprint Goal. Any change that only moves the audience, or removes the conversation altogether, leaves the event as reporting.

Principles that cover the other common situations:

• Helping is not owning. Nothing in Scrum forbids a Scrum Master facilitating the Daily Scrum when the Developers ask. Help in a way that builds their ability to steer the event themselves, and step back as they do. Monitoring individuals' tasks, or becoming the permanent host, moves ownership away from them.
• Keep the event to its purpose. When the Daily Scrum turns into long problem-solving, coach the Developers to keep it to inspecting progress and adapting the plan within the timebox. The Scrum Guide notes that Developers often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint's work, so a separate conversation after the event is a natural place for technical deep-dives. Impediments raised still need action now, not weeks later.
• Working on Sprint Backlog items makes you a Developer at the Daily Scrum. The Guide says that if the Product Owner or Scrum Master is actively working on items in the Sprint Backlog, they take part as Developers. That makes them one of the people who plan together; it does not give them the right to direct the others' day.

The Sprint Review is a working session in which the Scrum Team and stakeholders inspect the outcome of the Sprint and collaborate on what to do next; the Scrum Guide says it should not be limited to a presentation. What good facilitation looks like:

• Design for conversation. Silent stakeholders usually mean the format suppresses feedback, not that there is none. Let attendees use the product, ask open questions and discuss what changed in the market or the business. Any format that removes the live inspection and collaboration, or turns the event into an approval step, defeats its purpose.
• Balance the voices. Draw out quieter attendees so the team hears the full range of feedback; seniority does not make one voice count for more.
• Route requests by accountability. Raising new needs at the Review is legitimate, because it is about what to do next. The Product Owner orders the Product Backlog, so requests go to the Product Owner. The Developers decide what they can take on for a Sprint at Sprint Planning, together with the Product Owner. Neither decision is made for them at the Review, by a stakeholder or by a show of hands.

The Sprint Retrospective is where the Scrum Team plans ways to increase quality and effectiveness and identifies its own most helpful changes. It inspects individuals, interactions, processes, tools and the Definition of Done, so the Scrum Master's own work is inspected too: the Scrum Master takes part as a team member, not as an outside observer or the person entitled to lead. Facilitating it well means:

• The team chooses the improvements. The facilitator structures the discussion and the convergence; the choice of what to change belongs to the team. A useful Retrospective ends with concrete improvements the team will act on.
• Hard topics stay on the agenda. Steering around a difficult subject to keep the mood positive hides exactly the kind of problem the event exists to inspect.
• The timebox holds. Timeboxes are maximums. When time is nearly up, help the team converge on its most helpful change and close the event, so the Retrospective concludes the Sprint as the Guide describes.

A Scrum Master switches between several stances, and the right one depends on what the person or group is missing. The four that matter most here:

The decision rule: missing knowledge, teach first; knowledge present but stuck, coach. Coaching questions cannot draw out something a person has never learned, so open-ended questions about a rule they have not met yet tend to produce guesses, not insight. The reverse mistake is just as common: repeating the rules to someone who already knows them does not reach the real cause. When a person knows Scrum well but keeps repeating a pattern that hurts the team, questions that help them notice the pattern and its effects are more likely to change it.

Whatever the stance, the aim is the person's own capability. Doing the work for someone, or quietly arranging for others to work around them, removes the symptom while the cause remains.

Stances combine in practice: teach the purpose, then coach the team as it applies it; facilitate the session, then coach individuals afterwards.

The Scrum Guide says the Scrum Master serves the team by coaching its members in self-management and cross-functionality. Self-managing teams decide internally who does what, when and how, so coaching self-management means handing those decisions back every time they drift towards the Scrum Master:

• Decisions about who does what stay inside the Developers. When asked to allocate work, coach the Developers to agree it among themselves. Any allocation from outside the team, however reasonable it sounds, teaches them to wait for someone else.
• Questions before answers. When Developers wait to be told what to do, ask questions that help them work out their next step, so the ability to decide grows inside the team.
• Transparency, not direction. When you see a risk in the team's plan, make it visible, for example with a question that surfaces an untested assumption, and leave the plan with the Developers who own it. Saying nothing withholds transparency; overruling the plan, directly or through someone else, takes the decision away.
• Let small experiments run. When you disagree with a low-risk, reversible choice, raise the concern, then let the team try it and inspect the result. That is empiricism at work; the Scrum Master is not an approver of technical choices.

The same principle applies to change in general. Without positional authority, a Scrum Master leads by making problems visible and coaching people to decide: bringing data on the cost of a recurring problem to the team, showing trends at the Retrospective, asking questions that help people weigh short-term speed against long-term cost. Changes imposed by command, whether through borrowed authority, a solo rewrite of a team agreement or the Scrum Master acting as a checkpoint, may produce compliance, but they damage the trust and ownership self-management depends on. A team-level process problem is a matter for the team to inspect, not a matter of individual blame.

A Scrum Master facilitates conflicts the team can resolve itself, and takes causes beyond the team's control to the people in the organization who can act on them. Facilitate first, escalate what facilitation cannot reach.

Two checks help place a conflict in the right row: who owns the decision at stake? and can the people in the room actually change the cause? Each accountability has limits too. The Product Owner is accountable for value and the Product Backlog, not for organizational matters such as employment terms, so those go to the people who own them.

The Scrum Master serves the Product Owner by helping the Product Owner get better at the accountability, never by taking it over. The Scrum Guide's services to the Product Owner include helping find techniques for effective Product Goal definition and Product Backlog management, helping the Scrum Team understand the need for clear and concise Product Backlog items, helping establish empirical product planning for a complex environment, and facilitating stakeholder collaboration as requested or needed.

In practice that means building capability: sharing techniques and helping the Product Owner practise them, helping the whole team see why clear items matter, and facilitating conversations between the Product Owner, stakeholders and Developers. The Product Owner may delegate some of the work, but the Guide is clear that the Product Owner remains accountable. So the Scrum Master does not become the author of the Product Goal, the owner of the Product Backlog's order, or the person who communicates the Product Owner's decisions to stakeholders.

The Scrum Master also serves the organization: leading, training and coaching its Scrum adoption, planning and advising Scrum implementations, helping employees and stakeholders understand and enact an empirical approach for complex work, and removing barriers between stakeholders and Scrum Teams. That includes teaching other departments how to work with Scrum Teams, and coaching managers on how self-management grows and how they can support it. The test is the same as inside the team: does the change leave people more able to work empirically and collaborate directly? Approval gates on the team's own decisions, heavy fixed procedures, and intermediaries between stakeholders and the team all work against that, whoever holds the role.