Anatomy of a Retrospective, Part Three

Attention: The following article was published over 12 years ago, and the information provided may be aged or outdated. Please keep that in mind as you read the post.

Part three in a three-part blog series.

As previously mentioned, Retrospectives integrate well into the natural cadence of an Agile software development approach. The three typical Retrospective rhythms are conducted at the iteration, release, and project points. Additionally, a project team might consider conducting a “mini” or incident Retrospective; as an example, the result of a daily standup meeting could warrant an elaborated session of reflection, enriched with the practices that reflect the main themes of a Retrospective.

While the overarching Retrospective format remains consistent among the iteration, release, and project contexts, there is a recommended variance in the amount of allocated time and the number of attendees in each Retrospective type, summarized below:

An Iteration Retrospective will usually be time boxed at 3 hours, and will include members from the project team who represent cross-functional groups.
A Release Retrospective will typically be time boxed at 8 hours, involving members from the project team, and potentially notable stakeholders who exist external to the boundary of the project team.
A Project Retrospective will involve many of the same people who attend the release Retrospective. The amount of time allocated to a project Retrospective may range from 1 – 3 days.
A Daily Retrospective is time boxed at 15-45 minutes, involving the same members of the team who attend an Iteration Retrospective.

Establishing the foundation of a Retrospective involves distinct steps and various activities that create and help to sustain a strong spirit of collaboration and learning. These phases provide structure for the team’s focus and resulting work (figure 1).

Figure 1: Steps of a Retrospective

Step: Retrospective Entrance/Setup

Begin the Retrospective by establishing the duration, goals and expectations of the Retrospective session.
Select the Facilitator of the Retrospective.
If the team is gathering to conduct their first Retrospective, the group will need to create the cultural norms that will be used in the future Retrospective(s); if the team is regrouping to conduct a Retrospective, the existing Retrospective cultural norms will be referenced. Norm Kerth’s Prime Directive [3] is an excellent and widely referenced guiding principle for each Retrospective (Figure 2).

Remind the team that the Prime Directive and cultural norms of the Retrospective are in place to establish an environment in which the members can safely expose sensitive topics and manage meaningful, if provocative, dialogue. The cultural norms guide the team by a “social contract” that clearly outlines the “team values and working agreements” that have been established by the team. The social contract should include organizational value statements that govern acceptable behavior and interactions, supplemented by inviolable principles that govern the conduct and morality of the team. The team must establish these rules of engagement before the group gathers to conduct the Retrospective session. Examples of working agreements include: tardiness is not acceptable, and those arriving late to the meeting must pay $1.00 to a Retrospective “fund”; cell phones must be powered off during the Retrospective session; all members of the Retrospective must be in attendance during the duration of the Retrospective, or ask permission from the group to allow their early departure; all opinions are welcome in the Retrospective; the team must strive for healthy, quality interaction [1,2].
The team’s working agreements (and Norm Kerth’s prime directive statement; Figure 2) should be displayed prominently in the Retrospective session, posting such statements on a wall that is clearly visible to all members of the team and, if required, is easily accessible, so that the team can edit the content. After the working agreements have been defined, the group will begin the Retrospective session with a quick review/ reminder of the guidelines.
Once the team has established a safe environment (as previously discussed) in which to conduct the Retrospective, the Facilitator of the Retrospective should elicit participation from the group.

Step: Collect and Analyze Data

The team begins this step of the Retrospective through a review of the meaningful characteristics of the Iteration, Release, Incident, or Project period. The focus of the team’s work in this step includes: critical developments, notable discoveries, work completed, project metrics (velocity, number of defects, etc.), and review of project artifacts (Product backlog, Iteration Plan, etc.). The team is encouraged to capture all information (i.e. project data, opinions, etc.) using various tools (white boards, charts, timelines, etc.) that provide a visual representation from which the team can identify relations and emerging patterns.
The team will use guiding questions to collect and analyze meaningful project data. The following example key questions can be used by the group to elicit relevant information:

Were the defined goals and objectives met? Did the release meet its functionality and quality goals? Did the release meet performance and capacity goals?
Were risks reduced or eliminated? Can we identify new risks?
Was all planned work items addressed?
Did the end user(s) provide favorable feedback on what we built in this iteration?
What impediments are in the way of productive work?
How do the testers feel about the work provided by the developers?
How did everyone feel about pair programming?
What portion of the current release will be base-lined? What portion will need to be reworked?
When were you excited to come to work?
When was coming to work “just a job”?
When did you dread coming to work?
What were the high points during the iteration? What were the low points?
Describe the experience of being a team member during this iteration.
Was the development process appropriate? How can it be tuned for the specific needs of the project?

The team has generated a list of candidate topics on which its collective inquiry and heightened analysis will be focused. The team’s methods of analysis should facilitate a deepening understanding of the events characterizing the iteration, release, or project Retrospective. The team will be evaluating the driving factors of success (“What worked well for us during the past Iteration [Project, daily meeting, etc.]”), failure (“What did not work well for us during the past Iteration [Project, daily meeting, etc.]?”, and opportunities for improvement (“What should we do differently, or what improvements should we undertake during our next Iteration [Project, Daily Meeting, etc.]”), ultimately documenting a roadmap for the next, or future, iteration cycle [1].
With increasing emphasis, the thread of team collaboration continues throughout the Retrospective, fostering an environment conducive to candid and unimpeded examination by the team; a rigorous style of examination that will be required to unearth the details lurking in the interactions of the team, the conditions of the project, fortuitous events, failures, risks, and examples of flourishing success.
After the team has collected and analyzed the key data in the Retrospective, the team will have evaluated key project content, and for each item evaluated, will have produced a root cause. The team will know the answers to the questions “What worked well for us…?”, “What did not work well for us…?” and “What should we do differently…?”, carrying forward a list of suggested improvements that will be prioritized by the team [2].

Step: Prioritize the Suggested Improvements and Actions

Referencing the project data collected and analyzed in the Retrospective, the team will now create a list of suggested improvements, assigning a measure of priority to each item in the list.
The selection of improvements should be limited to a subset that will be applied in the next iteration cycle. This list should be considered input to update the next Iteration Plan (or daily standup meeting, Sprint, Release, or Project), securing an integrated relationship between the changes identified in the Retrospective and the “normal” course of the team’s work plans.
Secure commitment from members to execute on, and or complete, the suggested improvements that have been chosen for application in the next iteration cycle. The visibility and exercise of commitment among the members of the team imbue a sense that the Retrospective was worthy of the team’s time investment, and that the output of the Retrospective work will be tracked in the next iteration cycle.
Maintain a backlog of the suggested improvements that were not chosen for the next iteration cycle. The backlog of suggested improvements will preserve the work of the Retrospective; the selected content that will be available for convenient access and monitoring for progress; the unselected items will be available for consideration in future iteration cycles.

Step: Conclude the Retrospective

The team’s honed methods of investigation and analysis (i.e. methods of inspection and adaptation) are now applied to the Retrospective, conducting an evaluation of the Retrospective session.
During the evaluation of the Retrospective, the team considers the moments of empowering thought and interaction, considers ideas for improving future Retrospectives, revisits the team’s social contract, extends appreciation throughout the group, and preserves the discoveries of the team (e.g. Retrospective “minutes” posted to a shared intranet space, using a digital camera to capture “whiteboard” notes, etc.).

Conclusion

The cross-functional nature of a project team requires that the members feel safe in conducting open communication, expressing their feelings about the progress of the project, presenting ideas for improvement, working in an environment that values collaborative work, and effectively reaching consensus on actions that should be integrated in the ongoing project.

Agile methodologies are designed to highlight the importance (and needed competence) of team collaboration and healthy communication, addressing the non-technical, but fundamental people-related aspects of software development, filling the “feeling” gap overlooked by traditional Iteration and Milestone assessments. As illustrated, Retrospectives provide a process-oriented means of addressing the common issues related to the sociology of the project team, providing an environment for adaptation and inspection, generating ideas and innovation drivers for process improvement, and conducting a rhythmic measure of the “heartbeat” of the team. In the words of one Agile evangelist: “If you are not holding retrospectives on your Agile software projects, you are not doing Agile projects!” [3]

— Ben Haith, [email protected]

Works Cited

Norman L. Kerth. Project Retrospectives: A Handbook for Team Reviews. Dorset House Publishers, New York, 2001.
Esther Derby and Diana Larsen. Agile Retrospectives: Making Good Teams Great. Pragmatic Bookshelf, Dallas, Texas, 2006.
Guest Lecturer Jutta Eckstein: Agile Methods – Coming of Age 6th International Conference, XP 2005, Sheffield, UK, June 18-23, 2005, Proceedings