A Scrum Master notices that the Developers are hesitant to raise a serious integration risk in the Daily Scrum because a stakeholder who is not part of the Scrum Team often sits in and criticizes anything that sounds like bad news. What is the most appropriate Scrum Master action?
Select an answer to reveal the explanation.
Short Explanation
A Daily Scrum only works if people can say the honest, unglamorous thing without getting pounced on for it. When an outside voice is quietly punishing bad news, that's an impediment as real as any technical blocker — and it's exactly the kind of thing a Scrum Master should step in and address, not just work around.
Full Explanation
Empiricism depends on transparency, and transparency depends on people feeling safe enough to surface real problems; a stakeholder who reflexively criticizes bad news is degrading exactly that, making it a legitimate impediment for the Scrum Master to address. The Scrum Master's accountability to serve the Scrum Team includes causing the removal of impediments to the team's progress, and a chilling effect on honest reporting inside an event qualifies. Telling the Developers to simply stop mentioning risks treats the symptom as the problem and leaves the underlying dysfunction — and the actual integration risk — unaddressed, which is worse for the product long-term. The Scrum Master personally absorbing and relaying the risk removes the Developers from a conversation about their own work and doesn't fix the environment that made them hesitant in the first place. Escalating the Developers for 'hiding' the risk blames the people responding rationally to a hostile environment rather than the environment itself, and misreads where the actual problem sits. The concrete move is coaching the stakeholder on the event's purpose or, if needed, adjusting Daily Scrum attendance, since the Guide notes the Developers can invite others but control who's present when it interferes with the event's purpose.