Retrospectives are a great way for teams to inspect and adapt their methods and teamwork, and they're a great way for teams to build on success and learn from hard times. Retrospectives take a critical look at what happened during an iteration (or part of a project) without being critical of people. But not everyone realizes that, says Esther Derby, so in this column she outlines how to approach retrospectives in the most productive way.
Not long ago, I received a call from someone who wanted to hold a retrospective. "Tell me about your goals for the retrospective," I prompted. The requestor proceeded to describe what amounted to a mini-witch hunt. If you really want to wreak havoc with a team, try having a retrospective for these reasons:
- To motivate another group to fix the way they do their work
- To make it eminently clear that Person X isn't doing his/her job-in public
- To definitively assign blame for poor design, missed deadlines, injecting bugs, and other disappointing results
- To force two individuals to solve a long standing conflict-in public
- To provide feedback on Person Y's poor performance-in public
- To prove that if those people had done better, everything would be fine
On the other hand, if you want to learn from experience, build on what works, gain perspective, and decide what to do differently, a retrospective can work for you. There are plenty of reasons in favor of well-run retrospectives, which help teams to:
- Take a "whole system" view of their methods and practices
- Discuss issues before they build up to a crisis
- Look at what's working and build on successes
- Create experiments to evolve and improve practices
- Fix what's within their own control, rather than waiting for management to take action
- Raise the visibility of impediments that managers need to work across the organization to fix
What follows is the outline of a successful retrospective.
Set the Stage
Lay the groundwork for the session by reviewing the goal and agenda. Create an environment for participation by checking in and establishing working agreements. Some people feel this preparation isn't real work, but believe me-when you skip this part of a retrospective, you may save a little time, but you'll pay for it later in the retrospective. Skip this part and people are less trusting and less likely to participate.
Gather Data
Review objective and subjective information to create a shared picture of the iteration. When the group members see the iteration from many points of view, they'll have greater insight and will be more likely to move beyond their personal views to the see the big picture of how the team works.
Generate Insights
Step back, and look at the picture the team has created. Use activities that help people think together to delve beneath the surface. When people think together from shared data, they are more likely to arrive at ideas that the whole group supports.
Decide What to Do
Prioritize the team's insights and choose a few improvements or experiments that will make a difference for the team. Be sure to identify concrete, small steps that the team can take in the next iteration—one colleague calls them "now actions." And make sure that the action steps are folded into the overall work plan, not kept to the side in an "improvement plan." When improvement is part of the regular plan, it's seen as a normal part of work, not something extra that the team will get to if they have time.
Close the Retrospective
Summarize how the team will follow up on plans and commitments. Thank people for their hard work, and do a little retrospective on the retrospective so you can improve your retrospective process, too.
This may look like a lot to cover in one meeting; but each step plays an important part, and needn't take a long time. For a two-week iteration, you can cover these steps in an hour or so. For a slightly longer project dedicate a half-day to deciding what to do better next time. For a project that lasted a year, you'll want to spend more time. Short changing your retrospective means short changing your chance to do better next time. Improvement doesn't happen by hoping; teams need to dedicate time thinking and learning.
Successful organizations know how to evolve to meet ever-changing expectations, rather than holding onto what used to work. Becoming comfortable with change, learning how to try something new, and measuring how well it works are critical business skills. And retrospectives are a great way to learn those skills on a team level.
