Agile Software Development Practices - Retrospectives

Agile Software Development Practices - Retrospectives

Recently I've been involved in teams that have been experimenting with different flavors and ideas on how to best execute retrospectives in Agile Projects. These sessions (sometimes called after-action reviews) focus on improving several aspects on your Agile projects, from team cohesion and morale to the process itself.

I wanted to share these experiences with the community and get your feedback and also hear about different experiences/methods of performing continuous improvement on the Agile process.

The approach we have been experimenting with is based on the excellent work by Esther Derby on the book Agile Retrospectives - Making Good Teams Great. I highly recommend the book if your just starting out on this practice since it is very "down to earth" and full with helpful advice to make retrospectives a fun and interesting exercise.

In our adapted version of Esther's approach, a facilitator (from inside the team) guides the 5-step process that consists of:

1 - Two word "check-in" - every team member reports about his/her state of mind. The objective is not only to get everyone in an introspection mood but more importantly to guarantee that everyone talks in the beginning thus “breaking the ice” for team members that are less extrovert. The rule here is that this needs to be done by pronouncing two words only.
2 - Sprint Timeline review - a sprint timeline is built where each team member comments on specific actions/attitudes by other team members. Each team member is also invited to highlight events that were either positive or negative to the sprint. This is the bulk of the session and should be facilitated carefully. It is important that the team has enough cohesion to provide true, meaningful feedback without turning the activity into a "blame fest"
3 - Insight generation - taking in consideration the sprint timeline, the team is broken down into small groups that generate insights on things that could be done to improve the overall team experience or the Agile process. It is important that insights are measurable and tangible so that the effectiveness can be properly measured. Insight generation is a very creative part of the process and it is important that all inputs are captured correctly and recorded for later review. These insights can also be added into a backlog that gets carried over multiple sessions.
4 - Insight selection - From the list of insights that were generated, the team will now select 2 based on a equal vote mechanism (everyone can vote for two insights). These insights will be implemented and measured for effectiveness on the next sprint.
5 - Check-out - every team member revisits the two word check-in and executes a two word check-out.

We have been experimenting with this for a while now and the results are promising, although so far we have failed to have the full team committed to the practice. I think that part of this lack of engagement also stems from the fact that we went down the path of using the retrospective as a team building/cohesion tool and therefore there is a lot of healthy confrontation between team members which in my opinion leads to better working relationships. Some of the people I've talked about tend to focus more on process improvement and less on inter-personal relationships.

What about you? Do you:
- perform any kind of retrospectives as part of your Agile software development process?
- regularly execute them (every sprint) or only at the end of the project (post-mortem)?
- use retrospectives as a team bulding tool or a process enhancement opportunity?
- use a different approach?
- utilize these reviews as a performance review mechanism for your team?
- have any tips on running a successful Agile retrospective?

I would like to thank Pedro Queiros for the enormous contribution of lining up the methodology and really being a champion of this practice inside our teams.

Thanks in advance for the replies and contributions!