Sprint Retrospective for Scaled Scrum

Retrospective plays a significant role in any of the Agile frameworks. One of the Twelve Principles published with Agile Manifesto says:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

Retrospective enables the Development Team to focus on self-improvement. The basic recipe for this event is quite simple: (1) review what has happened in the last iteration, (2) plan action to improve what can be improved and preserve what if worth to be preserved, (3) try to carry on with this plan in the upcoming iteration.

Things become a bit more complicated when we are in the environment where more than one Development Team are involved (Let’s assume we have three teams or more). Why?

Too many cooks spoil the broth…

We can make Retrospective for which we invite all members of all teams. However, if we do that, we are quickly going to end up with a meeting with more then 21 people (at least 3 teams and average Development Team size is 7 +/- 2 people + Scrum Muster/Scrum Catch + Product Owner/Customer).

With so many people it is hard to make an effective Retrospective. To be honest, with so many people it is hard to have a productive meeting during which everyone speaks up – and this is one of the Retrospective’s goal.

Some things should be kept behind the closed doors…

For the sake of discussion, let’s imagine that we were able to organise one Retrospective for all of our teams, for all of our 21 people. It might happen that during this meeting we won’t be able to focus on problems significant for the particular team. And this might occurs for one of the reasons:

  • some issues won’t be raised because someone might be afraid “to wash team’s dirty laundry in public” (this is one of the reasons why Team’s Retrospective should be limited only to Development Team, Scrum Master/Scrum Catch and Product Owner/Customer)
  • some issues crucial for one team won’t be addressed appropriately, because they are not essential for others (they won’t pass voting phase)

You don’t win ware single-handed…

Therefore it might seem that we should stick with separate Retrospective for each team. We have a small group of people so everyone can speak. We have a private meeting, during which we can raise any issue as we are “a family” (or a group of good friends at least). From my observation, this is the very common approach. However, there are some downsides as well.

In multi-scrum-teams-environment, the increment is the result of the work of all team and the cooperation between those teams. If the cooperation does not work (or could work better) all teams should try to address the discovered issue. And resolve it.  Moreover, there are only limited things one team can do to bust performance. The big changes or complex changes require cooperation between the teams.

Furthermore, the data and the insides based on which we run our retrospective is limited only to the observations made by people from just this one team. Yet this is not the only team working on that project. As the old saying says – “You can see the mote in your brother’s eye but not the beam in your own” – the rest of the group might help us to point out some of our shortcoming which we are not aware of.

Two-step or three-step retrospective

But don’t be afraid. There is a silver bullet – at least something which is close enough to be called a “silver bullet”. Two- or three-step retrospective which, has been introduced in Nexus Framework and Large-Scale Scrum (LeSS) and Scaled Agile Framework (SAFe).

Nexus Sprint Retrospective is a three-step event: (1) First meeting is designed to identify shared impediments and challenges across all teams. Each team sends one team representative. This can be any person from the team, and he/she does not have to be Scrum Master. (2) Afterwards, each team hold an individual Sprint Retrospective. The expected outcomes of this part are the action for issues raised during this meeting but also for matters identified during the first part of Nexus Sprint Retrospective. (3) The final session is once again for appropriate team representatives. The goal of this part is to agree on how to visualise and track the identified action points. According to Nexus Guide during Nexus Sprint Retrospective following aspects should be verified and adequately addressed: number of work undone, technical debt, increment integration, quality and frequency of deployment.

A bit different approach is proposed in Large-Scale Scrum. Instead of three, there is a two-step Retrospective. (1) The initial phase is built from individual teams Retrospectives. In addition to “standard” Retrospective, each team should also look into broader picture and try raise challenges and impediments affecting not only this but others teams as well. (2) The second part of this two-step Retrospective is Overall Retrospective. The goal of this meeting is to discuss cross-team and cross-organisation issues. The input for this meeting are problems identified in the first part and is attended by the Product Owner, Scrum Masters, Team representatives, and managers.

Never the less. No matter which approaches to Retrospective you chose the most important things to remember are: (1) do it regularly, (2) be honest and (3) let the team decide which items will be carry on in the next interaction.