Corinna Baldauf wrote an excellent introduction to retrospectives. Start there.
Also work through Esther Derby’s primer.
Let me supplement these two introductions with a couple of points.
From Tobias Mayer’s Simple Scrum:
[T]he team members reflect on their process, seeking ways to improve and making commitments to change. Every Sprint produces […] a better, happier team.
While not widely quoted, I just love Dale Emery’s Second Directive:
We accept the responsibility to change at least one of the conditions that made our best less than we now want it to be.
Many teams decide on the topic of a retrospective during the retrospective itself. It is common to have a list of topics ordered by priority after gathering data. In other words, many retrospectives have a generic goal, e.g. “Learn from the last sprint.”
However, a team may choose to narrow that, e.g. “Avoid the flood of bug reports right after release.” In Scrum, the Scrum Master may suggest such a focus based on his observations. When focusing a retrospective, it might be helpful to gather some data beforehand in order to facilitate the analysis. For instance, have charts ready that show the relationship between releases and bugs.
So you know about the 5 canonical phases. But what if you have more than one topic to talk about?
After gathering data, prioritize the topics and for the most important one
- Generate insights and
- Decide what to do
When done, repeat these two for the next most important topic. Iterate until your time box is up or you have agreed on enough actions to fill the team’s plate.
Oftentimes folks who are new to retrospectives will try to talk about every single thing that is on someone’s mind. In my experience, this leads to either overly long discussions or to superficial ones, with tons of good will, but no consequences. If you are unlucky, you will have both. Don’t worry about trying to cover everything. Focus on the actions that you agree on during the retrospectives, observe how things get better. Over time people will start trusting the process.
It’s like with definitions of done: a weak DoD that is enforced by the team is better than a strong one that is adhered to only from time to time.
Most retrospectives look back. They are called retro-spectives after all. However some teams have had great success by looking forward for improvements, that is by employing a solution focus instead of a problem focus.
Pierluigi Pugliese has a great presentation on employing a solution focus.
A number of techniques used in prospectives are based on Luke Hohmann’s Innovation Games. The speedboat (image, description) is a prime example.
Yes, there is the bible: Esther Derby and Diana Larsen’s “Agile Retrospectives”. Allegedly, after years of begging from the community, Esther and Diana are working on a second edition.
Here are two great resources on the web: