Retrospectives: “At regular intervals”… or not?

This is the first in a series of posts about how to moderate retrospectives creatively.

Traditionally the retrospective in agile software development is the reflection done at the end of the iteration. Principle twelve of the Agile Manifesto says “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly”, so regular it is: at iteration’s end we invest some time in continuous improvement and we call that retrospective.

But… is this the whole story? The Agile Manifesto writers might have had the best possible intentions, but they got the concept of continuous improvement a bit too superficially. Sure, better at the end of an iteration than never, like in most of the projects done around the world, but that is not enough.

My thesis here is that the continuous improvement process shall drive when and how retrospectives are done. This opens the gates of a new creative world where the team facilitators can use group reflection in a more useful way. To find some examples, let’s challenge the Agile Manifesto’s statement piece by piece…

“At regular intervals [when?], the team [who?] reflects on how to become more effective [what?], then tunes and adjusts its behaviour accordingly [for what?]”.

Let’s look at the first aspect: regular intervals…

“At regular intervals”… or not?

The typical place for a retrospective is at the end of the iteration. But… could it be elsewhere? Yes! For example at the end of a project cycle: let’s not review only the last iteration, but let’s have a look at a longer time frame and enjoy a broader perspective. In fact, this is what Norman Kerth’s “Project Retrospectives” are about. I’m of course not proposing to replace the iteration’s retrospective with a, say, release retrospective. I propose instead that in addition to the iterations’ reflections the team or the organisation should also have some longer term reflections. These require usually some preparation more, given the longer time span, but they are definitely worth the time invested: very often a reflection focused on an iteration give some very local results, driving the team to a local optimum. Longer term reflections provide a different and more systemic type of learning.

Another way of running reflections is when they are needed: sometimes a team gets stuck in a certain phase of the project. Typical examples are endless planning sessions, conflicts the team is not able to handle, project crises. Sure, we can wait until the end of the iteration and reflect there. Or we can reflect immediately, right after the situation has happened. In fact, this method might require a bit more facilitation in the tougher cases – keyword conflicts -, but it allows the team to reflect more productively as the information and the emotions are “fresh” and immediately available. You might not call them retrospectives, but this is what they are, in fact.

Once the team understands the value of reflecting immediately, they are likely to do it by their own and more often. In fact, this might deplete the reflection at the end of the iteration because the topics are discussed already during the iteration.

In the next few posts we will look at the other aspects in more details.