Selling a Project Retrospective
Read Project Retrospectives: A Handbook for Team Reviews and more than 24,000 other books and videos on Safari Books Online. Start a free trial today.
“Who? Who?” Owl asked as he peered down from his porch. “Oh, it’s you, Beaver. Where are you going?”
- Beaver stopped short and looked up into the tree to answer Owl. “It’s not where I’m going, it’s where I’ve been. I was visiting the Alligator Alliance. I tried to sell them on the idea of building a new swamp.”
- Curious to know more, Owl asked, “How did your meeting go?”
- “I tried to use my best engineering logic,” replied Beaver. “I showed the alligators exactly where the humans have changed the water flow just upstream from their swamp. I included water-flow measurements, calculations, hydro-dynamic projections, and photographs showing how the humans breached my dams. It’s obvious to the casual observer that the swamp will get smaller every year for the next three until there will be no swamp left. I explained how, in my years of experience with humans, I’ve found that they don’t give up on these projects.” Beaver took a deep breath before continuing. “The only logical response is to build a new swamp over in Never-Build-Here Valley.”
- Owl probed, “Did they buy into your proposal?”
- Showing obvious disappointment,“ Beaver replied, “No, they didn’t. But their refusal doesn’t make sense. There is no logical reason not to build a new swamp. Alligators are just stupid!”
- Owl was considering how best to give Beaver some suggestions on selling his idea to the alligators when Beaver changed the subject. “By the way, Owl, I passed the levee that directs water around your tree. It should be built out another foot or two longer, given the new water-flow projections. Do you want me to work on it?”
- “Sure,” replied Owl, as he watched Beaver scurry away.
Beaver is an engineer. He doesn’t know how to sell and, like many technical professionals, he doesn’t want to know. Nevertheless, for retrospectives to flourish, facilitators need to learn how to sell, if only just a little.
I have a special place in my heart for people who set out to sell an organization on trying its first retrospective. Whether you are a retrospective facilitator, a member of a community that is ending a project, or an advocate in a software engineering process group—you are on a bold and noble path. In an ideal world, you would use Beaver’s approach. You would attempt to sell management simply by describing the process and activities of a retrospective and conclude by saying, “This is a good thing and it is obviously cost-effective. Decide now to do it.”
However, as Beaver discovered, this is not an ideal world and this approach never works unless management has already been sold, which means that the selling was done earlier by someone else. Let’s look more closely at how to sell the idea of a retrospective.
Understanding the Market for Retrospective Sales
Begin by analyzing the retrospective-buying marketplace. You can divide it into three segments: First are those potential clients who want to change their software development process because change is a habit. Second are those who want to change because of the pain or crisis experienced during the project. Third are those who don’t want to change their process at all because they think the status quo is good enough.
Each of these segments has its own special needs and is motivated by unique factors, so your approach to selling retrospectives must vary according to your customer. The figure shown on the following page illustrates market opportunity and ease of sale.
By looking at the figure, we can see that a community in Segment 1, in which continuous process improvement is a habit, will readily accept the idea of a retrospective. The team has learned to look at its development process and improve it every day—in fact, improving its process is regarded as a crucial part of the job, and the team’s track record shows it. If team members have not yet participated in a retrospective, the most likely reason is that they either don’t know about the technique, haven’t found a good facilitator, or have tried it but did not have a good format for facilitation. It strikes me as a sad fact that there are too few teams in the software engineering field that consistently and reliably produce excellent software at reduced cost in the expected time frame.
At the other end of the spectrum are numerous groups that fall into Segment 3. These groups rarely consider the idea of seeking ways to improve their process. In such groups, attention to process is lost in the urgency to solve the immediate problems of creating software. At first glance, you will see little motivation for such groups to consider a retrospective. It doesn’t mean you shouldn’t try to sell to this segment; it just means that the sell will require more effort and more time. Even after all that, there is little likelihood that the Segment 3 group will buy into holding a retrospective. You will need to find a “mass market” approach, relying on numbers to find the few groups interested in trying a retrospective. These few groups may be making their first effort toward moving to Segment 1, or sadly, have recently and painfully moved into Segment 2.
Segment 2 contains groups that have experienced difficulties during their previous project. Their project struggled to the end. Schedules slipped, technology let them down, customers were unhappy, or possibly the project was stopped before the software was produced. While change is not a habit for such a group, its members are now aware that something different needs to be done. The problem, however, is that they aren’t certain what that is. A retrospective will be foreign to them. The idea that individuals within their community have something valuable to learn from each other, that they can discover ways to improve their work process, or that this learning can be done in a positive manner will be suspect. Nevertheless, a team that is in this segment is a good prospect.
Segment 1 Sales Approach (Change As Habit)
To sell a retrospective to managers in a Segment 1 environment, ask them how they have gone about identifying aspects in their software process that they want to improve. Ask them to describe all aspects of change they find intimidating. Explain the retrospective process, demonstrate that you are competent, and tell them ways a retrospective can complement their current approach to improving software process. You might share with them details from Chapter 2, “Anatomy of a Retrospective,” or even better, write a version based on your own experience leading retrospectives but tailored to fit the current situation.
Segment 2 Sales Approach (Change Due to Pain)
To sell Segment 2 customers, begin by assuring management that the community can find ways to prevent a similar painful experience from occurring on future projects. Help the managers see that if the community does not learn, the likelihood of a recurrence of the experience is great. Help them understand that software development practice can improve. Explain Kerth’s Prime Directive for retrospectives and discuss ways to make a retrospective a positive learning experience. Ask the managers what concerns they have about the retrospective and respond with facts from a few of your own True Stories.
Segment 3 Sales Approach (No Change Requested)
Plan on waging a long sales campaign and use frequency of the message as your main sales tool. Your goal will be to accomplish one or more of the following:
- Help the team shift into Segment 1 or 2, and then proceed with the sales approach for that segment.
- If team members have shifted by themselves, help them realize they have moved into Segment 1 (or 2), and then work with them to set up a retrospective.
- Build a relationship and wait for team members to realize they need to set moving into Segment 1 as a goal.
When I use the expression “frequency of the message,” I mean that you should use a combination of mailings, phone calls, and lunches to accomplish this ongoing dialogue and to build your relationship with the Segment 3 customer. Position yourself not just as a retrospectives expert, but also as a clearing-house of software engineering information—an expert in the whole field and, as such, the first one they think to call whenever they have a question.
Periodically, touch base with managers in the community and discuss whatever difficulties they are having. Do what you can to keep communication channels open. From time to time, share stories with them about how a particular retrospective benefited another similar community. Use the lessons learned from other retrospectives not to push the idea of retrospectives themselves, but to share the wisdom. Take every opportunity to educate the managers about how a retrospective can help their teams improve their software process. Let them know that if they ever need help, you are available.