Retrospectives are team meetings where all members reflect on the past in order to shape the future. There are a variety of ways to gather and share this information. A concrete example should help those unfamiliar with the concept:
Every week, the team meets to review the work of the preceding week. The focus is on improvement and solving problems, rather than blame. A secondary objective is to share successes so that the team can collectively see practices that are working well and should continue.
For example, one or more people will write down ideas that the team comes up with in the following categories:
What went well?
What needs improvement?
What is puzzling us?
Test coverage is at 85%.
CI Server is running smoothly.
Product owner was happy with the demo.
The integration build has been red every morning for the past 3 days.
Stories are being kicked back. We don't have enough integration tests.
Deployment to QA environment is too slow - we need automation.
We don't know when we will have content in Spanish.
New story cards are appearing on the wall without estimates. Where are they coming from?
The questions at the top may differ from team to team. Instead of "What needs improvement?", you may see "What has improved?" Instead of "What is puzzling us?", you may see "What went badly?" or vice-versa.
We'll consider identify what individual skills support this practice by answering: So what makes this practice go well?
Focus. For example, if the major pain point is that a demo didn't go well, focus on the reasons why this is so. Center the discussion on data gathered from the team about the problem. Focus and centering the discussion depend on good Leadership in the group--so here's an individual skill we could add to the inventory.
Consider using activities to keep the team engaged and open-minded. These activities and skills to keep communication channels open rely on individual skills for Communication and Peer-to-Peer Feedback.
Identify the problems, not the people who are responsible for problems. (Team leaders may need to address problem individuals over time, but it isn't part of the retrospective.) This fact-finding without blame could be called Appreciative Inquiry.
Focus on solutions - this isn't a venue for complaining or blaming, but for identifying problems to be solved. This also depends on Peer-to-Peer Feedback.
Assign one or more people to each problem / improvement opportunity. Create story cards with estimates to cover any work that is done to reduce or eliminate the problems. Failing to do this will likely mean that nothing will change. Adding story cards to the backlog is a way for the team to commit to change--and is a clear example of Collective Ownership.
Celebrate successes by encouraging people to recognize what went well. This feedback is just as important as what went poorly. "Change what isn't working, but don't change what is working." There are several elements of Supportive Culture here, as well as Confidence and Peer-to-Peer Feedback.
Once the list of problems is complete, solicit ideas on how to solve the problems. If no sound ideas emerge right away, assign them as a spikes or a offline discussions with interested parties later. This sounds like Collective Ownership again, so we'll stop analyzing here. We keep hitting the same skills, so it seems like most of them have been identified.
We've just identified several skills to support this practice. Let's tie them back to the practice, just to be sure we've got a good list:
Peer-to-Peer Feedback - this is the core of a good retrospective, the free and open exchange of ideas. Being able to let go of ego and include things you have not done as well as you would like is key.
Collective Ownership - every member of the team is responsible for improvement.
Leadership - knowing how to speak up about a problem, success or opportunity is at least as important in this meeting as it is in stand-ups.
Confidence - Good retrospectives give us insight into the state of a project, help us affirm what we're doing right, and help us recognize individual contributions on the team.
Appreciative Inquiry - sharing what has worked before and focusing on solutions means that problems are solved quickly and all team members understand what the next steps will be.
Communication - good retrospectives are an example of strong, public, positive team communication.
There's something missing--it's the individual daring to say something that others don't want to hear. Let's add it:
Speak Your Truth - sharing concerns with minimal judging and expressing yourself with respect and tact are important to get the best information and ideas in a retrospective.
Retrospective Rules (James Carr) - A short blog on behaviors and ideas that can make or break a retrospective.
The Retrospective Starfish (Pat Kua) - Blog entry on an alternative to the usual three-column retrospective summary.
A Retrospective Timeline (Pat Kua) - A more long-term view of what works and doesn't on a project.
Facilitation Patterns (Jeremy Lightsmith) - A wiki aimed at people who facilitate meetings (including retrospectives).
Agile Retrospectives: Making Good Teams Great (Esther Derby, Diana Larsen) - A comprehensive book on Agile retrospectives.
The Prime Directive http://www.retrospectives.com/pages/retroPrimeDirective.html