Retrospectives

Study groups address programmers' needs for continuous technical learning, but when does the entire XP team customers, developers, and coach come together to reflect and learn about how to improve? The whole team gathers during release and iteration planning meetings, but the primary purpose of those meetings is planning, not learning. So what happens when something in the current process isn't working well? Too often, there is simply no time to air the problem, discuss it, and resolve it.

What is commonly missing is the practice of holding retrospectives. Norm Kerth, author of the book Project Retrospectives: A Handbook for Team Reviews [Kerth2001], describes a retrospective as an end-of-project review, involving everyone who participated on the project in examining the project to understand:

• What happened

• What the community could learn

• What the community could do differently next time

The continuous learning approach to retrospectives means they come not at the end of a project, but at the end of every iteration. Conducting iteration retrospectives enables teams to quickly adjust and improve their performance because they are continuously revisiting these questions.

• What worked well?

• What did we learn?

• What should we do differently next time?

• What still puzzles us?

Norm gives very clear guidelines for successfully conducting retrospectives. I'll do my best to summarize them here, but you'll probably enjoy reading his book, which is destined to become a classic.

Norm recognizes that people have a fear of retrospectives because they have a fear of being attacked, of being made to look foolish, of getting a poor performance review, or of hurting someone's feelings. Yet no retrospective can succeed if people are afraid or if there is an atmosphere of blame, criticism, sarcasm, or even humor at other people's expense. Therefore, Norm lays down specific ground rules that help establish a safe environment for conducting a retrospective. Perhaps the most important of these ground rules is Kerth's Prime Directive of Retrospectives, which states:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand. [Kerth2001]

Once the group understands these safety ground rules, it's time to break out some butcher paper. This is paper that is usually 30 feet long and six feet high. Norm likes to hang this stuff from the walls, break it up into sections of a timeline (for example, three sections could signify each week of a three-week iteration), and then have teams go off and identify key events or things that happened during each section. People then add their identified events and happenings to the various sections of the timeline, which is next mined for stories and team goals. Norm suggests that professional facilitators help lead this process. In fact, he believes it is vital that the facilitator be an outsider and not a member of the team involved in the retrospective.

The final part of a retrospective is perhaps the most important. This is when the participants take the lessons learned during the retrospective and turn them into concrete ideas for improving their development process. This is hard work. I would add that it is particularly hard on XP projects, because it is easy to think you've found a deficiency in the XP process, when all you've really found is a faux deficiency. Chris Collins and Roy Miller describe how "process smells" can be identified during retrospectives, and they advise people to be careful about how they choose to fix them.

The key to retrospectives is to make sure you are solving the correct problem. Sometimes the tendency is going to be to add a practice to the process, where the real problem is in how you are implementing one of the twelve practices. [Collins+2001]

So how much time should it take to run one of these iteration retrospectives? If we spend too much time on them, we'll lose vital development time. I asked Norm about this, and his answer surprised me. He said that even for a three-week iteration, he would begin with a retrospective that lasts two and a half days. I thought that was excessive, but Norm explained that groups need to learn how to do retrospectives. When beginning to perform retrospectives, they need lots of time. As time goes on, they will get better and better at it, until it takes perhaps only half a day. I marveled at the simple good sense of this advice: Take time early on to get good at doing retrospectives, and you won't need much time to do them in the future.