Agile Retrospectives: Making Good Teams Great

by Esther Derby

Fearless Change: Patterns for Introducing New Ideas

Here’s an example of why you need working agreements at the start of the retrospective: Fran’s cell phone starts ringing just as the group broaches a sensitive topic. At this point, it’s awkward to say, “Don’t answer that phone!” And it feels capricious to people when they learn what the rules are only after they’ve been broken. If your team has a working agreement that says “Mobile phones on silent during meetings,” it’s less disruptive to point to the agreement and end the interruption. It also feels more fair to the people in the retrospective. The last thing you want is to look like a petty tyrant when you are leading a retrospective.

Inexperienced retrospective leaders like to skip setting the stage and plow ahead into the “meat” of a retrospective. We never regret spending time setting the stage—and neither should you. “Saving” time by skipping this part costs time later. When people don’t speak early, they may not contribute at all—and may not buy into the team’s insights and decisions. When they don’t know the approach, people have trouble focusing and may take the group on a tangent. Team values and working agreements help keep the conversations and interactions productive.

When your team looks back more than a week or two, create a visual record using a timeline or data charts. A visual depiction of data and events makes it easier for people to see patterns and make connections.

Rather than ask directly how people feel, try asking the question a different way: When were you excited to come to work? When was coming to work “just a job”? When did you dread coming to work? What were the high points? What were the low points? How was it to be on this iteration? When were you [fill in an emotion word—mad, sad, surprised...]?

Holding your retrospective right before iteration planning is ideal. Plan a break—even if it’s only lunch—between the retrospective and the planning session.

The learnings belong to the team, and team members: not the coach, not the team lead, and not you as the retrospective leader. The team needs to own them.

When you talk to people on the team, find out about topics such as these: What did this iteration produce? What was the team aiming for? How did the result meet (or not meet) expectations? What is the history of previous project reviews? What happened, and what was the follow-up? What’s going on elsewhere in the organization that affects the team as they go into the retrospective? For example, are there rumors of layoffs? Has there been a recent merger? A canceled product? What are the relationships between team members—how is their work interdependent? What are their personal connections and working relationships? What are team members feeling? What are their concerns or anxieties? What are they excited about? What kind of outcome will achieve value for the time invested—both for the retrospective sponsor and the team? How has the team worked with facilitators before?

Useful goals for retrospectives include the following: Find ways to improve our practices. Discover what we were doing well. Understand reasons behind missed targets. Find ways to improve our responsiveness to customers. Rebuild damaged relationships.

Take breaks when there is a logical stopping point, when energy drops, or when people express a need. For retrospectives longer than two hours, build time for breaks into the schedule. Count on a ten-minute (minimum) break every ninety minutes or so.

Most of us have had the experience of driving or walking a familiar route and arriving at our destination without noticing anything along the way. The same process can happen when teams always meet in the same room. Moving to a different room can help people notice different things.

Tables can be a physical barrier that becomes a psychological barrier. Avoid rooms with an immovable conference table in the middle. That big ol’ table will inhibit creative collaboration. This isn’t a board meeting, after all.

Retrospective leaders focus on the process and structure of the retrospective. They attend to the needs and dynamics of the group and help the group reach a goal. Retrospective leaders remain neutral in discussions, even when they have strong opinions.

Beware: some participants believe that once they’ve written the issue down or mentioned it in a conversation, it’s no longer their job to bring it up. Make it clear that issues belong to the people who have them, and you are relying on them to raise topics in the retrospective.

In an iteration retrospective, the team takes action on issues that are within their control. But releases usually involve people from other teams and departments. The problems identified often cross organizational boundaries—they’re system problems.

If you’ve ever tried to change a personal habit (nail biting, for example) you know that it’s virtually impossible unless you have something else to replace the old behavior. It’s easier to add a new behavior than extinguish an old one. The same is true for teams and organizations.