In a Sprint Retrospective, a junior firmware Developer admits they knew the Sprint Goal was at risk a week earlier but stayed quiet because they were afraid of being blamed. What should the Scrum Master focus on in response?
Select an answer to reveal the explanation.
Short Explanation
A late-surfacing risk is a symptom; the real story is what made staying quiet feel like the safer choice. Turning that into a team conversation about what needs to change — not a hunt for who to blame — is how you actually get earlier warnings next time, because safety is what determines whether people speak up at all.
Full Explanation
The core mechanism is that empiricism depends on transparency, and transparency depends on people feeling safe enough to surface bad news before it's too late — so the Scrum Master's job is to address the safety gap itself, at the team level, rather than the individual incident in isolation. Hunting for someone to hold responsible does the opposite of what's needed: it confirms the Developer's fear was justified and makes the next risk even less likely to surface early. Rushing past the topic to protect the Developer's feelings in the moment avoids the discomfort but wastes a genuine opportunity to improve how the team works, which is the entire purpose of a Retrospective. Redirecting the Developer to escalate to the Product Owner instead of the team misdiagnoses the problem as a reporting-channel issue rather than a trust issue, and it also bypasses the team's own ability to inspect and adapt together. A concrete follow-up: agree on one specific, observable change — like naming risks explicitly during the Daily Scrum — and check at the next Retrospective whether it actually happened.