Firstly let me say that holding Sprint Retrospectives should be considered mandatory in the Scrum process in your organisation. Obviously their goal is to allow the team to look at what went well in a sprint and what didn't. But they are often overlooked, rushed and not given due time and attention. Another aspect of Sprint Retrospectives we must be careful of is, that they do not de-generate into a finger pointing and moaning exercise. Retrospectives that spiral into this pit of doom, are often a result of a poorly structured meeting, probably caused by opening with "What worked in the sprint and what didn't?" One of the best ways to avoid this is to apply structure and proven techniques which help gather sensible data about the sprint and help generate insight into improvement and success.

The following outlines how I hold Retrospectives and is taken from various sources. Please see references at the end of this post. Its important to note that I did not invent this process, I simply use it in a slightly modified form.

Retrospective Format:

The retrospective can be broken into 6 components as follows:

1. Introduction, presentation of the agenda and setting the goal of the retrospective
2. Review the previous retrospectives actions and assess if they were instigated and whether they were of benefit.
3. Gather Data - Energy seismographs / timelines
4. Generate insight – look at the timeline and identify why things went wrong, why people were motivated etc – mine the charts
5. Decide what to do – based on the insights, produce action plans to go forward into the next sprint.
6. Close the retrospective – retrospective the retrospective, conclude and thank attendees etc.

1. Introduction and setting the stage

This is the “opener” to the meeting and is designed to outline the retrospective format, set ground rules and agree on a retrospective goal

The agenda is outlined as above.

Agree on the ground rules that help dialogue and conversation and prevent arguments:

• Inquiry rather than Advocacy
• Dialogue rather than debate
• Conversation rather than argument
• Understanding rather than defending

Set the goal for the retrospective. A usual goal for a retrospective is “Increase productivity, faster deployments and more robust code” etc etc

2. Review previous retrospective action plans

its important that this step is completed to ensure that retrospectives outputs are being fed back and instigated in the following sprints. Holding retrospectives and failing to implement the agreed actions is a futile exercise.

3. Gather data

Draw an “Energy seismograph”, this is simply plotting the sprint timeline along the X axis, and Energy in the Y axis. For each team member, get them to draw their energy levels on the time line. This will help identify possible hidden items that people haven’t bought up and will help detail areas where an individual suffered or the team were suffering as a whole. Remember that each person has a unique view on what happened during the sprint and drawing their energy levels through the sprint and talking about the peaks and troughs will help identify points for discussion, such as when a spec was changed, when a fault was found, when a breakthrough was made.

Gathering data in this fashion forms a group agreement on what actually happened on a factual basis and provides a shared view on the sprint as a whole.

Energy seismograph

4. Generate insight

Esther and Diana detail this step as a follow up to gathering data. During my retrospectives, I like to mine each persons Energy seismograph as we go, milking all the information up front. Once the team have completed the graphs, you can discuss the whole picture and mine the data further, asking more generalised questions possibly in relation to actions from the previous sprint and whether they helped the process.

My output from steps 3 and 4 is a learning matrix, an area of paper, whiteboard, divided into quadrants: Positive, Negative, Ideas, Appreciations.

5. Decide what to do

Take your negatives and ideas developed in steps 3 and 4 and produce action plans to implement and or maintain these. Its is important that the whole team agree to the actions generated.

If needs be, actions should be assigned to a team member or chicken. To help prevent vague actions being created such as “improve communication” break the action down into 2 sub-components, a long term action and an action for the next sprint e.g.

Long term action: Improve communications

Now action: Invite other people as chickens to the scrum

6. Close the retrospective

Closing a meeting is always a recommended practice to help solidify what has been discussed and agreed and to provide closure. I summarize the following points:

• What has been achieved in the retrospective
• Thank everyone for coming and any special appreciations as required.
• Ensure anyone tasked with follow up actions are aware of this.
• Perform a quick Return On Time Invested (ROTI) poll.

ROTI's

I use the following scale to gauge peoples opinion on the retrospective:

1 – Useless – I gained nothing from the meeting 2 – It was useful but it wasn’t worth 100% of the time spent on it 3 – Average I gained enough to justify the time spent in the meeting 4 – Above average, I gained more than the time spent on the meeting 5 – Excellent, A really useful meeting that benefits the team and myself and worth more than the time spent on it.

Record each persons vote and be happy if everyone voted 3 or above. Remember a vote of 3 is fine, no one has wasted their time. Should you receive a number of genuine votes under 3 then something is going wrong with the retrospective(s). They could be going on longer than people like, maybe the actions plans are not be instigated from previous sprints, leading people to have a "why bother?" attitude.

Conclusions

Holding retrospectives provides invaluable feedback on the Scrum Sprints. They empower agility in the development process and will always provide valuable gains in team satisfaction and/or productivity.
There are numerous other techniques that can be used to gain insight into a sprint, but I generally follow this format. I try to keep retrospectives to around 1-1.5 hours, and always provide doughnuts, developers always like doughnuts (it has nothing to do with the sugar rush keeping us all awake honest!)

Please feel free to comment on your retrospectives here, I'd love to hear of any success stories you have had and i'll do my best to help suggest options for those that are struggling.

References and Credit

http://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649 by Esther Derby, Diana Larsen and Ken Schwaber

Google Tech Talks also have Esther and Diana in a 51min video about the subject here...