Finding the right retrospective rhythm

What’s the appropriate frequency for conducting retrospectives? If you follow the Scrum methodology or a hybrid of it, you’ll likely say at the end of every sprint, once the sprint review, showcase or demo has taken place.

For teams which are learning to be agile, that is the right answer. It takes a few sprints for a new team to develop the mutual trust and psychological safety required to have a productive retrospective. In those early sprints, there might be a reluctance to identify problems for fear of offending team members, a tendency to identify symptoms rather than real issues or to generate a long list of “did wells” and “do betters”. Team velocity has also not stabilized and hence there is ample opportunity to increase it through incremental improvement on each sprint.

But what happens once a team has worked together for many sprints?

Answering the same questions sprint-over-sprint gets old really fast. To try to resolve this, the agile community has been very creative at coming up with alternate methods of eliciting valuable input using materials such as Lego bricks or Play-Doh. But while such variety might make for a fun team activity and should reduce the potential for team member disengagement, will repeating this ceremony every sprint always generate value? And if it doesn’t, why are we doing it?

On projects where the team has gelled and their delivery process is in control, there is often a natural transition from team level continuous improvement to team members practicing personal kaizen.

But this shouldn’t mean that we stop doing retrospectives. To do so would be to repeat that mistake of traditional lessons learned practices of identifying them too late in the lifecycle to provide much value to the originating project. For teams which are delivering change every few sprints, a release might provide a good opportunity to hold a productive retrospective, but that might still not be often enough.

Team self-awareness needs to be at a relatively high level so that an individual team member can identify the benefit of conducting a retrospective, but to help bring some consistency to the process, the team could proactively define trigger events. Examples of such triggers could include velocity falling outside of the team’s expectations, quality dramatically improving or dropping, unexpected feedback or outcomes from a sprint review, or the departure or arrival of a team member.

So what is the right retrospective rhythm?

Just in time to generate value for subsequent delivery efforts.