Project Retrospectives DOA?

Dr. Shepherd: [Packing away the defibrillators] "We did everything we could, but it wasn't enough... we lost him."
Dr. Grey: [Looking lost and emaciated] "The only thing left to do now is hold our project post mortem."
Dr. Shepherd: "Yes, let's start by talking about the things we did right, and then look for opportunities to improve in the future. There's no topic we can't broach given enough post it notes and white boards."

I'm sure that Grey's Anatomy is about as accurate a depiction of hospitals as Hackers is of my workplace (and if you haven't seen it then think Jeff Goldblum uploading a virus to on oncoming asteroid). But I still can't imagine a group of doctor's holding a post mortem and starting off by discussing what they did right. Somebody died! That's what post mortem means: "after death". (And if they do start this way that doesn't ruin the post... read on).

A post mortem is a very serious event. Someone has died. If it is within our control, then we need to make sure it never happens again. It isn't a time for constructive feedback and team building. It is a time to focus on the mistakes. Does anyone seriously thing that performing a trust fall exercise is an appropriate response to a death?

Project retrospectives are different. It's not a team of 2 surgeons, some nurses, and a handful of smart, flawed, yet sexy interns (that's you Christina Yang). It's a much larger team including developers, managers, quality assurance, tech writers, even sales. In the wake of a failed project you're probably demoralized, maybe bitter, definitely overworked. With retrospectives it's OK to pull out the index cards and pipe cleaners. Heck, order some pizza. Let's have some fun. But let's not call them post mortems. Our work is a lot different than surgeons. As developers we're known for hubris, but comparing ourselves to surgeons is a bit rich. Right?

Let's consider for a moment that there is a substantive difference between the situations that call for a post-mortem and those that call for a project retrospective. When do you cross the line from one to the other? It is easy to consider that a human life may be at one end of the spectrum and a small software project at the other end... but where do the two meet? Here's an interesting way to think about it: take all the jobs in America that require low skill. Now look at the hourly wage for each one. You'll see that as risk of death increases, so does hourly wage. Using these numbers it is possible to calculate the amount of money American workers will accept in exchange for a higher risk job, and statistically speaking, death. Timothy Taylor at Macalester College did this, and the answer is 5 to 7 million US dollars per human life.

So by one measure a human life is worth 5 to 7 million dollars. What is your project worth? 1 million? 2 million? 5 million? A human life? 2 lives? We're in a serious business here. And since that business is software we're allowed to be cold and calculating. Or maybe it's just me.

Anyway, my point is that not only is there no clear delineation between those projects that require post mortems and those that require retrospectives, there is actually no delineation at all. The only difference is what you call it (and that is a big difference). Using the post mortem metaphor for your project retrospectives invokes a response from the participants. One of seriousness, somberness, and possibly death. The term retrospectives invokes pipecleaners and pizza. Arguably more fun. Proven to be more effective. Seriously, go look at the research. Looking at what you did right over the course of the project is the best thing to do... even if someone died. There is no human-cost magic that precludes retrospective best practices on your project.

The first step towards an bad retrospective is calling it a post mortem. A meeting announcement called "Post Mortem" prepares the participants for a negative, serious, and somber event, which isn't an atmosphere conducive to organizational learning. It doesn't matter how much free soda and food you show up with.

But what does it matter? "Who cares what we call it," you're thinking. Well, imagine the following three couples in marriage counseling:

Couple 1: "We had a strong, healthy marriage. But now we have a sick relationship."
Couple 2: "We were crazy about each other. But now she's driving me out of my mind."
Couple 3: "She cast her spell over me, she had me hypnotized. But now the magic is gone."

Each couple uses a different metaphor for love. The first couple uses a patient metaphor, in which love is something that can be nurtured and healed over time. The second couple sees loves as a madness. Love is irrational at times, but madness in our society can be dealt with. Maybe medication is required, but there are still options. And the third sees love as magic. Unexplainable, unaccountable, and certainly something without morals.

Which of these three couples is most likely to salvage their marriage? Couple 1, right? Implicit in the language is their knowledge that relationships require work, and are subject to some forms of cause and effect. Which couple is most likely to split up? Couple 3, right? If love is something totally unexplainable, that is completely outside of your abilities and behavior to affect, then you're not going to even try to improve the marriage.

Since the 1970s, linguistic researchers like George Lakoff and Mark Johnson have been showing that language shapes our experience, rather than reflecting our experience. By thinking and speaking of love as a patient, couple 1 is increasing the likelihood that they will work to correct their relationship. They aren't using that language because that is how they behave... they are behaving that way because they are using that language. You don't refer to love as madness because you continually make irrational decisions; instead, you are making those poor decisions because you've mentally framed love as a madness, which is not subject to rationale and clear thinking. Has anyone ever told you that forcing yourself to smile will eventually make you a happier person? They might be right.

So when when your project "post mortem" is completely derailed, and people are yelling at each other, and there is enough blame to go around for several projects... maybe you shouldn't have called it a post mortem. Maybe you should be more careful with the language you use. And if someone really has died... hopefully you're a doctor and then hopefully you have insurance.

And at the end of it all, you're thinking, "Seriously? 1000 words to tell me to call it a retrospective and not a post mortem?" Yeah. It bothers me that much. That's why mine are called Futurespectives. But I wouldn't want to force that level of cheesiness on anybody.

Disclaimer: This post has a much longer history than my current employer and in no way reflects any real events in the last year.