Conducting a Post-Mortem Review


Post-mortem reviews can be very casual, but in our experience they're much more helpful when you create an agenda and stick to it. Without structure, any meeting can become chaotic , but an unstructured post-mortem review can quickly devolve into a "bitch session." When this happens you get very little benefit from the review. People talk about what went wrong, which is cathartic in the short term, but no long- term improvements are realized.

From Gary's experience with moderating project post-mortem reviews, we present guidelines for making the review session effective.

Involve the Whole Team

While it seems obvious to invite all team members to the review, many post-mortem reviews are held without all team members present. Either members aren't invited, or they aren't available at the appointed time.

Sometimes a team doesn't invite certain people because they are perceived as disruptive or they didn't meet the rest of the team's expectations on the project. The team decides, incorrectly, that the missing member will add nothing to the meeting. It turns out that the team will often learn a lot by inviting this person. If nothing else, they will get a deeper understanding of why the difficulties existed, and perhaps what type of person isn't a good fit for the team in the future. Even better, they might learn how to work effectively with more and different types of people, so that in the future they can increase the diversity of the team.

Sometimes people aren't available because they are on vacation, or they have already started work on another project when the post-mortem review is scheduled. Make every attempt to change the schedule if necessary to accommodate these people. You just went through a project as a team, and you should review the project as a team. In the worst case, you can set up a phone link to let the missing members participate remotely. Remote participation is hardly as effective as in-person participation, but the team member is at least able to provide comments and realize that the team does value him or her.

There is one case in which it's appropriate not to invite a team member. Depending on the organization and the culture of the team, the project manager is sometimes a deterrent to openness. Some managers still rule by fiat and decree what the team will do, how they will act, and so on. These managers stifle honest criticisms of the project. You might ask how the team would even be allowed to have a post-mortem with such a manager running the project. Some organizations require a project post-mortem. Because it's required, the manager schedules the meeting, but ensures that nothing negative comes out of it.

Finally, remember that the whole team includes everyone who participated in the project, including the customers and other stakeholders. While you could have a post-mortem review without them, we strongly recommend that you invite them and encourage them to attend .

Provide an Agenda

Team members attending a post-mortem review should understand the purpose of the meeting, and what will occur. The agenda doesn't have to be very detailed, but there should be a clear purpose and estimated amount of time spent for each part of the agenda. The agenda is no different than an agenda you would publish for any other meeting, but you should make every effort to create one and publish it to the team well in advance of the meeting. Figure 11.1 shows a sample agenda for a post-mortem review meeting.

Figure 11.1. Sample post-mortem review agenda

graphics/11fig01.gif

Establish Goals

Setting a clear goal for the meeting is important so that participants can tell if the meeting is successful. The purpose of the review is to improve the team's process for the next project. You may think of other goals that you want to express to attendees.

Provide Preparation Guidelines and Activities

To have a successful and useful post-mortem, it's necessary for everyone to participate and not just show up because they have to. The best way to guarantee participation is to ask attendees to prepare for the meeting.

What type of preparation is most appropriate? That will depend upon the goals of the meeting, but in general we encourage you to ask these questions.

  • From the customer's viewpoint, how well did we meet our objectives?

  • From the company's or organization's viewpoint, how well did we meet our objectives?

  • From the project team's viewpoint, how well did we meet our objectives?

  • From my personal viewpoint, how well did I meet my objectives?

  • Considering each viewpoint, were the objectives realistic?

  • Considering each viewpoint, were the objectives clear?

After considering questions about the goals of the project, participants should answer the following questions and bring their answers to the review.

  • What caused me, personally , the most difficulty during this project? Why? What could I have done differently to help alleviate the problem? What could others have done differently to help alleviate the problem? What was the net effect of this problem on the project?

  • What went well during the project? Why? What was the net effect?

  • What went poorly during the project? Why? What was the net effect?

  • What things did we do that seemed to have no reason, but took up a considerable amount of my, or my team's time? How could we have reduced the time or eliminated these activities?

  • How did I feel about the whole experience? Was it a positive or negative experience? Am I proud of the work I did? What did I learn? Would I do it again? What would I do differently?

  • Did the team work well together? Why or why not?

Many of the items on this list are in the realm of the soft side of software development. As you know from reading this book, we think that the soft side is as important as any other aspect of software development. One of the early reviewers of our manuscript, Magnus Lyck , said it eloquently: "Psychology is the trickiest part of software engineering." The post-mortem is like a group psychology session for the team. And like a group psychology session, you need to control it to make sure that you get results.

Employ a Facilitator

Meetings such as post-mortem reviews are best run by someone who isn't a part of the project team. Many meetings benefit from having an outsider facilitate because that person has no vested interest in the meeting and is viewed as impartial. The impartiality is an important factor in achieving open communication among the team members.

In a large organization, there are often several people who naturally make good moderators. You know who they are. They are the people whom everyone seems to respect and trust. They are the people who don't "flame" people whose opinions differ or who make "silly" statements. When you identify these potential facilitators, get to know them and establish a relationship with them. When it's time to hold your post-mortem review, ask if one of these people can facilitate the meeting.

There are times when no one from outside the project is available to facilitate the meeting. In such cases, ask the team member who comes closest to being the "facilitator type" to lead the meeting. This person must be comfortable with the role. This person also cannot participate in the session as if he or she were a regular team member. And it's best if this team member isn't in a management position.

When a team member facilitates the post-mortem review, there are times when he or she wants to contribute to the group's discussion in a more personal way. When this happens, facilitators must step out of the facilitator role, make it clear that they aren't speaking as a facilitator, get someone else to facilitate if possible, and clearly identify when they step back into the facilitator role.

There are many good references to how to (and how not to) run effective meetings. One of our favorites is a film called "Meetings, Bloody Meetings." This is a hilarious look at meetings starring John Cleese of Monty Python fame. It is perhaps the best training film ever made on the subject of how (not to) chair a meeting. [1] One book that describes how to facilitate meetings like the post-mortem review is Facilitator's Guide to Participatory Decision-Making by Sam Kaner et al.

[1] This film is available from several sources. Use your favorite Web search engine to locate it.

The post-mortem is, in fact, a decision-making meeting. In it, the team members decide how they want to work in the future, as individuals and as part of a team. What could be more important?

Once you have facilitated a post-mortem review, or other meeting where the group is charged with making decisions, you will find your own style. Our observations are that you will be most successful if you can maintain a "gentle" approach to controlling the meeting, while actually having firm control of it.

Produce Action Items from the Review

The post-mortem review should be more than a time for everyone to get together and reminisce. There are many ways of eliciting, collating, and prioritizing the information the participants bring to the meeting. Many of these activities are similar to those described in RUP about how to run a Requirements workshop. If you think about it, this makes sense. During the project post-mortem, you are eliciting requirements for the next project ”on the organization, the project team, and individuals. You are defining success criteria for the next project.

We recommend grouping the items in two dimensions. One dimension is a temporal dimension: short term to long term. The other dimension identifies the scope of the action: personal, project, and organization. Table 11.1 shows an example of such a chart. Each action item produced from the meeting should be assigned to one of the cells on this grid.

Table 11.1. Format for action items from the post-mortem review
 

Short Term

Long Term

Personal

   

Project/Team

   

Organization

   

Decide what your team considers short-term and long-term. We suggest two or three months as the boundary for most organizations. How you group the items really isn't that important, nor is the definition you give to each column and row heading. Some of these categories may not even apply to your project. Certainly for the PSP Tools project, the organization-level items weren't relevant. The important thing is that each person has at least one item on the board that she or he owns.

Act and Revisit Regularly

This guideline is critical. If you are just going to make the action items and then leave it up to individuals to "do the right thing," don't waste everyone's time. You would be better off buying each team member a good self-help book. Make a point to meet regularly to discuss how people are doing with their actions. You just finished a project as a team. Now continue to support each other (and the organization) to achieve the goals you've established for yourselves.

Do Something Fun

Either end the post-mortem review with a fun activity or plan such an activity for another time. The activity doesn't have to be elaborate or expensive, but it can serve as a nice acknowledgement of the humans who worked on the project. And it can be a creative way for the team to both bond and let off some steam . Suggested activities range from goofy (but not mean-spirited) awards to an ice cream party to an outing. Pick something that's right for your group and that your group will enjoy.



Software Development for Small Teams. A RUP-Centric Approach
Software Development for Small Teams: A RUP-Centric Approach (The Addison-Wesley Object Technology Series)
ISBN: 0321199502
EAN: 2147483647
Year: 2003
Pages: 112

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net