Checkups are especially appropriate if your team is following an iterative development process. At the end of each iteration, take time to reflect. The benefits are easier to identify because you’re more likely to remember things that happened a few weeks ago and a checkup takes a lot less time than a full-blown postmortem.

But, wait, let’s back up. I made one of those blanket assumptions at the beginning of the first paragraph. Just in case your organization needs a reminder about the benefits of postmortems, let’s have a little review.

First of all—the word "postmortem." It calls up a vision of a group of concerned analysts gathered around a cold, dead body. Most of the projects I’ve been on produced something worthwhile. The team should celebrate success as well as mourn mistakes. A good postmortem, or as I would prefer to call it, and will from now on in this article, a good retrospective provides an opportunity to see what went well as well as those oh-so-easy-to-identify-things-that-didn’t-go-well that we don’t want to repeat.

Conducting retrospectives is one of my professional interests. As an independent consultant, I help teams by facilitating retrospectives and supporting the follow-on activity of building on the knowledge captured in the process to make future projects better. There are others who are in the retrospective business. We met recently in the first ever retrospectives facilitators’ conference in a little town on the Oregon coast. We met to create an identity and to begin to share information about how we conduct our businesses and how we can improve. We also plan to create patterns: both patterns for retrospectives and patterns for projects based on our collective experience. In my next article, I will talk more about these patterns.

Let me tell you a story about a retrospective, one of the most valuable I’ve ever facilitated. You can judge for yourself whether this kind of experience would help your organization. All names have been changed to protect the company and the team.

The team lead called me in early January. His voice was full of despair, "Linda, our project has just been cancelled. These guys are really upset. Some have already given their notice. I can’t blame them. They worked over Christmas to get last minute fixes done and now management says it’s over. I want to make sure that this kind of thing never happens again. I don’t know whether there are patterns here but we need to learn from this." Of course I took on this messy assignment. Failed projects happen. But when they do, team members take that failure personally. They carry that guilt and anger with them to the next project—even if the project is in another company. If these issues are not addressed and continue to build in subsequent projects—burnout is inevitable.

Fred, my good friend and colleague, agreed to help me with what promised to be an especially challenging retrospective. This was a large team that had been together for over a year. I would need someone with me to manage this session.

My mentor, Norm Kerth, has written an excellent book [Kerth01] on this important part of the development cycle. He advises taking teams off-site for three days for an end-of-project retrospective. I usually don’t have the luxury of either the off-site location or the extensive amount of time. Most managers are lucky to find a couple of hours and the budget to buy lunch and count themselves lucky to have that! In our story, I had two hours to get 50 people through a retrospective.

Since the group was so large, we decided to use "quiet storming," a technique that allows each person on the team to write his feelings about any part of the project on a large index card and then post the card on the wall. We had categories across the top of the wall: Requirements, Design, Coding, Testing, Customer Interaction, and so on. Sometimes a card won’t fit the existing categories and a new category is added. As cards are written, they are brought to the wall and posted. Writers peruse the posted cards and as they do, ideas for more cards are generated. Anyone can write anything and all cards are anonymous.

As the wall began to fill up, people were spending more and more time, reading the cards. At one point, nearly everyone was standing at the wall. It was eerie. It reminded me of the Vietnam War Memorial. People were re-living the history of the project, dredging up bits and pieces, flashes of insight, painful moments, happy moments. I let them have time for this.

At this point, it was clear that no more cards were being added, so I asked them to look at the cards in each category and see if they could detect any trends. I asked them to look at the bigger picture, look beyond the details on the cards and see if we could capture: (1) What went well. We need to document those good things—and there are always good things—that we’re afraid of forgetting. (2) What should be done differently? Let’s not make the same mistakes again. (3) What do we still not understand? What puzzles us?

As we became more analytical, people began to think ahead and move beyond some of the painful recollections of this project. They could easily identify good things. They could see that there had been successes—things they could be proud of. They were able to talk about things that hadn’t worked well and what they would like to correct before the next project.

We were able to identify some potential patterns—from the good things and some action items—from the things that should be corrected on the next project. Follow-on meetings were planned and responsibilities assigned for the patterns and the action items.

Toward the end of this part of the exercise, someone in the back of the room said, "What good is all this anyway? We know nothing will come of it. We’re just going to go out there and do this all over again. We’ve already started to make some of the same mistakes on the next project and we’ve only been on it a few days!" To my very great surprise, the team lead jumped up and said, "I promise all of you that what we have captured today will be presented to every other manager in this company. This will not just go into some web page where no one will ever read it. I’ll take it all the way to the executive council." I was impressed—I think the other team members were, too, because no one said anything for nearly a minute. They were all taking this in. Maybe this company really could learn from its mistakes. Maybe things really would get better on the next project. Maybe there really was hope.

I guess that’s the point of the whole story. Without the retrospective, the team would never have found any hope. Each team member would have carried his burden onto the next project and the next, maybe never completely recovering. Good companies understand that what people produce reflects the things people bring to it.

One of my favorite stories about this phenomenon is from a book by Ruth Sawyer [Sawyer76].

He was Bavarian, little, very old. He had come to measure our davenport for re-covering. With painstaking care he got out of his coat and into his apron of blue-and-white-striped ticking, adjusted his pincushion, his shears, hung his tape measure about his neck. He got only as far as measuring the front; and there he sat, on his heels, while he told me about his experience as an under-master in the palace of King Ludwig. He talked about a special event held every year when everyone who worked for the king took part in an opera. Those who could sing were in the chorus. Those who played instruments made up the orchestra. A conductor from Dresden was brought to direct. The soloists came from the big cities. The great Wagner came. For a week the celebration was held; then everyone went back to work.

What the Bavarian upholsterer said at the last I have always remembered: "All the goodness, the lift of the heart that we got from playing those operas, we would put back into our work—in the draperies and tapestries we hung, in the cabinets we made. Nothing was lost. That is how it should be when you have experienced something great and beautiful. And so, my lady, something of those operas will go into your sofa."

There it is. Software developers or creators of any product put into their work the joy they find in their lives. When the joy has been taken away by hopeless schedules, 60-hour-weeks, missed ball games or piano recitals, it becomes harder and harder to retain that optimism and heart we software junkies are so proud of. One of the best ways of getting that back is a retrospective.

Our story has a happy ending. The team lead really did spread the word about lessons learned from the project. A report really was presented to the executive council. Several good patterns were also written and I’ll pass some of those along in the next article where I’ll share some ideas for making sure that the lessons learned in a retrospective or checkup don’t get lost.

References

[Kerth01] Kerth, N., Project Retrospectives: A Handbook for Team Reviews, Dorset House, 2001.

[Sawyer76] Sawyer, R., The Way of the Storyteller, Penguin Books, 1976.