Using Large Agile Retrospectives to Improve Projects
Retrospectives help teams to learn and improve their way of working. Can you scale retrospectives to cover larger projects or programs with multiple teams? Several agile coaches have done this, using techniques from retrospectives and open space technology. Let’s explore how they did it.
In the blog post how ro run a big retrospective, agile and lean coach Henrik Kniberg introduces a large retrospectives that he has done at Spotify:
The goal was to capture learnings from a large coordinated effort involving dozens of teams for over half a year. The teams had been doing sprint retrospectives during the project, but we also felt the need to get a larger group together and look at the big picture.
The retrospective helped Spotify to get insight in what they have learned, defined recommendation for improvement, and identified "mysteries": problems and issues that need to be identified further. Henrik describes what made this large retrospective different from a sprint retrospective:
This event was more demanding, since we had lots of people in the room and expected concrete, actionable output. Norm Kerth’s classic on Project Retrospectives provided lots of useful ideas on how to do this.
Previously, InfoQ wrote about how agile was adopted at Spotify in scaling agile at Spotify: an interview with Henkrik Kniberg. The blog post running big retrospectives at Spotify from Joakim Sunden, agile coach at Spotify, describes in detail how the large retrospective at Spotify was done. The retrospective was split into three parts: the past (reflecting on the project), the present (discussions on relevant topics) and the future (prioritize and presenting key messages).
In the past, the retrospective attendees looked at how the project had been done, and visualized the the project timeline:
Our Chief Product Officer started by giving his view on the expected project outcomes, everything from increased collaboration between different teams to actual deliverables, and project costs like frustrations, tech debt and alternative costs. He posted them on flip chart sheets and anyone could add their own ones during the day.
We had all been given a home work assignment before the retrospective to gather artifacts related to the project. (...) We used these and our insights, memories of events, feelings, challenges, and so on, written on stickies to build a timeline on sheets prepared on the wall.
Based upon the timeline they investigated how the attendants felt about the project, and how successful they found that the project has been. Sticky notes were used to collect information and make it visible to everybody.
To explore the present situation, the topics that the attendants prepared during lunch were gathered on a time matrix board, and discussed using an open space approach:
The goal for each session was to generate insights and recommendations on what to keep doing and what to do differently in the future. The topic originators were encouraged to make sure these things were captured during the sessions. If we bumped into something important that couldn’t be solved here and now, we noted that as a mystery.
The results of the open space sessions (insights, recommendations and mysteries) were presented to the group. The issues were cleaned, duplicates were removed, and the issues were clearly written so that the attendants could give dot votes to the issues:
Everyone gathered in the big room again where a human billboard presented each flip chart while someone read the notes out loud from him or her. We also had a short discussion about the few notes that had several black dots and several green dots to better understand why people had such different views on these.
This was the retrospective part that they called " the future" , where the attendants wrote down their main take-aways of the retrospectives and shared what they had learned.
In the blog post how to conduct a large retrospective, agile change agent Rob van Lanen describes how he has done a retrospective with a large group. He started with an explanation of the goals of the session, followed by an introduction:
Let everybody speak briefly and “check in”. If people speak up at the start of a meeting, chances are higher that people speak during the meeting.
The attendants organized themselves into multidisciplinary groups, and were asked to define topics that could be discussed:
In our case, I asked them to discuss and agree on a prioritized top 5 of highlights of last year, 1 per post-it.
Each group had a facilitator, who explained the topics from the group to all attendants. The topics were gathered, duplicates were removed and the a voting was done:
Ask everybody to vote privately (on a post-it) by spreading a number of votes on the items. Give them boundaries by telling them their total number of votes (and maybe even a maximum they can put on one item). I chose for private voting so there is less influencing compared to public dot voting. In the latter method, early voters can set a trend and late voters can make decisions for the group. I wanted to prevent trendsetting.
The winning topic was discussed in a fishbowl session (a technique from open space technology), and actions were defined and agreed upon:
In our case, we wanted to relive our highlight of last year. We discussed actions to reach this goal. As a facilitator, your role is to stay invisible. If people have a hard time creating actionable tasks you may want to summarize, sharpen and ask powerful questions.
A solution to do retrospectives with a larger group is a "retrospective of retrospectives". Paulo Caroli describes in his blog post the retrospective of retrospectives how this can be done. He starts by explaining the needs for retrospectives on a program level:
The teams were getting good value out of the Retrospective Agile practice. But the improvements were done in a team level. And the overall program was losing focus on continuous improvement. At times, the action point from one team’s retrospective was dependent on other teams. Other times, two team retrospective action points were contradictory.
To have retrospectives for the large program team, they introduced a technique which is similar to a scrum of scrums:
The Retrospective of Retrospectives (RoR for short) meeting is held after each individual team retrospective. The participants (representatives of all team and the program) meet to discuss what went well and what to improve in the program level. The RoR focus is on improving the overall program output, and not on individual team performance.
Some of the benefits that Paulo saw from the retrospective of retrospectives are:
Quick access to all teams – all managers and stake holders have visibility on the top items for each individual team.
Focus on improvement – for both the individual teams and the program level.
All managers (...) are periodically talking and acting on the overall goal of the program.
Any local team problem will be heard by all the teams.
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015