Retrospectives are a great way for agile teams to learn and improve themselves. Many projects have multiple teams who work on the same product. Each team can of course do their own retrospectives. But are there additional things that agile projects can do to improve collaboration between teams, and increase their contributions in the project? Doing retrospectives of retrospectives (RoR) is a way to share learnings across a project, and to solve problems that a project is facing.
This is another retrospective technique that is included in the agile retrospectives book that Luis Gonçalves and I wrote: Getting Value out of Agile Retrospectives.
Why do a Retrospective of Retrospective?
Doing retrospectives of retrospectives is a way to share learnings across a project. To improve collaboration between teams, and increase their contributions in the project.
Since product owners often work with multiple teams, RoR can be used to align the way of working. That can make things easier for them, and for the teams.
A project manager will often participate in a RoR, as it helps him/her to manage his project with agile teams. Managing agile projects is different, and a RoR helps to stimulate collaboration and self-organizing of teams.
As an RoR improves collaboration within the project, it can be a great way to handle risks and improve product quality. And increase the chance that the project delivers valuable functionality, quickly.
Corporate-wide improvement programs often fail, where retrospective have shown to provide continuous improvement on the workfloor. RoR enhances this by making it possible for teams to learn from other teams. And teams can team up, where they see commonality. The sum is greater than the individual parts.
This blog post talk about doing RoR in a project. But you can also do it in a department, or for the complete organization. Wherever you have teams that have to collaborate to make things work, regularly doing a RoR can help you to remove barriers and keep things going.
How can you do retrospectives of retrospectives?
In a retrospective of retrospectives, members from different teams gather. They discuss the reflections from their team’s retrospectives, and the actions that they have taken. Together they can decide on
- Additional actions that are needed
- Reprioritization of the team’s actions
- How to work together doing the team actions
- Improvements to the team’s actions
A RoR can be done in several ways. You can define the topics to be discussed up front, which makes it easier for participants to prepare. But you also have the participants suggest topics at the beginning of the RoR, and do a voting and prioritization. Or use open space technology to have people gather themselves on topics that they consider important. Or turn it into a storytelling event where people share stories on how they experienced the project and what they learned.
A RoR is somewhat similar to a Scrum of Scrums. That is where scrum masters come together to discuss their progress, next steps, and any issues that they are facing. Usually, the scrum masters participate in a Scrum of Scrums, and that is one of the things where it differs from RoR. Basically, any team member who has been in the teams retrospective can attend the RoR. Where it could be a team member who will be driving a teams improvement that joins the RoR. Or another designer or tester, depending on the issues up to be discussed. A team member that has change management skills. Also it doesn’t have to be the same team member in every RoR, where in a Scrum of Scrums that is often better. The purpose of the RoR is also different, it doesn’t focus on what should be done, but on how to do it. The focus is on the people, the process, the way the work is done.
When would you do a retrospective of retrospectives?
My recommendation is to do a retrospective of retrospectives after every (major) delivery. For most projects that would be ones every 3-6 sprints, which means roughly every quarter year. The idea is to do it when you have something that is worthwhile to look at, which is what has happened on the way to the last delivery. And you also have a goal for the RoR: What do we need to do to make the next delivery work?
The success of major deliveries depends on:
- Teams working effectively together
- Alignment between the backlogs of teams
- Teams having a shared view of what is important to make the project successful
RoR help members of the teams to focus on this. To see what went wrong, and could be improved. And to define effective actions for the coming sprints that lead up to the next delivery.
You can also do a RoR at the start of a project. At that time it is important to make some first decisions how the project will be organized, and how teams will work together. Another time to do it would be when a project is facing major or repeating problems, that have to do with the way that teams work together. You can get to the root causes of problems in a retrospective, which helps the teams to define effective actions to getting the problems solved.
The teams take action
What comes out of the retrospective of retrospectives will go back to the team. Because it’s the people in the different teams that are doing the actions. By changing the way that they do their work (their process). And it is up to the teams themselves to follow up on their actions. A RoR is not an additional hierarchy on teams, it is a practice that helps teams to align their improvement journey with other teams. To travel together where that makes sense, to find new directions that lead toward their destiny, and to not go into directions that would be a waste of time. Retrospectives give power to the team!
What about team confidentially you might ask? Teams may have discussed issues in their retrospective that are private to the team. Which involve individual team members. Is that something that is shared in a RoR? Normally not, the basic rule that I apply is “what happens in the team, stays in the team”. Does that mean that you cannot discuss it in a RoR? Unless you can go it anonymously, without hurting individual team members or the team, you cannot. But similar to the trust that is there in a team, there should also be a level of trust in the project. Where you can discuss things and assume that they will not be misused by the participants.
Examples of large-scale retrospectives
There are some inspiring stories on large-scale retrospectives that I can recommend:
- Using Large Agile Retrospectives to Improve Projects on InfoQ
- Retrospectives of Retrospectives by Deborah Hartmann Preuss
- The Artifacts Contest exercise from the book Project Retrospectives by Norm Kerth
- Bubble up exercise from the Agile Retrospective Resource Wiki
- Huge retrospectives with online games on InfoQ
- Large Scale Retrospectives at Spotify
- Overall Retrospectives in LeSS
- Running a retrospective with large teams
- (more to follow)
Have you done retrospectives in your project with multiple teams? Used Open Space Technology to share learnings in projects? I like to hear from you!
Note: This post was updated on February 1 2016 and March 20 2017 and Januari 9 2018 : Examples added for how to do retrospectives of retrospectives.
This Post Has 11 Comments
Great post. When I did a series of retrospectives, it showed that always the same issues arose with particular parts of our process. So I gathered all people responsible for that part in some kind of meta retrospective, solely about that one topic, which resulted in a specific set of actions we could implement. It’s not the same as the RoR, but it’s also a retrospective based on the outcomes from other retrospectives. You could call it a boutique retrospective on one specific topic. Pretty similar to the idea of guilds Henrik Kniberg uses when scaling agile at Spotify.
Bart, that’s a great way to do a focused retrospective that brings value! I think this also has some similarities with ToC, work on the biggest constraint first and solve it.
One of the values that retrospectives brings to organizations is actions by the team, for the team. The team decides what to do, and does it. If the team considers 1 topic to be important enough to work on and get that out of the way, then they can do it.
In your article, you asked about using technology to facilitate more effective retrospectives.
Love to hear what you think about this http://www.groupmap.com/agile-retrospectives/
Jeremy, GroupMap looks to be a tool to collect data, and define and vote on actions. For a questions based retrospective that can certainly be useful.
How would you use it in a Retrospective of Retrospective, to facilitate learning across teams and increase collaboration?
You could go metacognitive with retrospectives or retrospectives… maybe we can set one up just this site. asking people what the think!
You could perhaps set up a map that asks people how else they would like to run retrospectives in the future.
Generally speaking, most people use it for their standard exercises, but with the ability to change the questions, invite people remotely, or to get honest answers in real time.
Indeed Jeremy, and I love to hear from people how they do retrospectives and the benefits they get from doing retrospectives! There is a Q&A on retrospectives which people can use to ask questions or share their experiences, and of course they can comment on the blog posts as you did 🙂
My suggestion to teams and facilitators is to use different retrospective exercises. You can vary the questions and setup, but there are a lot more exercises that you can do. Ever tried a Root Cause Analysis in a retro or done a Constellation or Value Stream Mapping? Why not give it a try!
Hi Ben, thank you for this great post! I’ve translated it into french :
Améliorer la collaboration dans les projets agiles avec la Rétrospective des Rétrospectives
merci pour la traduction Fabrice! Trouver plus d’exercices à Tirer profit des rétrospectives agiles.