A time boxed meeting held at the end of an iteration, or at the end of a release, in which the team examines its processes to determine what succeeded and what could be improved. The retrospective is key to an Agile team’s ability to “inspect and adapt” in the pursuit of “continuous improvement.”
The Agile retrospective differs from other methodologies’ “Lessons Learned” exercises, in that the goal is not to generate a comprehensive list of what went wrong; a positive outcome for a retrospective is to identify one or two high priority action items the team wants to work on in the next iteration or release. The emphasis is on actionable items, not comprehensive analysis.
Retrospectives may take many forms, but there is usually a facilitator, who may or may not be a member of the team, and the process is usually broken down into three phases: data gathering, data analysis, and action items. Retrospective facilitation is a distinct skill set, and there are many formal tools and exercises that may be used to gather and analyze the team’s data, many of which are described in detail in the most widely recognized handbook: Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larson.
The term retrospective was first applied to this type of meeting by Norman Kerth, who describes its origins in his 2001 book, Project Retrospectives: A Handbook for Team Reviews: “Wayne and Eileen Strider, two fellow facilitators, suggested that we call what we do a retrospective. The word seemed appropriate; it didn’t carry any loaded meanings and it could be applied to projects without implication of success or failure….”