If you keep working in the same way, there’s no reason to expect future projects to go any better than previous projects. Continuous learning and process tuning are hallmarks of successful organizations. A retrospective is the most effective way to look back on completed work as part of a culture of continuous improvement.
Reflecting on completed projects or development iterations can yield insights that help future work be far more successful. Retrospectives are an intrinsic element of many agile software development approaches, as the team can apply lessons learned from early sprints immediately to improve their future sprints.
A retrospective is a structured way to gather knowledge, insights, metrics, and artifacts from a completed project, phase, or development iteration. Even in daily life, taking the time to reflect on why something unpleasant happened helps you to avoid a recurrence.
A formal retrospective provides closure. It’s a way for the participants to share their observations and experiences away from the day-to-day project pressures. Even if the project was a colossal failure, the lessons you harvest from it can produce something positive from the experience.
Retrospectives are sometimes called post-project reviews, debriefings, or post-mortems (even when the project survived!). Retrospective is a neutral term that suggests a contemplative reflection on previous experience to gain practical wisdom and improve future performance.
When to Hold a Retrospective
Hold a retrospective whenever you want to gather information about your project, evaluate how the work is going, or understand why it went the way it did. Agile projects iterate through a series of development cycles; gather lessons after each such sprint or iteration to help you with those that remain. Reflecting on past experience is especially worthwhile any time something went particularly well or particularly wrong.
It’s easy to forget what happened early in a project that lasts longer than a few months, so hold a short retrospective after reaching each major milestone on a long project. The healing effects of time and the exhilaration of recent success can ease the pain you suffered some time earlier. Those painful memories contain the seeds of future improvements, though.
The Prime Directive
The father of retrospectives, Norman L. Kerth, wrote the seminal book on this topic, Project Retrospectives: A Handbook for Team Reviews. Kerth’s Prime Directive states: “Regardless of what we discover, we must understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.” The Prime Directive can help you keep the retrospective participants focused on constructive evaluation and future improvement, not scapegoating and recriminations.
The Retrospective Process
Figure 1 illustrates a simple retrospective process. The key players are the sponsoring manager, the project manager, the project team members, and a facilitator.
Planning. The management sponsor for the retrospective works with the facilitator to determine the scope of the retrospective (the entire project or just a portion), the activities to examine, and any specific issues to probe. Planners identify who should participate, choose a facility (preferably off site and away from distractions), select appropriate facilitation techniques, and define an agenda.
Kickoff. During a short kickoff session with all participants, the sponsoring manager introduces the facilitator and any other unfamiliar faces. The manager identifies his objectives for the retrospective and thanks the participants in advance for their time and their honest contributions. The manager should clearly state his commitment to taking concrete actions based on the retrospective outcomes. Otherwise no one will take the event seriously.
The facilitator outlines the agenda of events. To establish the appropriate constructive environment, the facilitator establishes some ground rules, including:
- Allow everyone to be heard.
- Respect the other person’s experience and perspective.
- Avoid criticizing input and ideas from other participants.
- Avoid blaming people for past events.
- Identify root causes, not just symptoms.
- Focus on understanding, learning, and looking ahead.
Data Gathering. Some retrospectives collect hard data and project artifacts like key planning documents, but the core activity is gathering issues, observations, and concerns from the participants. We explore four basic questions in a retrospective:
- What went well? (We want to repeat it in the future.)
- What could have gone better? (We might want to change it.)
- What happened that surprised us? (This might indicate possible risks to manage on future projects.)
- What do we not yet understand? (Those issues require further analysis.)
The traditional facilitation approach has a facilitator stand by a flip chart in front of the group and ask the participants to suggest issues. The facilitator marks what went well with plus signs and less favorable experiences with minus signs. A variation is to use a round-robin approach, asking each participant in turn to raise one issue and cycling through the group until everyone passes. This approach to issue-generation typically takes 60 to 90 minutes.
After issue-generation is completed, the facilitator (or a scribe) records each issue raised on a separate index card. The participants then group the cards into related categories and name the issue groups.
This traditional facilitation approach has several drawbacks.
- Sequential issue-generation is slow.
- A few outspoken participants can dominate the input.
- It’s easy to slip into an extended discussion of a single hot-button topic, instead of identifying more issues.
- Some participants are uncomfortable raising sensitive issues publicly.
- Influential or strong-willed participants might render others unwilling to speak up.
Silent techniques that let participants generate issues in parallel can be more efficient and comprehensive. The sponsor could identify several categories for likely issues in advance. Common categories for software projects include communication, organization, teamwork, management, requirements, design, construction, testing, and processes.
Write each category name on a separate flip chart page. Then divide each page into labeled sections for what went well, what could have gone better, and what lessons were learned. During the meeting, have the participants write each of their issues on a separate 3x5 sticky note, indicating the pertinent category. The facilitator places these in the right section of the appropriate flip chart page. Participants can walk around the room and see what other people wrote to stimulate their own thinking.
Participants working in parallel like this can generate more issues in a given amount of time. There’s little chance of being distracted by discussions as each issue comes up. People who might be reluctant to speak up can contribute their input silently and anonymously. The facilitator will need to read all the sticky notes on the flip charts aloud, make sure each issue is clearly stated and properly classified, and group related or duplicate issues.
To close the data-gathering portion of a retrospective, ask each participant these two questions:
- What one aspect of this project would you want to keep the same on a future project?
- What one aspect of this project would you want to change on a future project?
Issue Prioritization. A successful retrospective will generate more issues than the team can realistically address, so prioritization and focus are necessary. Pareto voting is a classic prioritization technique. Each participant gets a limited number of votes, about 20 percent of the total number of issues being prioritized. Colored adhesive dots work well for this voting process.
The participants walk around the room, study the flip charts, and place their dots on the issues they believe are most important to address. Those issues that gather the most dots are most ripe for early action. However, seeing the dots on the sticky notes can bias people who might not want to “waste” votes on issues that clearly are not popular. You might have the participants place their dots on the backs of the sticky notes so they’re not visible to the voters.
Analysis. If you have time during the retrospective meeting, spend perhaps 15 minutes discussing each of the top priority items. Otherwise, assemble a small group to explore those topics after the meeting. For items noted as going particularly well, determine why they succeeded and what benefits they provided. Find ways to ensure that each of those aspects of the project will go well again in the future. For high-priority “could have gone better” items, learn why, determine the consequences, and brainstorm recommendations for doing it better the next time.
Retrospective Success Factors
A retrospective can succeed only in a neutral, non-accusatory environment; it’s not a witch hunt. Honest and open communication is essential. The facilitator needs to channel any venting in a constructive direction and make sure it doesn’t get personal. Emphasize guilt-free learning from the shared project experience. Let’s look at some critical success factors for retrospectives.
Define your objectives. The sponsoring manager should identify his objectives for the retrospective. Select the specific project aspects to review and identify the potential beneficiaries of the activity. Who will come out ahead if the information gathered guides some valuable changes? Who might look bad if the root causes of problems are revealed? You’re not looking for scapegoats, but you do need to understand what happened and why.
Use an impartial facilitator. Engage an experienced, neutral facilitator who can make the retrospective succeed by surfacing the critical issues in a constructive, learning environment. The project manager cannot objectively facilitate a retrospective. He might have a particular axe to grind or want to protect his own reputation. Having the manager take the lead can intimidate other participants into silence on important issues.
Engage the right participants. Invite all project team members to participate, along with any managers who were actually members of the team. Summarize the key issues and lessons learned to senior management and to others who could benefit.
If the project involved multiple groups who blame each other for problems or refuse to sit down together to explore common issues, you might begin by discussing the friction points between the groups. The retrospective might address what needs to change for those groups to collaborate more effectively next time.
Prepare the participants. If the participants aren’t familiar with retrospectives, the event can cause fear, confusion, or resistance, particularly if the project had big problems. Inform and reassure the participants through the invitation material and during “sales calls” with key participants. Establish a constructive mindset by stressing that this is a future-oriented improvement activity, not a blamefest.
Focus on the facts. A retrospective should address the processes and outcomes of the project, not the participants’ personalities or mistakes. Collecting objective data, such as planned versus actual schedule performance and product quality data, is helpful.
Identify the action plan owner. The action plan owner should assign each action item to an individual who will implement it and report progress. This owner must carry enough weight in the organization to steer these individuals toward completing their action items.
Don’t try to tackle all of the issues that come out of a retrospective immediately. It can be overwhelming. Choose up to three issues initially from the top priority list; the rest will still be there for future treatment. Write a simple action plan that describes your improvement goals, identifies steps to address them, states who will take responsibility for each activity, and lists any deliverables that will be created. At your next retrospective, check whether these actions resulted in the desired outcomes.
I once facilitated retrospectives for the same team two years apart. Some issues that came up in the later event were the same as those identified in the first one! If you don’t learn from the past, you’re guaranteed to repeat it. Nothing kills an organization’s retrospective program faster than recommendations that go nowhere.
The Learning Organization
The project team is the best source of information about how a recently completed project or development iteration really went. Use a retrospective to help the team assemble a whole picture of the project, to help create a more effective environment the next time. Remember that organizational change takes time, patience, and commitment from all stakeholders. If people don’t want to change, they won’t. But if they do, a retrospective is a powerful place to start.