Tips to Improve Retrospectives

Posted by Mark Levison on Dec 17, 2008

Sections

Process & Practices

Topics

Agile Techniques ,

Change ,

Agile

Tags

Productivity ,

Retrospectives ,

Continuous Improvement

Esther Derby, co-author of "Agile Retrospectives: Making Good Teams Great", has recently written about techniques to improve retrospectives:

1. Let the Group Members do the Work - standing at the front of the room and doing all the writing discourages team members from taking ownership of ideas. Instead have them write on large PostIt notes (using big dark markers) - it keeps everyone involved and encourages even the quietest person to provide something.
2. Record Faithfully - a facilitator (or ScrumMaster) is there to capture the group's ideas and not filter or inject their own.
3. Use Parallel Processing - when there are more than one or two problem areas to discuss, break into groups of two or three and do a root cause analysis. Along with speeding things up this reduces the influence of one or two noisy voices on the team.
4. Let the Group Members Draw Conclusions - occasionally facilitator (or ScrumMaster) will look at the raw data generated by the team and announce what they're conclusions are without allowing the team to do its own work. Effectively the facilitator is saying that they don't value the input of the team. While it can take longer for the team to analyze the data themselves, they then draw better conclusions and take ownership of the resulting action items.
5. Test for Agreement - after a short period of discussion it is useful to test to see if the team has reach a basic agreement (not always the final decision, sometimes just a way point). A decision should be proposed and once everyone has asked clarifying questions, we test using the "Fist of Five". With this technique the number of fingers indicates the degree of support: Five - I wish I had this idea myself and will help lead the change; Three - I can live with the will of the group; One - there are still issues I need to discuss; Fist - no vote, I wish to block consensus and force more discussion.

George Dinwiddie suggests taking the actions from the retrospective, writing them on story cards and putting them in the product backlog. This keeps them visible and makes it more likely that they will get done. In addition, he suggests that sometimes you shouldn't tackle the biggest or most important problem - these can be daunting. Instead have the team pick a task that they have the energy to tackle.

Jo Geske proposed:

Instead of putting sticky notes with significant events on a rather abstract timeline representing the Sprint we put them directly on the respective Sprint burndown chart.

Advantages:

• Encourages thinking (why was the burndown high/low on that day?)
• Helps concentrating on events relevant for the Sprint and team
• Helps illustrating correlation between cause and effect

Mike Sutton takes it one step further: "you could extend the burndown chart as a diary of the sprint, capturing not only the tasks burndown, but impediments (as above) and key events that will enable you to better retrospect." Mike goes on to illustrate this with a team that had trouble tracking impediments and remembering the problems they encountered by the time the retrospective happened.

One approach Mike has used:  Stickies are posted for impediments and included the date, the reason and other hints/context. When the problem was resolved, an additional notation was made on the sticky.

In addition to helping the retrospective, Mike has found that this approach can help focus on the daily Scrum by maintaining a balanced urgency.

Ilja Preuss says that this is definitely an interesting idea but it is likely to focus the retrospective on things related to the burndown chart so he would ensure that other techniques were used to raise more subtle problems and also the good things from sprint. Finally, he varies his retrospective format over time so that teams don't get stuck in a rut.

• Older >