A Retrospective on Retrospectives

If you follow the Agile movement, you have no doubt run into the idea of retrospective meetings. In fact, you have probably run into them in lots of other places too. The basic idea is very simple: at the end of a project, iteration, event or whatever, the team involved gets together to discuss how things went and see if there are things they could do better the next time.

Sounds simple, but I’ve seen enough of them to suggest that most groups are probably overdue for a retrospective on their retrospectives.

Common Mistakes

  1. Trying to do too much. Any group that leaves a retrospective with a list of more than three things they are going to change have too long a list.
  2. Not holding them often enough. If your lists are too long, or you seem to be discussing too many items, you probably aren’t holding your retrospectives often enough.
  3. Meeting for too long. If you feel the need for a ½-day meeting to discuss the results of some project, you haven’t been meeting often enough. These things can, and must, be kept short.
  4. Not organizing your outcomes. Even if you have a short list of three items, if they are all for the same person or group, you have too much.
  5. Not using a formal structure. Does everyone just get together in a room and complain, or do you have a method for these meetings?

For Best Results

  1. Use a formal structure. To begin, make sure you have a single person in charge of running the meeting. Their job is to keep everyone on topic, and the meeting clicking forward. Then choose a structure that works for your group. At GenoLogics, we do our retrospectives in three phases: first we brainstorm all the things we need to STOP doing. Then we brainstorm everything we need to START doing. Finally, we highlight anything we should CONTINUE doing. This simple structure keeps everyone on topic and guarantees you have useful output at the end of your meeting.
  2. Keep them short. If your retrospectives last longer then 30 minutes, see the previous point. You probably need a better structure.
  3. Try to fix one thing at a time. I suggest every individual come away with one item, each group choose one item, and each department or company pick one item (this last is optional).
  4. Meet often. If you have two- or three-week iterations, hold a retrospective after every iteration. If you don’t use iterations, or you use longer cycles, hold a retrospective once a month. If you wait too long you’ll forget important ideas.
  5. Record your commitments and follow-up. Since you are holding retrospectives regularly, they are an ideal time to follow-up on everyone’s actions. Take the first ten minutes of each retrospective to ask everyone a quick “did” or “didn’t” for their assigned actions from last time.
  6. Publish the results. By making the results public, everyone can learn from the same mistakes. The cheapest mistake to learn from is somebody else’s. Don’t lose this opportunity.

I’m sure your situation has its own characteristics. Some of these ideas may not apply to you, but they are a good place to start your own discussions.

How does your group do retrospectives? What lessons have you learned? Please add a comment and share your ideas.

(Someone will no doubt notice that this retrospective has six items, not three. I guess every rule has a proper time when you should break it.)


2 thoughts on “A Retrospective on Retrospectives

  1. As a facilitator (and Scrum Master) of many retrospectives, I found that quite often on a team there are those members who are eager to provide input and they can often “outspeak” others, leaving some team members silent. And I’ve been at this long enough to know that silence doesn’t mean someone does not have something to offer.

    To avoid only hearing form the “loudest” team members, I’ve used sticky notes during the brainstorming phases. Then we would have people stand up, post their note on the board (under the appropriate column of “keep doing”, “stop doing”, “start doing”) and explain their thinking/suggestion.

    The discipline of making sure everyone on the team is heard was very worthwhile. And after some practice I found that the quietest and most reserved team members ultimately became more forthcoming.

    • This is an excellent idea kaptaink. I’ve seen sticky notes used to great affect in situations like this. The only downside I’ve seen is that they sometimes result in far more material being put on the board than can be dealt with in a limited time. Fortunately, that’s pretty easy to fix: just give everyone a fixed number of sticky notes. That immediately gets everyone thinking about their most important items first. Also, by having an allotment of stickies, I find it easier to encourage people who might only put up one or two ideas, to really use their entire pile of stickies.

      This gets the quiet people “speaking” (though their notes) and prevents their more vocal people from saying too much. Overall, stickies are a terrific idea and I’m glad you brought them up!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s