Robert Galen introduces his book, Software Endgames, where he presents the core strategies for delivering working software to your customers, focusing solely on the endgame—that final stage of software development between release for testing and release to customers.

The endgame is the period of software development between the testers’first receipt of the software and the customers’first receipt of the product.

In heavier-weight methodologies, the endgame is entered later in the project life cycle, with a much larger scope to be tested over the course of several iterations.

In lighter-weight methodologies, the endgame may be entered quite early in the project life cycle, with a much smaller scope to be tested over the course of many iterations.

The endgame is really about testing, defect detection, and rework, ultimately leading to product stabilization and customer release.

Think of it in terms of the final stages of a software development project, when the construction phases are winding down and testing has begun. At this point, management begins to develop high expectations for product delivery—expectations that normally don’t align with the realities of the product’s maturity and stability.

The term “endgame,” borrowed from chess, is quite appropriate. Everything prior to endgame entry is simply setup and preparation. You win or lose depending on your endgame strategy and overall execution. That’s what makes it so darn challenging.

You Know You’re in the Endgame When . . .

I’ve tried to define endgame entry from a methodological point-of-view. It’s also possible to determine your entry in the endgame simply by what you’re experiencing. The following scenarios are all-too-familiar indicators once you’ve played one or more roles in the endgame:

You are a software developer, and you’re frantically finishing up late features and repairing bugs like mad. And not a day goes by without someone asking about your progress or whether you’re done yet.

You are a software tester, and you’ve got about half the time you expected for testing, primarily because development took longer than expected to complete coding. You’re working like mad to test the product and to find mass quantities of bugs, which cause more work, which in turn introduces more bugs, and so on. And not a day goes by without five folks asking about your progress and whether the product is “good enough” to ship yet.

You are a manager on the team, and you feel as if everything is out of control. Features are getting changed and added at the last minute. Defects are coming in bunches, and product stability seems to be a fleeting goal. Most of the time, your team doesn’t seem to have the numbers, skills, or time to keep up with all the work. And not a day goes by that the project manager, director, or VP doesn’t ask whether the product is done yet.

You are the project manager—you’re under intense pressure from management to deliver. You’re burdened by too many bugs, too little product stability, far too little time, and high expectations for you to manage everything effectively. Every time you focus on one problem, five others seem to surface elsewhere. You feel like you’re driving a car with no steering wheel and no brakes. And, yes, everyone keeps asking you about progress.

You Know You’ve Exited the Endgame When . . .

To complete the bounding of the endgame period, I present the following indicators that your project is leaving the endgame:

The project is cancelled.

The project manager and/or other managers are fired or reassigned.

The project sponsor is fired or reassigned.

You are simply exhausted and can’t go on any longer.

You have a party celebrating the release (whether it’s on-time or late).

You simply release it and move on.

You find yourself, oddly enough, working within another endgame, a situation not unlike certain episodes of The Twilight Zone.