Running a release retrospective without turning it into blame
Facilitation habits that keep post-release conversations on observed impact and next-window changes.
After a difficult cutover, people arrive tired and defensive. A useful retrospective still needs the deployment timeline on the table — but the tone determines whether anyone will speak honestly.
Open with the timeline, not the verdict
Start by reconstructing when the release started, paused, rolled forward, or rolled back. Shared facts reduce the urge to jump to personal conclusions.
Ask what was observed, then what was inferred
Separate “payment retries rose for two hours after 21:40” from “the new library is bad.” Both statements may matter; only the first is an impact observation.
Cap the room
More than a dozen people usually turns the session into status theatre. Invite the release owner, the on-call who lived it, and one product counterpart who felt customer impact.
Write disagreements down
If two plausible causes remain, record both. Forced consensus looks neat and teaches nothing.
AutoDeploy HQ’s Release Retrospective Facilitation prepares from your timeline and keeps the room on release impact. The output is a short agreed record for the next window — not a performance review.