I’ve worked on two different teams this year which had quite different approaches to retrospectives.

In the first team we had a retrospective at the beginning of every iteration i.e. once every two weeks and in the second team we tried out the idea of having a rolling retrospective i.e. we put up potential retrospective items on the wall and when there were enough of those we discussed them in the standup.

The problem we had with the first approach was that we often had the same types of discussions in each retrospective and the same types of issues were raised each week so that it seemed almost pointless to even have it in the first place.

Several people ended up disliking the idea of even doing a retrospective in the first place because of this.

We came up with the idea of having a vote at the beginning of the iteration to decide whether or not we should have one with the idea being that if it didn’t seem necessary then we could skip it for one week but would definitely then have the next one.

I think this worked reasonably well although it’s slightly different to the approach taken by Rolf Knutsen which he discussed at XP2010 in his session on 'Feedback and Retrospectives in Agile Projects'.

Rolf suggested that we should have a retrospective at a given time interval and just cut it short if we don’t have anything else to discuss.

I think I prefer Rolf’s suggestion as it’s too easy to come to the conclusion that we don’t need a retrospective especially if we think that they’re a waste of time.

I thought the rolling retrospective approach that we took on the second project would work much better as we could just address any problems as soon as they came up but it hasn’t worked quite that way from my experience.

Several issues which would normally be addressed in a retrospective seemed to go by unchecked and without being resolved.

Having a retrospective is a very useful way to put people in a reflective mindset where they look for things that aren’t being done well or that could be done differently whereas during the day we might not do that.

I hadn’t appreciated this benefit of a retrospective session and had felt that problems were often being saved up for a retrospective even if they could have been addressed earlier.

Fabio previously wrote about the idea of the future retrospective box to ensure that we don’t forget anything that happened early on in an iteration when we come to a retrospective but that still doesn’t address the problem of only addressing problems in the retrospective!

It seems like a combination of having a pre scheduled retrospective with problem solving on a day to day basis is what we need so I’d be interested to know how others have addressed this.