When to Coach and when to tell what you Observed
When coaching questions stop helping and a direct observation moves things forward.
Q: “Hi Vibhor, I’ve been trying to improve my coaching skills as a Scrum Master, so I often use open-ended coaching questions instead of giving advice. But sometimes I feel the team already knows the issue and another question just delays the conversation. When is it more helpful to tell my observation rather than coach?”
Thank you for the question.
Many Scrum Masters learn that great coaches ask powerful questions. That’s true, but it’s only half the story. A Scrum Master developing coaching skills often learns to replace advice with open-ended questions:
“What are you noticing?”
“What options do you have?”
“How does this affect the Sprint Goal?”
“What would you like to do differently?”
This is generally a positive change.
Questions can create reflection and learning. They help team members think for themselves rather than becoming dependent on the Scrum Master for answers.
However, questioning is NOT ALWAYS the most helpful intervention.
Sometimes the team has already discussed the issue. Sometimes the behaviour is unfolding visibly in the room. Sometimes another question merely invites people to talk around something they are reluctant to face. In such moments, a clear and respectful observation will likely create more awareness than another round of coaching questions.
Great Scrum Masters know how to balance “questions” with observations, and that’s what we will discuss in this post.
Let’s get started.
Got an urgent question?
Get a quick answer by joining the subscriber chat below.
The short answer
Questions create discovery
Observations create awareness
Ask a question when the team is missing awareness they can generate themselves. Make an observation when you hold information they don’t, or when they already have the awareness and are choosing not to act on it. A question closes an awareness gap. It cannot close a willingness gap, and asking a fourth question about something the team named ten minutes ago will feel to them like a quiz they’re failing.
Balancing coaching questions with direct observations
Is real coaching only questions?
No. It isn't.
The ICF competency on evoking awareness clearly includes sharing observations and insights. “Telling” what you observe is ALSO coaching. It sits inside the stance, not outside it.
The rule that “a Scrum Master never tells” grew as a correction to Scrum Masters who only told. But like most corrections, it overshot.
Let’s say in your Daily Scrum every Developer reports individual activity, but nobody refers to the Sprint Goal.
What I have noticed is that when this happens, most SMs simply inquire, “How is the Sprint progressing?”
That’s a very broad question, and a quick answer could be “It’s going well.”
But when you ask, “I noticed that we covered everyone’s tasks, but the Sprint Goal didn’t enter the conversation.”
and then pause…
That pause gives the team an opportunity to connect “your” observation with its own experience.
Telling your observation provides focus
Asking a question leaves interpretation and ownership with the team
We are NOT choosing between coaching and telling. A well-formed observation is a coaching intervention. It helps the team face reality without prescribing what to do about it.
Questions work well when there is something to discover
Telling observations become valuable when something important is already visible but gets ignored
Knowing when questions become avoidance
Questions are powerful.
But they can also become a place where you can hide your opinion.
Sometimes Scrum Masters keep asking questions because observations feel uncomfortable.
Questions are psychologically safer
Observations are more personal
If you’ve asked three different questions about the same issue and the conversation keeps circling back, it’s worth checking the following:
Am I helping the team think?
Or am I avoiding saying what everyone already knows?
Coaching is a way to create the maximum amount of awareness, not asking maximum questions
How to tell observations… respectfully?
If it happens once… it is an event.
If it happens twice… it is coincidence.
But…
If it happens the third time, it is a “pattern,” and it is your job to make your team aware of these patterns.
Naming a pattern on a single data point gets you a factual argument about that data point rather than a conversation about the pattern.
Below is how you can name these patterns respectfully:
1. Ask permission when the topic is hot.
"Can I share something I've been noticing over the last few sprints?" This changes the posture of the room from being told to being offered.
2. Name group behaviour in the group. Name individual behaviour in private.
"We" and "the conversation" are safe subjects in a retro. A person's name attached to a criticism is not safe, unless it's genuinely neutral and observable.
3. Use counts and timestamps, not adjectives.
"Three times in this session" is still discussable. "You people always ignore this" is not discussable
4. Hand it back and then stop talking.
End with an open question, then let the silence do its work. Most Scrum Masters ruin a good observation by adding a second one.
Applied to examples:
“Twice now, someone has raised a concern about the release date, and both times the room went quiet, and we moved on. I’d like to go back to it.”
2. Sprint Goal being ignored:
“I looked back at this sprint’s Daily Scrums. The Sprint Goal wasn’t mentioned in four out of five. Is it safe to keep ignoring it?”
3. Repeating behaviour:
“This is the third retro where we’ve agreed to break stories down smaller. Looking at the board, the average story is the same size it was in April. What’s stopping us doing that?”