47. Practicing Endgame

The team measures its emerging product against the release criteria at regular intervals during development.

It’s your first day of a new course of study. Your instructor greets you and the other students and then proceeds to describe how he plans to conduct the class. He concludes by saying, “I don’t believe in waiting until the end of the semester to give the final exam. I prefer to give it every two weeks throughout the term. Of course, it won’t be the same final exam each time, but it will cover the same material in more or less the same way.”

This may sound wacky, but it’s pretty similar to what we mean by “practicing endgame.”

To understand the appeal of this approach, let’s contrast it against what happens on all-too-many software projects: the Readiness Review Folk Dance. It usually proceeds in several movements:

• Procrastination during the definition of release criteria: “Well, the ship date is months away, and the Readiness Review occurs just a week or so before the planned ship date—and there are really urgent things to do right now!”

• The pre-review fire drill: “Ohmygod, the review is in less than two weeks! Where did we put those release criteria? How are we doing against them? Gosh, how would we measure this one?”

• The solemn Readiness Review ceremony: Everyone knows that the review happens so close to the ship date that any significant problems will cause the team to miss the date—“There isn’t enough time left to do any serious fixing.” So, everyone realizes that the only acceptable declaration is, “Ready to ship.” Too many defects? Service pack!

• The post-review fire drill: After the ceremony is declared a success, a few worried people gather to figure out which of the most heinous gaps in the release criteria can be cured by the ship date without doing more harm than good.

• The lessons unlearned lament: No one enjoyed this. Everyone vows to do better next time. Unfortunately, next time is months away, and we’ve got to get started on the next release, because there are really urgent things to do right now!

Like most folk dances, this one varies from one team culture to another, but we suspect that you recognize one or two aspects of your own variant in this description.

Teams that practice endgame develop their release criteria early in the project. They then develop whatever tests are required to assess the product’s fulfillment of the criteria. These tests are run at the completion of every development iteration, followed by a brief Readiness Review.

Consider the benefits of this approach:

• At every stage of development, your team becomes refocused on the work left to do in order to ship the product.

• You get early warning of regressions against criteria that were previously met.

• You have multiple opportunities to refine your release criteria as you go.

This can be an awkward process. Some release criteria are very difficult to measure meaningfully early in development. Nevertheless, even those big black “TBDs” prompt useful questions like,“Hey, when are we going to run the performance suite for the first time?”