Timing and three types of Retrospectives

I was told the following story this week by one of my clients. He works for a large organization with many software development groups. The company believes retrospectives are a good thing and some people in the company, including my client, are trained in facilitation.

A few weeks before Christmas my client got a call from another group lead in the company who asked if he could facilitate a retrospective. “Sure” said my client who went to discuss it with the group lead.

Now it turns out that this group has not been holding regular (iteration) retrospectives during the project so this was to be the end of project retrospective. But the project had slipped a couple of months so wouldn’t ship until February. “Arh” says my client, “wouldn’t it make sense to hold this retrospective then?”

“Yes” says the group lead, “but, one of my objectives for the year is to hold a project retrospective so we need to do it this side of Christmas”. This company operates management by objective and the group lead had this objectives and his manager didn’t want to vary the objectives so an “almost done” retrospective it would be.

There are two schools of thought on when to hold a retrospective and this case was neither of them. The first school, exemplified by Norm Kerth in Retrospectives is the Big End of Project Retrospective (BEPR). The problem with this type of retrospective is that it occurs too late to make a difference to a project. Only if the same people will be working on something similar sometime soon is there a lot of benefit to the participants.

Still the BEPR is a good way of getting started with retrospectives. If you’ve never held one before there is a lot of ground to cover. I find them useful when I’m getting started with a team as a first step towards regular retrospectives and to help loosen the team up. It doesn’t necessarily have to be at the end of a project but to have value it needs to be held in time to make a difference. Do it in “stoppage time” probably makes little difference.

The second school of thought is exemplified in Diana Larsen and Esther Derby’s book Agile Retrospectives is the Regular Iteration Retrospective (RIR). I recently came across Joshua Kerievsky’s “How To Run An Iteration Retrospective” which is a good one page guide to this type of retrospective.

These are smaller, shorter, retrospectives that occur on a regular basis. Typically these are held at the end of an iteration so anything between 1 week and 4 weeks. By occurring regularly such retrospectives can make a difference while work is in progress. There are two problems here, the first is confusion and the second freshness, let me explain.

Simply, people get confused about what is a retrospective at the end of an iteration and what is not. This isn’t helped when you occasionally skip a retrospective.

I’ve been known to skip retrospectives, typically when the team is still settling and I can see changes occurring organically. In these cases I prefer to leave things to improve by themselves.

I’ve also skipped them when I feel that they will sap morale. I recently worked with a large client where I was coaching several teams. It quickly become apparent that the problems the teams were facing were systematic and beyond the teams ability to fix. What was needed was structural change across the organization. This wasn’t going to happen any time soon but until it did asking the teams to reflect on the problems they faced would only revisit the same old ground.

At the end of an iteration there are three types end of reflection to my mind:
• Review: this happens at the end of every iteration. Look at the work done, count the points (if using), talk about what was done and problems encountered. This needs to happen to close the iteration. Not really a retrospective but sometimes its seen as one.
• Informal retrospective: as part of the review or immediately afterwards. A discussion of what has happened, what could be useful and how the team might change. Informal retrospectives are useful when there is not the time for a formal one (they flow naturally after a review), when the team are still settling in or when the team are recovering from a lot of micro-management and learned dependency.
• Formal retrospectives: a formal period of time for reflection with some exercises to facilitate thinking. This format also allows you to keep track of what action was decided on and follow up changes. Ultimately all teams should be aiming for this type of retrospective.

The second problem with RIR’s is freshness and mainly the formal retrospectives. If you are holding these every second week and doing the same exercises they quickly become boring. The trick is to vary the exercises and try new things. Again this is one reason why I’m happy to use informal retrospectives, more variety.

I’ve recently had success using dialogue sheets as a facilitation tool in formal retrospectives. I’ll post my template online soon and blog about it in more detail.

One of the big difference between BEPR and RIR is the timeline. In a BEPR the creation of a timeline is normally a (even the) major event. The team map out what took place and when it happened, and then reflect on it. If you are holding RIR then creating a timeline for, say, 2 weeks then it doesn’t get you very far. Hence the need for more activities to trigger reflection.

As you might have gathered from above, RIR are in many places displacing BEPR as teams move to more Agile development. Generally this is a good thing but I suspect the BEPR is due a comeback and I think the force for this will be the Kanban development process.

Two factors make RIR less suitable to Kanban. Firstly the most advanced Kanban teams don’t bother with iterations. The pull system renders them less necessary, therefore the natural place to hold an RIR disappears.

Second, drawing from Lean, Kanban teams may well adopt a “Stop the line” mentality. That is, if the team see a problem the immediately address it rather than waiting for the retrospective to come along.

Yet I still think there is are occasions when it is worth the team stopping and actively taking time to reflect. In Lean we might think of this as a Kaizen or Kaikaku event. At such time a BEPR retrospective might be exactly right. Still, schedule them every quarter. Make them frequent enough to make a difference and avoid the problems my client had.