Chapter Ten. After the Retrospective

Flying in from the West, Bee spotted Owl in his tree and settled on a branch near him. He wanted to talk to Owl about the Busy Bee Realty Company, which had grown so large Bee now had eighteen critters working for him. Bee began his conversation by telling Owl that much of the company’s success was due to Owl’s idea of holding retrospectives, and reported that he was scheduling reviews after every sale.

Pleased at Bee’s news, Owl asked about Bee’s staff. “I hear Singed-Tail started to work for you recently. He had such a bad time hunting that I’m glad to know he’s trying something new. How’s he doing?”

“He’s doing a fine job!” Bee buzzed happily. “I would never have guessed he’d succeed, but he’s my best sales-critter, breaking all records. Not only that, he writes newsletters and gives a seminar called ‘How to Sell It All: Lairs, Dens, Tunnels, Nests, Holes, and Perches.’ I guess he was born to sell.”

Owl shifted a bit on his branch. “Actually, the truth is, I’ve coached Singed-Tail a bit. He came to me just after you hired him, worried that he didn’t know anything about selling real estate. I told him to gather wisdom where he could. Right away, he started reading the reports from all your retrospectives.”

Bee hesitated for a second, looking somewhat confused. “Gee, I thought those reports were private.”

Owl flapped his wings and sputtered with exasperation, “Wisdom serves best when it’s shared. I told Singed-Tail that, too. That’s why he’s writing newsletters and teaching, putting your retrospective reports into practice. He wants your wisdom to live on!”

Bee squirmed, still looking mystified, “I wonder how he got the reports?”

“He just asked for them—but while sporting a big grin,” replied Owl. “When a wolf grins, he is likely to get anything he wants!”

Whether an organization develops an ongoing practice of holding retrospectives depends on what happens after its first one. If the ideas and energy that emerge during the retrospective get swallowed by the day-to-day operations of the next project, project members will have less interest in holding another retrospective. On the other hand, if the retrospective marks the beginning of a sustained attempt at serious, committed improvement of the software development process, then retrospectives will become habitual—and they will surely prove to be the most heavily relied-upon tool employed as management, project members, developers, and facilitators work together to build ever-stronger corporate units.

At the end of a retrospective, I like to select three or four action items that all members of the retrospective agree should be implemented on the next project (for example, accepted proposals from the “Cross-Affinity Teams” Exercise). More than four action items tends to be too many to expect participants to accomplish on the very next project, but a facilitator should work with the participants to identify which additional changes individuals can implement for themselves and which changes can be left to be undertaken “next time.” Using input from retrospective participants, we devise a plan for the community to use to track the changes, so they are not diluted or forgotten. I also lend strong support to making a report entitled “Progress on Retrospective Action Items” a standard item to be discussed during the community’s project status meetings.

As the retrospective ends, your responsibility to the particular community is nearing completion, but you may be able to take on other roles. If the community has come to appreciate your skills as a facilitator and as a leader, and if its members have become comfortable with you as part of their team, the possibilities for follow-up consulting work are good. However, whether or not you are invited to continue to work with the community, do follow up with it at various intervals to see how team members and management are progressing with their plans for change. I use both phone calls and e-mail to keep in touch with specific individuals charged with leading the changes. Usually, I contact them a couple of weeks after the retrospective to ask how they are doing and to determine whether there are small problems I can help them with. Because I do this as a follow-up to the completed retrospective on my own initiative, I charge no additional fee. However, if a true consulting assignment emerges, I let everyone know my terms so there is no confusion about the cost of ongoing work. If I am to continue to track the changes as a retrospective follow-up, I ask how often people want to hear from me.

Immediately after a retrospective, I make notes about the people I met and my impressions of them. I record who showed interest in which important issues. If feasible, I use instant-camera photographs to connect names with faces, and I flag the names of any individuals I want to stay in touch with through their subsequent projects.

As a retrospective is not an event in which a facilitator evaluates the community’s work, the report should be written not by the facilitator but by a committee made up of cross-affinity team members. This ensures good representation and widespread ownership. The report authors should identify their primary and secondary audiences and design the report for them. In addition to retrospective participants—the primary audience—a secondary audience might include

• upper-level managers of the specific project who were not at the retrospective

• managers of other projects who want to learn from the team’s experience

• managers of subsequent projects who want to validate their own scheduling estimates by looking at historical data

• new team members added to the development staff at a later date who want to understand the history and operational norms of the group

• software-engineering process-improvement investigators

Although there is no fixed report format for a team to use, the following two pages present a sample to get the writers started. This sample is intended as a boilerplate to be modified for a particular audience.

Make sure that the report is sent to all the participants as well as to the intended readership. Most likely, the majority of participants will file the report without reading it. They were there and remember more than the report can discuss. However, a few years later, they may find the report useful as a reminder of specific details of the project.

Sample Report Format

If a firm has no established process-improvement group, then other recommended selections include an executive such as the VP of Information Technology, whose office can be used to house the collection, or the firm’s librarian, whose location and curatorial skills may be almost as valuable as the collection itself!

In searching for the perfect person and place, be certain that the person responsible will keep the information alive, and that the location is secure enough to preserve any desired degree of confidentiality. Retrospective reports that end up in a locked file cabinet will never be put to good use.

To keep the wisdom alive, the responsible party needs to package it. This means to comb through the reports, cull interesting details pertaining to the various retrospectives, analyze and summarize the information, and then post or publish it where targeted customers will see it—such as on a bulletin board located in a common area or in a regular column in a company newsletter. Trends, new ideas, and cost comparisons are just some of the topics that can be presented.

The market and sell steps also require extensive ongoing effort on the part of the retrospective collector. By proactively meeting with people who are initiating new projects and exploring with them how the collection of retrospective wisdom can assist in their planning process, the collector ensures that valuable lessons do not fade from view.

Experimenting with projections derived from the accumulated effort data, several of the groups we served shifted responsibility for scheduling from marketing to the programmers and developers. The results of the experimental shift were perhaps predictable but nevertheless heartening: Although marketing-dictated schedules were never met, programmer-generated schedules invariably were more accurate.

The report collection’s value as a research resource was enhanced further when we were able to use the reports to identify configuration-management strategies and other improvements that had not been made operational because no one in the firm knew how to initiate them. Citing this quantitative data, we were able to justify the cost of hiring outside trainers to provide organization-wide courses, among other steps. The reports also helped us determine what courses we should develop in-house, what colloquium topics we should recommend for further discussion, and what standards efforts we needed to mandate.

Our software-engineering support group became recognized as project historians and data experts, consulted, for example, on how the firm developed software and what process improvement measures needed to be made. Knowing that we had cost data from which to develop return-on-investment calculations, managers and developers with new ideas asked us to help them with their project and process-improvement proposals. Over time, the number of retrospective reports in our archive grew to 86, providing to the firm an impressively large body of information. It was said that the value of that collection’s wisdom was many times greater than its weight in gold!

Eventually, I left the group to work at another location. Because no one else had my desire to package, market, and sell retrospective wisdom, the collection of retrospective reports remained dormant and unused, filed in a cabinet. The software-engineering support group I had left continued to work together, but gradually lost its edge, failing to keep up with current software-development practices. Major software projects failed, and the firm downsized, disbanding the group.

By the time word of the group’s fate had reached me, I had long since become a consultant, working to facilitate retrospectives. Suspecting that no one within my old firm cared about the 86 reports, I asked a company executive whether I could have them. He responded, “Sure—if you can find them.”

Mindful of the enormity of the task, I felt jubilant when I traced the whereabouts of the old file cabinet, only to despair at finding none of the reports in it. It seemed the cabinet’s current owner had needed the space, and had recycled all the “junk” that had been in the drawers.

As this is a true story, I will admit that I went out to the parking lot, climbed into my car, and shed some tears. I still cared for that company even though I was no longer an employee, but I felt most distressed that my former managers had failed to recognize and utilize a key that could have helped them solve many of their software development problems.

Whenever I have encountered this need for complete security of information, I have worked to find a solution, always emphasizing the belief that shared information contributes to software process improvement. It takes time, energy, and lots of dialogue to build the trust necessary to release information. I use a statement such as the following to explain my conviction to advocates of nondisclosure:

“This information is crucial for top management. It will be used only for executive summaries and as background material for decision-makers. Our goal is to justify new initiatives for software improvement, and the quantitative data we release for the justification can be limited to a small circle of executives.”

I also try to encourage security-conscious people to participate in the retrospective process—perhaps by facilitating retrospectives designed to help them understand breaches in security. In the best of cases, the collection of retrospective reports becomes familiar, and security is relaxed. In the worst, I shy away from future business.

Although we all know we can learn from our experiences in order to acquire wisdom, it’s easy to “forget” to review our own performance. However, holding a review of the just-completed retrospective is the best way I know to become a better facilitator.

Therefore, after each retrospective, I meet with a few members of the community, perhaps for dinner or in the car as we drive back home. People I invite to my retrospective-of-a-retrospective usually include sponsors such as the manager who contacted me, retrospective facilitator trainees, and any others who might have a unique perspective (such as a person who hung around after the retrospective to help clean up). They all usually have something meaningful to say.

I start the discussion by rephrasing the Prime Directive: “I did the best job I could, given what I knew at the time, and I hope I learned from this experience.” I say this for my own benefit as well as for that of the people giving me feedback. I then say I’d like to hear from each of them in response to a tailored set of the five questions from the “Mining the Time Line for Gold” activity:

• What worked well?

• What did you learn about leading retrospectives?

• What would you do differently next time?

• What still puzzles you about leading retrospectives?

• What skills, knowledge, and experiences do you need to acquire before we hold another retrospective?

As the now-ex-facilitator, my main job is to listen, although I do need to start the discussion by asking the five questions. During the discussion, I take notes and perhaps ask for clarification, but I resist any inclination to respond and defend my actions. If I say anything in defense or explanation, the free-flowing feedback will cease. I just take notes and thank each person for giving me input. A few days later, after a bit of rest, I return to my notes and decide how to interpret and use the feedback.

If you acquire wisdom from leading retrospectives and can share it, please visit my Website to post your discoveries and to download others. My goal is to create a community of retrospective facilitators who will work together to improve our software profession. Please join me.