A firmware Developer privately tells the Scrum Master that a safety-certification test has been failing for two Sprints, but the Developer has been afraid to raise it in the Daily Scrum because a previous Scrum Master publicly criticized bad news. What is the most effective step for the Scrum Master to take first?
Select an answer to reveal the explanation.
Short Explanation
Picture transparency like a window — if people are scared to open it, the room stays dark no matter how good your inspection process is. The fix isn't one brave announcement, it's rebuilding trust so bringing bad news early feels normal, and that starts with how the team talks about problems together, not with one dramatic confession.
Full Explanation
This is fundamentally about psychological safety as the precondition for empiricism: you can't inspect and adapt to reality you're too afraid to say out loud. Working with the whole team on how problems get discussed — for example, explicitly welcoming early bad news in the Retrospective — treats the fear as a team-level pattern worth changing, not a one-off favor to a single Developer. Fixing the certification issue personally removes the immediate problem but leaves the underlying fear intact, and it also strips the Developers of ownership over their own technical risk. Telling the Developer to just announce it unsupported ignores the real reason for the silence and risks repeating the exact harm that caused it. Quietly pulling the item off the Sprint Backlog hides the problem rather than making it transparent, which directly undermines the artifact's purpose of showing real, current work. A concrete check: watch whether the next piece of bad news — from this Developer or anyone else — surfaces in the Daily Scrum itself rather than in a private aside to the Scrum Master; that shift is the actual signal safety is improving.