Many teams look back at the end of a project and ask themselves “What worked, what didn’t?” This gives an opportunity to avoid making the same mistakes as we move on to future projects. But what if you didn’t wait until after the mistakes had been made before you asked “What isn’t working?”

Retrospectives take the idea of asking “What’s working, what isn’t?” and doing it at regular intervals while the project is ongoing. Asking these questions throughout the project gives the team the opportunity to reflect on those parts of the project that need to be improved before it’s too late.

How do They Work?

Although retrospectives take many different forms, they all focus on three basic questions…

1. What worked well?
2. What didn’t work well?
3. What do we want to try before the next retrospective?

Each of these questions aretaken in the context of ‘since our last retrospective’. For example, if you’re having retrospectives monthly, question 1 may be thought of as “What has worked in the last month?”

Let’s take a look at each of these questions to understand better what we’re trying to learn from them.

What worked well?

If this is your first retrospective, you may want to hear from your team which parts of your process really add value, from their perspective. This can be a good time to ask them about any standing meetings and what value they bring to your team, or about such tools as support project management or bug tracking that are entrenched in your process.

After your retrospectives are occurring regularly, this is a great opportunity to ask about any new ideas that you have tried since the last retrospective. If, for example,you decided at the last retrospectiveto try morning standup meetings to increase communication across the team,then this is a great time to ask how well those meetings are working.

What didn’t work well?

This is the meat of the retrospective. This question gives the members of your team the opportunity to bring up anything that is not working as well as it could be. This may be anything from meetings that have started to lose their value, to remote team members struggling to hear on speakerphones, or to poor test coverage in recent parts of the code…anything is fair game.

Also take this opportunity to get the team’s take on recent big events that have impacted the team. For example, a major customer issue, a team member’s departure, or a recent crunch time in preparation for a release.

In addition, encourage the team to keep notes of pain points that they encounter between each retrospective as ideas that they’d like to discuss. This is a great way to capture those nagging parts of the day that never seem important enough to bring up later.

What do we want to try before the next retrospective?

Think of the time between retrospectives as an experiment. You have the opportunity to try any new idea, technique, or process that you like, with the reassurance of knowing that you have the opportunity to completely abandon it at the next retrospective if it doesn’t work. As an example, imagine that your team would like to try test-driven development. Committing to test-driven development from here on may seem like diving into the deep end. However, if your team is participating in retrospectives every two weeks, thenit may not be as scary to commit to trying test-driven development for just two weeks. At the end of two weeks, your team can look at the pros and cons of this new technique and decide whether it’s right for them.

In fact, new ideas don’t even have to be as audacious as test-driven development. For example, your team may elect to tackle something as trivial as trying out a different mocking framework or a new format for your morning standup. Anything is fair game since your team has the option to pull the ripcord on that experiment at the very nextretrospective.

Picking Ideas to Try

If your team is typical, they won’t find themselves at a loss for ideas worth trying before the next retrospective. In fact, more often than not, you’llhave more ideas than you can handle. However, trying them all at once may doom the success of any.

Be limited in what you try

Resist the urge to come out of your retrospective with a baker’s dozen of new ideas. By actively focusing on the new ideas during the time between retrospectives, you’ll greatly improve their odds for success, but even the best teams can’t focus properly on too many new ideas at once. For this reason, choose no more than two new ideas to try between each retrospective.

Not just any goals…SMART goals

Another frequent pitfall is to choose ill-defined goals.And if the goal itself is not well defined, then success will be even less defined.

An easy solution to this is to design goals in such a way that they’re considered SMART. SMART, is an acronym that stands for Specific Measurable Attainable Realistic and Time bound. Choosing goals that meet these criteria will ensure that not only can you clearly judge their success or failure, but that they are realistic and clear to your team. For example, “let’s try test-driven development” is not a SMART goal. However, “let’s use test-driven development on two new stories and record our impressions before the next iteration” is a very specific goal that is attainable to most teams. In addition, by specifying what you would like to measure…i.e., how quickly were the different phases of the stories completed or how many bugs were introduced as a result of these stories as compared to the others…you have a true picture of what success looks like for this experiment.

Bailing Out

The beauty of having a regular cadence of retrospectives is that it creates a safe environment in which to try new ideas without the pressure of deciding for how long. But, what should you do when a new experiment seems to go awry from day 1?

If possible, try to stick with the experiment until the next iteration.

However, if the experiment seems hopeless, if it is actively damaging the velocity of your team in a very significant way, or something has changed within your team that now makes the outcome of the experiment irrelevant, then feel free to pull the ripcord on the doomed experiment before the next retrospective. Thoughan excellent topic for the next retrospective would be to discuss why the experiment failed so fantastically, and why this wasn’t foreseen when it was chosen.

Mixing it Up

Like any standing meeting, retrospectives have the potential to get a bit stale. Here are a few ideas to keep your retrospectives feeling fresh for years to come.

Retrospective Wall

A Retrospective Wall allows your team to immediately record areas of your process that aren’t going as smoothly as everyone would like. At the next retrospective, the stickies on the Retrospective Wall can make great conversation starters. If you find yourself with more stickies than you can likely discuss in the time allowed, then ask your team to rank the items most important to them using Dot Voting.

Although we all encounter pain points during the time between each retrospective, sometimes team members will struggle to remember specifically what wasn’t working during the actual discussion. If you notice just a general malaise with your team but no one can put their finger on why during the retrospective, then you may want to consider a Retrospective Wall.

Have the team use yellow stickies for items that need to be discussed but can wait for the retrospective while red stickies denote items which need to be dealt with immediately. Whenever a red sticky appears on the board, the team should immediately huddle to talk through the issue and develop a plan to tackling the problem.

Retrospective Pie

A Retrospective Pie is a technique for helping team members visually brainstorm things that went well since the last retrospective, things that haven’t gone as well, and things that they’d like to try before the next one.

The process is quite simple…

1. On a whiteboard or flipchart, draw a large circle.
2. Divide the circle into three equal slices, labeled with the icons shown.
3. Have the team brainstorm both things that they’ve noticed since the last iteration as well ideas they’d like to try before the next iteration and place those stickies on the appropriate slice of the pie. Things that went well should go in the slice with the smiley face while things that didn’t go as well should go in the slice with the frownie face. Ideas for the future should be placed in the slice with the light bulb.

If multiple team members seem to present similar ideas, encourage them to cluster their stickies close together so it becomes obvious which ideas are the most important and warrant the most discussion. If the most important ideas still are not clear, use Dot Voting to further clarify the team’s priorities.

Focused Retrospectives

After your team has begun to work the most noticeable kinks out of its process, you may want to consider an occasional Focused Retrospective. Rather than using the more common open format, these retrospectives center the same three-Question format on a specific problem currently plaguing the team. For example, if your team seems to be seeing a higher and higher number of bugs during each cycle, you may want to focus a retrospective on understanding why. This retrospective would focus the three questions on the problem at hand…

1. What actions have worked well to reduce new bugs?
2. What actions have we taken to reduce new bugs that haven’tworked as well?
3. What two specific things can we try during the next cycle to reduce bugs?

It’s often helpful to begin a Focused Retrospective with a “5 Whys” exercise aimed at understanding the root cause of the problem at hand. “5 Whys” is a root cause analysis technique that consists of simply asking “Why” 5 times in an effort to cut to the root of the problem. In the example above, a “5 Whys” chain may look like this…

There are two things to notice here. First, it doesn’t take exactly 5 Whys to get the root of the problem, sometimes it takes less, sometimes more. Secondly, there is more than one jumping off point in this question chain that could be the starting point for a brainstorming session on addressing the problem. In the example above, the answer to either question 3 or 4 would be suitable starting points for discussing with the team.

If the “5 Whys” technique is successful, then you should notice that both the answers and resulting questions become more and more specific as you progress through the chain. Once you start getting to answers specific enough that they could be addressed by the team, then you’ve started to hit the jumping off points for your retrospective.

Wrapping Up

Productive retrospectives are a key to a healthy, highly functioning team. In addition, many agile practitioners consider them a great gateway to the agile process. However, regardless of whether or not you intend to transition your team towards an agile process, retrospectives are sure to empower your team identify and correct the issues that are plaguing them.