After a production incident on the state unemployment-claims portal, some managers want names. What should the Scrum Master / Team Coach ask first?
Select an answer to reveal the explanation.
Short Explanation
"Who is at fault?" slams the door; "What did we learn?" opens the lab. Unemployment-claims outages are ugly enough without a hunt for a scapegoat. Learning first keeps the team honest and still able to talk.
Full Explanation
Learning-oriented questions come before blame questions if the team is to inspect a production incident safely. After a production incident on the state unemployment-claims portal, when some managers want names, the Scrum Master / Team Coach should ask first what the team learned so improvement is extracted before blame. That framing protects psychological safety, accelerates root-cause learning, and keeps benefit payments and claimant experience at the center of the response.
Asking who is at fault so it can be documented before the next increment fails by concept: it converts learning time into scapegoating and suppresses honest reporting. Asking which vendor SLA clause lets the team skip a learning review fails by concept by using contracts to avoid inspect-and-adapt after a civic production failure. Asking how fast utilization hours can be restored to pre-incident levels fails by concept: it optimizes busyness metrics over understanding and fixing the portal failure mode.
Exam caveat: SASM and SAFe DevOps culture emphasize blameless learning after incidents; naming culprits first is a common exam distractor. Accountability for follow-through still matters—accountability for learning and fixing is not the same as public shaming of individuals on unemployment systems.
Operational check: open with a learning question, run a short blameless review focused on timeline and system factors, capture experiments with owners, defer personnel blame narratives, restore service with verified fixes, and confirm the next similar incident starts with learning rather than a names list.