LEARN. PRACTICE. GROW.1. Identify the help being requested
A fictional team is preparing deployment automation for financial applications. Two people understand technical options but cannot compare risks in a productive conversation. Another person does not understand the Definition of Done. A third wants to improve how she asks for help. These needs justify different interventions. The first may benefit from facilitation, the second from teaching, and the third from a coaching conversation. Start by clarifying the desired outcome and existing knowledge. Choosing an intervention depends on the problem, relationship, and required capabilities, as well as the Scrum Master’s role. These helping approaches complement Scrum accountabilities without creating mandatory additional roles.
2. Make a change of approach explicit
When facilitating, help people structure the conversation and develop a decision. If you hold a strong technical opinion, acknowledge that interest and avoid presenting it as the group’s inevitable conclusion. In coaching, open questions can help someone observe their experience and choose a next step. If sharing experience or advice would help, make the change explicit and check whether the person wants to hear it. Teaching Scrum requires presenting its concepts accurately; neutrality in the facilitation process does not require treating an incorrect rule as equally valid. Clarity about the intervention helps participants understand who is exploring, advising, or deciding.
3. Create space for different contributions
In a remote meeting held in English, speed of response may be confused with knowledge or agreement. Three people write important observations in chat while two dominate spoken discussion. One possible experiment starts with silent writing, groups observations, and then discusses differences. This is a facilitation option, not a mandatory Scrum rule. Explain the purpose, allow enough time to understand the question, and let participants clarify their own contributions. Do not assume silence means agreement. Before concluding, check for objections or data that would change the decision. The intended outcome is shared understanding and useful participation, not an artificially equal allocation of speaking seconds.
4. Use facts to explore disagreements
After a deployment failure, operations and development blame each other. A useful retrospective starts by separating observations from interpretations. Reconstruct the sequence using timestamps, known decisions, and information gaps. A 14:02 log entry shows an event; it does not alone establish the root cause. Invite people to explain what information they had when deciding. This helps identify conditions that could recur, such as an alert without a clear recipient or a check performed too late. Respecting people does not prevent discussing choices and responsibilities. It enables evidence-based discussion without turning the meeting into a vote on blame or an exercise in departmental defense.
5. Act on barriers outside the team
An environment request has waited three days because a rule requires approval from someone outside the team. Developers have assessed alternatives and lack authority to change the rule. The Scrum Master can connect the observed impact with someone able to decide, clarify options, and follow up. They need not personally perform every technical task to help remove the impediment. Nor should self-management be interpreted as permission to bypass controls. Keep the decision owner, next action, and follow-up time visible. Meanwhile, Developers adapt their plan. After resolving the case, inspect whether the same mechanism creates recurring delays that warrant an organizational improvement.
6. Practice an intervention and inspect its effect
Choose a fictional situation: someone monopolizes discussion, an external dependency exists, or the team misunderstands a Scrum rule. Write the desired outcome, chosen intervention, and an observable improvement signal. For participation, check whether relevant perspectives previously absent have emerged. For a dependency, track waiting time and the ability to decide. For teaching, ask for application of the concept to a new example. One well-rated meeting does not prove sustained change. Record learning and decide whether to retain or adapt the experiment. The lesson’s summary is to choose appropriate help, make the approach understandable, and enable the team to act with knowledge.
Fictional example: environment request E17 has been blocked for three days. Developers adapt the plan; the Scrum Master facilitates a conversation with the rule owner using impact, options, and a concrete decision.
Common pitfalls
Hiding advice inside questions, treating silence as agreement, confusing respect with avoiding problems, and making the Scrum Master the sole intermediary for every decision.
Related topics: Self-management with clear accountabilities · Review, retrospective, and usable learning
Match the intervention to the need: understanding, learning, deciding, or removing a barrier. Make the approach explicit and inspect whether it improved the team’s ability to act.
Reference: Comparing Facilitation, Coaching, Mentoring and Teaching · PSM I; Scrum Guide November 2020; no public numbered exam revision