| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ContentDescription xmi:version="2.0" |
| xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.5/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmi:id="-i-UeSpBxKd6YtGLz_NW8GQ" |
| name=",_277QEA4gEdy63f1yVoPyfA" guid="-i-UeSpBxKd6YtGLz_NW8GQ" changeDate="2007-06-01T15:50:36.302-0700"> |
| <mainDescription><h3> Establish norms and agreements</h3>
 |
| <p> Begin the Project Retrospective by establishing the duration, goals, and expectations 
 |
| of the session. The following are typical durations for various Retrospectives: 
 |
| </p>
 |
| <ul>
 |
| 
 |
| <li><b> Iteration: </b>2 to 4 hours </li>
 |
| <li><b> Incident: </b>15 to 45 minutes </li>
 |
| <li> <b>Project: </b>1 to several days </li>
 |
| </ul>
 |
| <p>
 |
| Select the facilitator of the Retrospective (See <a class="elementLinkWithType" href="./../../../openup/guidances/concepts/retrospective_B003F386.html" guid="_2PfbIA4QEdy2q5zsU8WDnA">Concept: Retrospective</a> for more detail on the facilitator).
 |
| </p>
 |
| <p> 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: </p>
 |
| <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
 |
| 
 |
| <p class="quote"> <strong>Prime Directive</strong>: “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.” [<a class="elementLinkWithUserText" href="./../../../openup/guidances/supportingmaterials/references_6CCF393.html#KER01" guid="_9ToeIB83Edqsvps02rpOOg">KER01</a>] 
 |
| </p>
 |
| </blockquote>
 |
| <p> 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. </p>
 |
| <p> The team’s working agreements (and&nbsp;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. </p>
 |
| <p> 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. </p>
 |
| <h3> Collect and analyze data </h3>
 |
| <p> 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. </p>
 |
| <p> The team uses guiding questions to collect and analyze meaningful project 
 |
| data. You can use these examples of key questions to elicit relevant information: 
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Were the defined goals and objectives met? Did the release meet its functionality and quality goals? Did the
 |
| release meet performance and capacity goals?
 |
| </li>
 |
| <li>
 |
| Were risks reduced or eliminated? Can we identify new risks?
 |
| </li>
 |
| <li> Were all planned work items addressed? What was the team’s velocity relative 
 |
| to the plan? </li>
 |
| <li>
 |
| Did the end users provide favorable feedback on what we built in this iteration?
 |
| </li>
 |
| <li>
 |
| Are changes to the project plan required?
 |
| </li>
 |
| <li> What portion of the current release will be used to establish the baseline? 
 |
| What portion will need to be reworked? </li>
 |
| <li> Have there been external changes, such as changes in the marketplace, in 
 |
| the user community, or in the requirements? </li>
 |
| <li> Was the development process appropriate? How can it be fine-tuned for the 
 |
| specific needs of this project? </li>
 |
| </ul>
 |
| <p> 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: </p>
 |
| <ul>
 |
| <li><b>Success: </b>“What worked well for us during the past iteration (or project 
 |
| or phase)?”</li>
 |
| <li><b>Failure: </b>“What did not work well for us during the past iteration 
 |
| [or project or phase)?”</li>
 |
| <li><b>Opportunities for improvement: </b>“What should we do differently, or 
 |
| what improvements should we undertake during our next iteration (or project 
 |
| or phase)?”</li>
 |
| </ul>
 |
| <p> 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. </p>
 |
| <p> 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. </p>
 |
| <h3> Set priorities</h3>
 |
| <p> 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. </p>
 |
| <p> 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. </p>
 |
| <p> 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. </p>
 |
| <p> 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. </p>
 |
| <h3> Conclude and document the process</h3>
 |
| <p>
 |
| The team’s honed methods of investigation and analysis&nbsp;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,&nbsp;through the use of Retrospective documentation
 |
| or&nbsp;pictures from a digital camera taken during the Retrospective).
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
