Esther Derby 
and Diana Larsen gave a presentation at Google Tech Talk about agile retrospectives. They explained how retrospectives are tied to the agile practices of inspect and adapt. It fits into the feedback cycle, looking at what you are doing, see if it is working or whether you need to do some changes and try things in a different way. Retrospectives address effectiveness of methods, engineering practices and team work.They then describe 5 steps of retrospectives:
1. Set the stage: get everybody’s head in the game.
2. Gather data: what happened and how we responded.
3. Generate insights: make meaning of the data.
4. Decide what to do: same, differently, or try new things.
5. Close the retrospective.
Retrospectives are ongoing and a linked process that flows naturally at the end of each iteration and into the planning part of next iteration. People think that they don’t have time for all of this, but these 5 stages can be done in about an hour. They recommend that you don’t skip these stages as you might compromise the results.Next they cover each stage in details:
1. Set the stage: Specify a goal on what we are going to look at and an agreement on how we will work together.
- a. Have a goal like let’s look at what’s working and what’s not working. This is good to start out with, but after a while it becomes boring. So then set a new goal like let’s look at how well we are applying coding standards, refactoring, xp practices, etc…
- b. Set a working agreement: Inquiry rather than advocacy, Dialogue rather than debate, Conversation rather than argument, Understanding rather than defending
2. Gather Data: Think together as a group and look back over the iteration. Create a timeline and put up events that are important. Try to have a common understanding of the what went on and get a fuller picture of what happened. Also add an emotional graph tracking energy (high, medium, low) along with the events (avoid using the word ‘feeling’).
