Guideline: Conduct Project Retrospective |  |
This guideline covers how to conduct a Project Retrospective, step by step.
Relationships
Related Elements | Assess Results Assess Results Project Management
Main Description
# Establish norms and agreements Begin the Project Retrospective by establishing the duration, goals, and expectations of the session. The following are typical durations for various Retrospectives: Iteration: 2 to 4 hours Incident: 15 to 45 minutes Project: 1 to several days Select the facilitator of the Retrospective (See Concept: Retrospective for more detail on the facilitator). If the team is gathering to conduct the first Retrospective, the group will need to create the cultural norms that will be used in the future Retrospectives. If the team is regrouping to conduct a Retrospective, the existing cultural norms will be used. Norm Kerth’s Prime Directive is an excellent and widely referenced guiding principle for each Retrospective: Prime Directive: “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.” [KER01] 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 needs to include organizational value statements that govern acceptable behavior and interactions, supplemented by inviolable principles that govern the conduct and ethics of the team. The team must establish these rules of group engagement before the Retrospective continues to the core of the group’s intended gathering. Examples of working agreements include: tardiness is not acceptable; mobile phones must be powered off during the session; all participants must be in attendance throughout the duration of the Retrospective or ask permission from the group for early departure; all opinions are welcome; the team must strive for healthy, high-quality interaction. The team’s working agreements (and the Prime Directive statement) should be displayed prominently in the Retrospective session, so that they are clearly visible to all members of the team and, if required, easily accessible so that the team can edit the content. After it is defined, future Retrospectives can begin with a review of these working agreements. After the team has established a safe environment in which to conduct the Retrospective, the facilitator of the Retrospective should elicit participation from the group, thereby granting tacit permission to members who are hesitant to participate immediately. # Collect and analyze data The team begins this step of the Retrospective with 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, and so forth), and review of project artifacts (requirements artifacts, project plans, and such). Encourage the team to capture all information (project data, opinions, and so on) by using various tools (white boards, charts, timelines) that provide a visual representation so that the team can identify relationships and emerging patterns. The team uses guiding questions to collect and analyze meaningful project data. You can use these examples of key questions 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? Were all planned work items addressed? What was the team’s velocity relative to the plan? Did the end users provide favorable feedback on what we built in this iteration? Are changes to the project plan required? What portion of the current release will be used to establish the baseline? What portion will need to be reworked? Have there been external changes, such as changes in the marketplace, in the user community, or in the requirements? Was the development process appropriate? How can it be fine-tuned for the specific needs of this project? The team has generated a list of candidate topics to focus on for its collective inquiry, or heightened analysis. The team’s methods of analysis need to facilitate a deepening understanding of the events characterizing the iteration, incident, release, or Project Retrospective. The team will be evaluating these driving factors, which ultimately documents a roadmap for the next cycle: Success: “What worked well for us during the past iteration (or project or phase)?” Failure: “What did not work well for us during the past iteration [or project or phase)?” Opportunities for improvement: “What should we do differently, or what improvements should we undertake during our next iteration (or project or phase)?” With increasing emphasis, the thread of team collaboration continues throughout the Retrospective, thereby fostering an environment conducive to candid, 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. For each item evaluated, they will have established a root cause. The team will know what worked well, what did not, and what to do differently this time, so they can carry forward a list of suggested improvements that will be prioritized by the team. # Set priorities By referencing the project data collected and analyzed in the Retrospective, the team now creates a list of suggested improvements, assigning a priority to each item on 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 as input to update the next Iteration Plan, so you can ensure an integrated relationship between the changes identified in the Retrospective and the normal course of the team’s work plans. Get commitment from members to complete, the suggested improvements that have been chosen for application in the next iteration cycle. The visibility and commitment among the members of the team imbue a sense that the Retrospective was worthy of the team’s investment of time and that the results of the work on the Retrospective will be tracked in the next iteration cycle. Maintain a backlog of the suggested improvements that were not chosen for the next iteration cycle. This will preserve the work of the Retrospective. The selected content will be available for convenient access and monitoring for progress, and the unselected items will be available for consideration during future iteration cycles. # Conclude and document the process The team’s honed methods of investigation and analysis are now applied to the Retrospective itself. 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 (for example, through the use of Retrospective documentation or pictures from a digital camera taken during the Retrospective).
More Information
Concepts | Retrospective
This program and the accompanying materials are made available under the Eclipse Public License v1.0 which accompanies this distribution. OpenUP Copyright. OpenUP/DSDM Copyright.