This post originated from an RSS feed registered with Java Buzz by Michael Cote. Original Post: Yourdon on Postmortums Feed Title: Cote's Weblog: Coding, Austin, etc. Feed URL: https://cote.io/feed/ Feed Description: Using Java to get to the ideal state. Latest Java Buzz Posts Latest Java Buzz Posts by Michael Cote Latest Posts From Cote's Weblog: Coding, Austin, etc.

In a short CIO Radio interview, Ed Yourdon says he's not too fond of postmortems for software projects. More specifically, he's doesn't like postmortems at the end of a project, vs. "mini-reviews" throughout the project. The problems, he says, are:

• There's a "corporate, political, reaction of sudden amnesia" after successful and, esp., failed projects. No one wants to say anything "negative" that'd be valuable.
• The people who know best or have the best comments typically have been demoted, moved on, are burned out. That is, there's an even lesser chance of valuable feedback.

Instead, he suggests mini-postmortems, e.g., at the end of iterations. This is, indeed, one of Scrum's aspects: instead of doing the review at the end of a release, it's done at throughout the release. This addresses the above problems, and has the benefit that:

• Goods and bads are fresh in people's minds, so the content of the review has a greater chance of being good.
• You can apply the things that come up in the mini-postmortems right away, in the current release you're working on, potentially fixing problems before they get out of hand.

I like all this, of course, because I'm a feedback-freak: I crave feedback so that I can correct things I'm doing wrong, and get reinforcement/verification for things I'm doing right. On a team level, as the second advantage points out, doing postmortems at the end of a release instead of at the end of each iteration, doesn't give you any feedback to correct course within the release.