is post mortem the same as running a retrospective? Edited

[Siegfred Soriano]

How does one run a retrospective?  Is this the same post mortem conduct being done in the software development lifecycle?

[Paz · Accepted solution]

Great question (and welcome!).

A post mortem is typically an analysis that happens after an incident is resolved. It's usually focused on identifying causes, impact, next steps, and measures taken to avoid similar incidents in the future.

A retrospective, at least in terms of the Agile methodology, is primarily concerned about what went well, what didn't go well, and what might we do different next sprint. Sometimes it's referred to as what we'll start doing, what we'll stop doing, and what we'll keep doing, in regards to a team's ability to deliver on its commitments. 

[Luis Ortiz]

My team wrote a great blog post about the difference: Agile Retrospectives Vs. Post-Mortem

In general, Post Mortems are done by a management team after a project is concluded (Post-Mortem = After-Death). While in #Agile software development, Retrospectives are done at the end of each sprint (or whenever needed) during the entire lifetime of the project. It is also different because the Retrospective involves the entire team.

We've written plenty about what we've learned while working to develop Agile Retrospectives For Confluence and for Jira. 

[James Bullock]

The canonical reference on retrospectives is Norm Kerth's book: Project Retrospectives: A Handbook for Team Reviews. You'll find it and him referenced all over, like this article by Joshua Kerievsky. Another resource on retrospectives in software development is Naomi Karten.

These distinctions help:

• Retrospective -- Facilitated look back, facilitating those pesky humans.
• After Action Review -- Operationalized, about what you did and how.
  • "What to *sustain*, and what to *improve*.
• Post Mortem -- Really about "How did we not see that coming?

All three sit in any of the try-do-review-adjust organizational (or personal) learning loops: Deming, Kaizan, O-O-D-A, etc. They connect with the same activity, from different perspectives.

• Retrospective techniques address "OK, how do we 'see what happened?' with all the pesky humans involved?" The content is about facilitating.
• After action reviews aim to operationalize whatever you notice. I've taught "Sustain and Improve" borrowed from after-action reviews.Sustain balances perverse ways to "improve." One way to "improve" software production by shipping less bugs is to never ship anything. Problem solved, except for "sustaining" shipping useful stuff.
  
  • "Here's this stuff we did well: we want to sustain that."
  • "Here's this stuff that didn't work so well. We want to improve that."
• A post-mortem, like the name says, is about "How'd that unexpected bad thing happen?" You're looking at your idea of how the world works. Somebody dies from eating lettuce, that's not the way we think the world works; maybe do something about that.

[James Bullock]

Another resource the RetrospectiveWiki

[James Bullock]

Edit of Reply Above to question about "retrospectives" and "post-mortems."

The canonical reference on retrospectives is Norm Kerth's book: Project Retrospectives: A Handbook for Team Reviews. You'll find it and him referenced all over, like this article by Joshua Kerievsky. Another resource on retrospectives in software development is Naomi Karten. Try also the RetrospectiveWiki.

These distinctions help:

• Retrospective -- Look back, facilitating those pesky humans.
• After Action Review -- Operationalized, about what you did and how.
• PostMortem -- How did that happen? (Did we know this was possible all along?)

All three sit in any of the try-review-adjust organizational (or personal) learning loops: Deming, Kaizen, O-O-D-A, etc. They connect with the same activity from different perspectives. All three make sense in generating candidate changes that might help: fodder for experiments in changing how you work.

• Retrospective techniques address "OK, how do we 'See what happened?' with all the pesky humans involved?"
  • Retrospective technique is about facilitating.
• After action reviews aim to operationalize stuff you notice. I've taught "Sustain and Improve" borrowed from after-action reviews, in software engineering. "Sustain" balances perverse ways to "improve." One way to "improve" software production by shipping less bugs is to never ship anything. Problem solved, except for the shipping useful stuff part.
  
  • "Here's this stuff we did well: we want to sustain that."
  • "Here's this stuff that didn't work so well. We want to improve that."
  • Any change in how we work mus satisfy both: sustain the good stuff, improve what could work better.
• A postmortem, like the name says, is about "How'd that bad thing happen?" You're looking at your idea of how the world works.
  • Somebody dies in a war zone, we thought that was possible all along, or should have. Maybe we can mitigate, but the possibility was always there and we knew it.
  • Somebody dies from eating lettuce, that's not how we think the world works; maybe do something to get rid of that possibility. Or get more nervous about salad.