Learning Done Right: The Agile Retrospective

By Angus Frame

Pop quiz: Which of the scenarios below led to meaningful, positive change?

Scenario A: After a rushed, challenging product launch and four months of firefighting, bug fixing and finger pointing, an independent consultant is recruited to conduct confidential 1-on-1 interviews with all the senior individuals involved in the project and to then write a lengthy report for the CEO on lessons learned.

Scenario B: Finding themselves mired in a “death-march” project, a cross-functional team of managers, engineers and designers directly involved in the initiative decide to meet every two weeks to reflect on progress and setbacks and make clear commitments on necessary and immediate improvements.

If you guessed Scenario B, congratulations. Nailed it. Gold star.

Scenario B describes an empowered, motivated team deciding that a situation needs to improve and finding a way to methodically make the changes they all agree are the most important. This is what advocates of agile software development call “retrospectives.”

The retrospective is, in my opinion, the most important part of agile and a practice that can be applied to all professional disciplines to accelerate learning and improvement. Simply described, a retrospective is a recurring meeting that allows a group of people with a shared purpose to openly discuss what is working well, what needs to be improved and to then make clear, time-boxed commitments to address the most pressing issues. It is incredibly powerful.

(Important distinction: A retrospective is not a “post-mortem” in which a project team gets together when something is finished to identify lessons learned. I’ve been to a lot of post mortems and more often than not they devolve into a blame party and the so-called lessons learned are inevitably repeated.)

A few conditions must be in place for retrospectives to be effective:

1. Full Participation. All members of “the team” (however team is defined) must attend and actively participate in the retrospective. It cannot be a top-down exercise, nor can it exclude the senior team members.
2. Open Culture. All participants must truly believe that everybody involved is equally committed to success and that the desire to improve is universal. The process will fail if participants feel insecure or do not trust others on the team.
3. Commitments, take-aways and action items. Each retrospective needs to end with a clear commitment from the team to focus on improving one or two specific things before the next retro. And then these commitments should be discussed as a key topic during the team’s planning sessions.
4. Regularity. A retrospective cannot be a one-off event. It needs to happen with clock-like regularity. This allows trust to build and the benefits of the retrospectives to become apparent.

I have facilitated and participated in countless retrospectives and one of the surprising dangers is the temptation to cancel the retros when things are going well. This is exactly wrong. When a team is in a groove, you really want to understand what is working and monitor things carefully to make sure a high-functioning team doesn’t stray. This can mean finding fresh approaches to the retrospective to prevent any boredom from setting in. Some of my favourite techniques for running interesting retros and keeping them engaging for long periods of time are:

1. The Plus/Delta Retrospective. This is my go-to retro, and it is an excellent way to make sure that every voice in the room is heard, including the introverts. Depending on team size, this retro will take between 30 minutes and an hour. The facilitator begins by distributing index cards and asking everyone to quietly write down two things that went well since the last retro; the facilitator then reads all the cards and the team identifies themes and captures them — you want to know what is going well so it can be protected. The facilitator then asks everyone to write down two things that could be improved; reads all the cards and leads a discussion around themes. The team then identifies two specific things that need to improve and commits to making the necessary improvements before the next retro. This is a simple approach and the use of index cards guarantees that everyone involved will express their own thoughts and the danger of a few dominant voices driving the conversation is mitigated. But the real value lies in the discussion and in the team’s ability to make solid commitments around what needs improving. Simply recording the good and the bad is not enough.
2. The Timeline. This is a good retro for teams that have note gathered to reflect on their work for a while. It can take some time, but it can also be powerful. The facilitator begins by asking everyone involved to remember what was accomplished in a given period of time (a month, a quarter, a year). Once the accomplishments are captured, the facilitator invites everyone to draw a picture of a face to show how they felt at each point in the timeline. This then creates a nice visual showing the work that was done and how everyone felt at the time. From here, it is a natural step to identify the times when morale was low and identify ways to make improvements in the future.
3. Mad, Sad, Glad. This is a popular technique here at TribalScale that I like because it allows a team to cover a lot of territory very quickly. It begins by handing post-it notes to all participants and instructing everyone to write down what about the most recent iteration made them sad, glad or mad. After about 10 minutes, everybody places their notes in the appropriate category and then the facilitator helps group them into themes. Once the feedback is grouped, everybody gets a chance to vote on the items they consider most significant (dot voting is a pretty effective tool at this point).With a clear view of the items deemed most critical, the team can have a productive discussion about what needs to happen next to improve how things are going. As with all retros, it is the discussion and commitments to improvements that matter the most.

TribalScale is committed to the continuous improvement and learning driven by retrospectives. So we have a lot of them. The engineering team, the sales group, the founders and all the client projects use retrospectives to get better. And the result? Every week, improvements are made.

That said, you don’t have to employ retros. You could always try out the process described in Scenario A and see how that works out…