by Karl E. Wiegers, (Process Impact) and Johanna Rothman. [This paper was originally published in Software Development, February 2001. It is reprinted (with modifications) with permission from Software Development magazine.]
Pat, a vice-president in an Internet start-up company, was proud of her team’s previous product release but concerned about why it had shipped a few weeks later than planned. At the project’s retrospective, Pat was astonished to hear several team members say, “I might have been done earlier, but I didn’t know exactly what ‘done’ meant. If I had known when my part was really finished, we might have been able to ship earlier.” It was a valuable comment, and Pat used the information on her next project to define clear release criteria, which helped improve her team’s schedule performance.
Retrospectives provide a structured opportunity to look back at the project or phase you just completed. You might see practices that worked well that you want to sustain, but you might also see what didn’t go so well and gain insights on how to improve. The retrospective helps you identify the lessons you’ve learned from often-painful experience.
The astute project manager will begin each new project by reviewing the lessons learned from previous projects for ideas that will save time and avoid sleepless nights. You might not be able to quantify the value of learning from past experiences. Nonetheless, the small investment you make in a retrospective will almost certainly save you more time than it costs. In today’s speed-driven and bottom-line conscious development world, you can’t afford to repeat past mistakes and encounter the same surprises on project after projec
A retrospective is a gathering of knowledge, insights, and possibly metrics and artifacts from a completed project or project phase. Metrics might include actual results for schedule, effort, cost and quality, which you can use to improve your future estimates. You can archive key project documents, plans and specifications to serve as examples for future projects.
A retrospective provides closure, a way for the participants to share their observations away from the day-to-day pressures. Even if the project was a colossal failure, the lessons you learn from evaluating it can produce something positive from the experience and point to useful improvement opportunities.
It may seem silly to talk about what a retrospective is named, but names have powerful associations. When someone calls a retrospective a post-mortem,we wonder who died; sometimes projects are successful! And naming a retrospective a post-partum suggests that the new baby product may grow up someday, but is far from mature. “Retrospective” and “post-project review” are neutral terms that suggest a contemplative reflection on previous experience to gain practical wisdom.
Hold a retrospective whenever you want to gather information about your project or evaluate how the work is going. Many projects iterate through a series of development cycles, so you should gather lessons after each cycle 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 ago, but those painful memories contain the seeds of future improvements.
The Retrospective Process
An effective retrospective follows the simple process depicted in Figure 1. The key players are the manager who sponsors the retrospective, the project team members and a facilitator.
Planning. Planning begins when the management sponsor who requested the retrospective working 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. During planning, you also need to identify who should be invited, choose an appropriate facility (preferably off-site and away from distractions), select the facilitation techniques you will use, and define an agenda.
We’ve had different results with splitting participants into groups. In one retrospective, Karl and another facilitator led two separate discussion groups in parallel. One group consisted of six managers, while the other group was made up of 15 software practitioners. The facilitators and the sponsoring manager believed that the practitioners would be reluctant to raise certain issues if their managers were in the room. Splitting the participants worked well in this situation, although we had to carefully merge and prioritize the issues from both groups. In another case, however, separating the participants proved unwarranted. The two groups involved were a software development team and a visual design team who had worked together on a major Web site development project. Karl underestimated the participants’ collaborative mindset, and realized that, despite some points of friction between the groups, it would have been better to keep the entire team in the same room to discuss their joint issues.
Johanna has never separated participant groups, because she believes that separating the groups placates the people with the perceived power. It’s important to prepare the managers by telling them that the retrospective may uncover issues that are uncomfortable for them. As Jerry Weinberg points out, “No matter what it looks like, it’s always a people problem,” and sometimes the people problems are management-generated. Consider requesting permission from the managers to ask them to leave the room if they seem to be inhibiting the discussion.
Kickoff. During a short kickoff session with all participants, the sponsoring manager introduces the facilitator and any other unfamiliar faces. The manager also 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. The facilitator then outlines the agenda of events. To establish the appropriate constructive environment, the facilitator defines 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. While some retrospectives collect hard data and project artifacts, the core activity is gathering issues, observations, and concerns from the participants. We explore three 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? (These might be risks to watch for on future projects.)
An experienced facilitator has numerous techniques for eliciting information from different kinds of participant groups. The traditional approach is to have a facilitator stand by a flipchart 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 audience 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 (affinity groups) and name the issue groups.
This traditional facilitation approach has several drawbacks.
- Sequential issue-generation is slow.
- It’s easy for a few outspoken participants to dominate the input.
- It’s easy to slip into an extended discussion of a single hot-button topic, instead of identifying additional issues.
- Some participants may be uncomfortable raising issues in a public forum.
- Influential or strong-willed participants might render others unwilling to speak up.
If you’re concerned about any of these factors, consider using alternative facilitation approaches. Silent techniques that let participants generate issues in parallel can be more efficient and comprehensive than the public, sequential method. In one such approach, the facilitator and the retrospective sponsor identify several categories in which issues are likely to arise prior to the retrospective meeting. Common categories for software development projects include communication, organization, teamwork, management, requirements, design, construction, testing, subcontractors, business issues and processes. You probably won’t need all of these categories for every retrospective. There is a risk that defining the category names in advance will limit what comes out of the group, so you might prefer to group issues and name the groups after issue-generation is completed.
Write each category name on a separate flipchart page, and 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 3×5 sticky note, indicating the pertinent category. The facilitator places these in the right section of the appropriate flipchart page. Spend about 20 minutes clarifying the things that went well, then move on to what could have gone better for another 20 or 30 minutes. Participants can walk around the room and see what other people wrote on the flipcharts to stimulate their own thinking.
This approach addresses most of the shortcomings of the traditional facilitator-at-the-flipchart method. Participants working concurrently can generate more issues in a given amount of time. There is little chance of being distracted by discussions as each issue is raised. And people who might be reluctant to state their opinions aloud willingly contribute them silently and anonymously. However, the facilitator will have to read all the sticky notes on the flipcharts aloud to share them with the entire group, 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, you might ask each team member two questions: What one aspect of this project would you want to keep the same on a future project? And what one aspect of this project would you want to change on a future project?
Issue Prioritization. A successful retrospective will generate far more issues than the team can realistically address. You must identify those items that the participants agree would be the most valuable to pursue. Some high-priority issues might point to effective practices you want to institutionalize on future projects. Others will reflect shortcomings in current practices that you need to address promptly.
A classic prioritization technique is Pareto voting. Each participant gets a limited number of votes, usually about 20 percent of the total number of issues being prioritized. To simplify the data collection with a large group, some facilitators give each participant just three to five votes. Colored adhesive dots work well for this voting process. The participants walk around the room, examine the flipcharts and place their dots on the sticky notes with 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 participants who might not want to “waste” votes on issues that clearly are not favored by the earlier voters. To avoid that problem, you can have the participants place their voting dots on the backs of the sticky notes.
Analysis. If you have time during the retrospective, spend 15 or 20 minutes discussing each of the top priority items. Otherwise, assemble a small group to explore those topics after the retrospective 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, determine why each item didn’t turn out as intended, the consequences of each and recommendations for doing it better the next time.
Retrospective Success Factors
A retrospective can succeed only in a neutral, non-accusatory environment. Honest and open communication is essential. If a project has been difficult or unsuccessful, some venting is to be expected; however, the facilitator must limit that venting and channel it in a constructive direction. Make sure your retrospectives don’t turn into witch-hunts. The retrospective must emphasize guilt-free learning from the shared project experience. Let’s look at some retrospective critical success factors.
Define your objectives. As the sponsoring manager, you should identify your objectives for the retrospective and the specific project aspects on which it should focus, along with identifying the potential beneficiaries of the activity: Who will come out ahead if the information gathered during the retrospective guides some constructive process changes? Also, think about who might look bad if the root causes of problems are revealed. Remember, you’re not looking for scapegoats, but you need to understand what really happened and why.
Use a skilled and impartial facilitator. It isn’t realistic to expect the project manager to objectively facilitate a retrospective. The manager might have a particular axe to grind or want to protect his own reputation. Some project managers might unconsciously impede participation despite their good intentions. Other participants can be intimidated into silence on important points, or the manager might put his own spin on certain issues.
To avoid these problems, invite an experienced, neutral facilitator from outside the project team to lead the retrospective. The facilitator’s prime objective is to make the retrospective succeed by surfacing the critical issues in a constructive, learning environment. Consider having someone who is not an active participant in the retrospective act as scribe to record the issues generated.
Engage the right participants. Of course, the essential participants are all of the project team members. Management representatives are invited to the retrospective only if they were actually members of the project team. However, you should provide a summary of lessons learned to senior management or to other managers in the company who could benefit from the information.
Some teams might be too busy, too large or too geographically separated for all team members to participate in a retrospective concurrently. In such a case, select representatives of the various functional areas that were involved in the project. If a large project was subdivided into multiple subprojects, each one should perform its own retrospective. Delegates from each subproject can then participate in a higher-level retrospective at the overall project level.
When people who we believe have key insights claim they’re too busy to participate, we ask them if they think everything went well on the project. Generally, they have some important observations and constructive suggestions. We then help those people balance their current time demands against the need to hear their input on the previous project.
If the project involved multiple groups who blame each other for the project’s problems or who refuse to sit down together to explore their common issues, you might begin by discussing the friction points between the groups. Chances are good that you’ll uncover important project issues. If the groups can’t get along in the retrospective, they probably clashed during the project, too. 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 accustomed to retrospectives, and if the project being studied had serious problems, an invitation to a retrospective can stimulate fear, confusion or resistance. Some participants might be sick with anxiety, while others will be eager to let the accusations fly. Provide information and reassurance to the participants through the invitation material and during “sales calls” made on team leaders and key participants. Describe the process in advance, and establish an appropriately constructive mindset, by emphasizing that this is a future-oriented and process-improvement activity.
Focus on the facts. A retrospective should address the processes and outcomes of the project, not the participants’ personalities or mistakes. The facilitator has to ensure the participants don’t blame or placate others by concentrating on what actually happened. However, people often experience events in different ways. Understanding the different interpretations can release hard feelings and provide the opportunity for new insights.
Identify the action plan owner. Identify the person who will write and take ownership of an improvement action plan and see that it leads to tangible benefits. Assign each action item in the plan to an individual who will implement it and report progress to the action plan owner. This owner must carry enough weight in the organization to steer these individuals toward completing their action items.
Retrospective Action Planning
After the retrospective, don’t try to tackle all of the identified issues immediately. Choose up to three issues initially from the top priority list; the rest will still be there for future treatment. Write an 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. Remember, an action plan that doesn’t lead to concrete actions is useless. Karl once facilitated retrospectives for the same Internet development group two years apart. Some issues that came up in the later event were the same as those identified two years earlier. Failing to learn from the past practically guarantees that you will repeat it, and nothing kills an organization’s attempt to hold retrospectives faster than recommendations aren’t implemented.
For the maximum organizational benefits, accumulate lessons learned from your retrospectives. We prefer to write lessons learned in a neutral way, so it isn’t obvious whether we learned each one because something was done well or because the team made a mistake. The information in your lessons-learned database could include:
- Statement of the lesson.
- Lesson-learned subject category.
- Date the lesson was entered into repository.
- Project name.
- Risks of ignoring the lesson.
- Recommendations for implementing the lesson.
- Work product involved.
- Pertinent life cycle phase.
The People Side
Because we’re human, our personalities influence how we react to situations. During one retrospective that Johanna facilitated, a management participant had tears in his eyes when he described a particular concern. Johanna spoke to him at a break and the words flooded out of him. He said he felt that his management didn’t trust him, yet he didn’t feel comfortable saying so. He agreed to have Johanna bring up this sensitive topic.
When the group reconvened, Johanna said that one participant did not feel trusted by management because of three points that she wrote on the flipchart. The room was silent for a minute. Then someone else said, “Me, too.” Several others chimed in, and then they looked at the senior manager. Johanna reminded the group we weren’t judging individuals, but rather airing our concerns so we could address them. The senior manager then asked, “Does anyone here trust me?” No one responded. It was a very telling moment. The senior manager then listed that lack of trust as a problem.
The project team is the best source of information about how a recently completed project or development phase really went. Use a retrospective to help the team assemble a whole picture of the project, so the project leader can use that information to create a more effective environment the next time. But remember that all organizational change takes time, patience and commitment from all stakeholders. If people don’t want to change, they won’t.
Like this article? See the other articles. Or, look at my workshops, so you can see how to use advice like this where you work.