A couple of months ago during a workshop presentation on the topic of getting started with DevOps, I was asked an interesting question:

Is it easier to start with retrospectives, or with postmortems?

The two serve distinct, although related, purposes. Retrospectives exist to encourage regular retrospection, whereas postmortems serve to understand root causes of incidents and prevent future reoccurences. So naturally, most teams will want to do both.

But if your team is doing neither, which is easier to start with?

If your team is open to it, by all means, start doing retrospectives regularly (monthly or biweekly). But if this doesn’t work, or you sense resistance, then starting with postmortems could make good sense. Here are some reasons:

1. Postmortems are timely. They ideally happen the day after a major incident has been resolved. This means everyone still has the incident, and its resolution, fresh on mind, and are generally in the mood to prevent such an incident from recurring.
2. Postmortems are focused. Each postmortem focuses on a single incident, and its proximate causes. This leads to focused discussion in a way that retrospectives may not.
3. Postmortems are blameless. Of course, your retrospectives, and indeed entire company culture, ought to be blameless, too. But if this is not already part of your culture, starting this tradition in isolation can be easier.
4. Postmortems can gracefully turn into retrospectives. Every postmortem requires follow-up. If your team is ready for it, you can easily turn your first postmortem followup into your first retrospective. After addressing the old business from the postmortem, leave the meeting open for other areas of improvement.

If your team could use some help implementing effective blameless postmortems, I’d love to help. Reach out and let’s discuss your needs.