Improving Collaboration in Agile Projects with the Retrospective of Retrospectives

populationNews: Getting Value out of Agile Retrospectives now available in print! Order your copy on Lulu or Amazon!

Retrospectives are a great way for agile team 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 an 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 will be included in the agile retrospectives pocket book that Luis Gonçalves and I are writing. The book that helps you to get value out of agile retrospectives. We love to hear from you, to make this a great book!

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 then 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 teams retrospectives, and the actions that they have taken. Together they can decide on

  • Additional actions that are needed
  • Reprioritization of the teams actions
  • How to work together doing the team actions
  • Improvements to the teams 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.

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 a 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 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. 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 help 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 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 recommended:

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!

(Visited 1,165 times, 1 visits today)
Tags: , , , , , , , , ,

About BenLinders

I help organizations with effective software development and management practices: continuous improvement, collaboration and communication, and professional development, to deliver business value to customers. Active member of several networks on Agile, Lean and Quality, and a frequent speaker and writer.
Tagged , , , , , , , , , . Bookmark the permalink.

9 Responses to Improving Collaboration in Agile Projects with the Retrospective of Retrospectives

  1. Hi Ben
    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.
    Cheers
    Bart

    • BenLinders says:

      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.

  2. jeremy says:

    Hi Bart,
    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/

  3. Pingback: Retrospectives for Teams with Multiple Customers | Ben Linders

  4. Pingback: We Want Agile Processes | Ben Linders

  5. Pingback: The Business Value of Agile Retrospectives | Bridge Global IT Staffing

  6. Jeremy says:

    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.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>