The retrospective is a key and often overlooked part of the Scrum process. I believe one reason for the success of my Scrum team in the past few years is related to our consistency in doing retrospectives at the end of each sprint.

I've seen other teams sometimes skip over retrospectives, for a variety of reasons:

• Retrospectives don't seem that important
• The team is too busy to take time to retrospect
• They believe that doing retrospectives won't improve anything

Having done a lot of retrospectives, from my experience, the retrospective serves a number of purposes:

• It provides a structured environment for the entire team to brainstorm ways to improve things
• It helps the team to bond—they have a time specifically to discuss their feelings and experiences, and to listen to each other
• It provides the team a sense of closure at the end of each iteration
• It allows team members to voice grievances and annoyances in a supportive environment
• Simply scheduling the time for the retrospective communicates to the team that their feelings and opinions are important and valued

The most obvious purpose of the retrospective is making improvements to the process. It may seem that making a few small process improvements each sprint won't really add up to much, but this has not been my experience. Although the individual improvements can seem very small, the cumulative effect can be quite surprising.

Thoughts and suggestions about retrospectives

(If you are unfamiliar with Scrum or the retrospective, I encourage you to read the excellent book Agile Software Development with SCRUM by Ken Schwaber and Mike Beedle. I strongly recommend this book—I think it is the best book I've seen about Scrum.)

First of all, I always refer to it as a “retrospective”, not a “postmortem” or anything else. Postmortem has the smell of death around it—I can understand people not wanting to go talk about how the iteration (and/or team?) “died” over the last few weeks. This word also implies a sense of hopelessness—the iteration or the team is dead and cannot be resurrected—instead we’ll just talk about how it died. On the other hand, the word “retrospective” gives the process a more hopeful tone—that you will look back in order to learn something that can make the process more pleasant going forward.

We start our retrospectives by making two lists on the whiteboard:

• What we liked in the previous iteration
• What we did not like in the previous iteration

We usually draw it with a plus sign at the top of the column for things we liked, and a minus sign at the top of the column for things we didn't like, for example:

Note that the second list is NOT defined as a list of mistakes that we made in the last iteration! This may be a subtle point, but it's important--not many people enjoy going to a meeting where they have to confess their mistakes over the past month. The list consists of things that we (members of the team) did not like. This can include mistakes we made, but the scope is much larger than that.

Note that, as the ScrumMaster for the team, I try to encourage and write down items in both areas, without adding too many of my own, or doing any editing or censorship of items. For the most part I just write items down—I don’t want to hijack the meeting so that it ends up being all about me.

In addition, I don't try to make the two lists “balance out” or be equal in some way—this is not a zero-sum game. If we had an unpleasant iteration, it’s likely that we'll have more items on the minus side than the plus side—and that’s fine! On the other hand, a really smooth iteration it may be the other way around, and that’s fine too.

I do what I can to encourage everyone to be honest—for example, if there is an event I recall that people didn’t like but nobody is bringing up, I’ll ask about it. Honesty is important—the more honest everyone is, the better the whole thing works. Sometimes this means taking social risks—we’ve had several retrospectives with people getting frustrated or angry and saying things like “I didn’t like how Bob would criticize my code!” If people are feeling it, this is probably the best time to talk about it, and it certainly makes the process a lot more interesting! Not talking about it just means that it likely won't change. In my experience, most of these types of interpersonal team issues were greatly improved after being brought up in a retrospective, and this greatly added to the team moral and productivity.

When we start running out of items, we prioritize the top few items that we didn't like. The prioritization is based on the importance of improvement in that area to us as a team. Usually the top priority items are the biggest pain points of the iteration for the team, and fairly easy to agree upon. Again, as ScrumMaster, I usually leave my own opinions out of the prioritization—I’ll sometimes add a bit, but I really don't want to control the prioritization.

Finally, we take the top two or three priority items from the minus side, and brainstorm as a team how we could improve the situation going forward. In my experience it's important to not select more than 2 or 3 items to improve, because they tend to be too many and some get forgotten, which makes the whole process seem pointless and frustrating.

It’s during the brainstorming about possible improvements where the real magic happens—the team is smarter as a whole than any individuals on the team. Issues that at first seem impossible to improve (items that you seem to just be stuck with) can often be improved in some way when the whole team focuses on them. Note that this means it often makes sense to spend some brainstorming improvements time on a painful item that everyone initially believes they cannot change. It is only in the brainstorming that the possibilities emerge. These improvements may not resolve it entirely but improve things incrementally—the tricky bit is that these possibilities can be difficult to see in advance. In my experience, the improvements sometimes involve more communication with someone (the product owner, users, someone on the team, etc), more training, new procedures, different tools, or a technical task for the next iteration to improve something. But there are no limits to the types of improvements you can brainstorm into existence.

And, as I said above, it’s important to follow through with the improvements—otherwise it undercuts the whole process.

In summary, if you are using Scrum but skipping retrospectives, I encourage you to try doing retrospectives seriously and consistently! From my experience, it may improve your team’s productivity and moral.