59. Shipping On-Time, Every Time

The team always ships its releases on-time.

Now and then, you will hear a software manager boast,“My team always ships on-time.” That’s a pretty impressive statement. Assuming that the team has shipped multiple times and that the software it builds is nontrivial, shipping on the baselined, planned date, 100 percent of the time, is quite an accomplishment.

However, teams that always ship on-time sooner or later have to lower the quality bar in order to hit the ship date. We’re not saying that they do so on every release. But a team that never compromises its ship quality criteria will eventually miss a ship date.

Navigating a development cycle requires constant rebalancing of priorities and reallocation of resources. In general, organizations have five main “levers” with which to steer the project:

1. People: Who is assigned to the project?

2. Technology: What processes, methods, and tools are available to your team?

3. Scope: What features are you building? What platforms are you supporting them on?

4. Calendar time: When do you intend to ship?

5. Ship quality criteria: What degrees of completeness, correctness, and robustness must the product exhibit before you ship it?

If you have formulated a rational plan, you have balanced these factors at the outset of the project. As you proceed, however, some things change, and you discover that other things were not what you thought they were. So, you adjust some combination of the five levers to keep your project on track to a successful outcome.

As we saw in Pattern 28, “Time Removes Cards from Your Hand,” the closer you get to the ship date, the less useful some of your levers become. For example,

• “Adding manpower to a late software project makes it later.”¹ Adding people consumes both the project’s calendar time and the effort of people already on the project. Adding people late in the game is rarely going to help you hit a ship date. If anything, it may contribute to slippage.

¹ Frederick P. Brooks, Jr., The Mythical Man-Month: Essays on Software Engineering (Reading, Mass.: Addison-Wesley, 1975), p. 25.

• Changing methods or tools entails retraining, and it is unlikely to accelerate the first project on which the new processes or tools are used. The learning curve consumes time.

• De-scoping only really helps if the features being de-scoped have not yet been developed. There typically comes a time in the release cycle when the product is essentially feature-complete: Most of the feature code has been written and is now being stabilized. You may save some time by cutting a complete feature, thus saving QA time, but de-scoping loses its value toward the end of the cycle.

When you encounter problems late in the release cycle, you often find yourself with only two operable levers: calendar time and ship quality criteria. If you have managed well, the problems you find late in the project are not going to be mammoth ones, but they may still require course correction.

If you really are committed to shipping exactly on-time, every single time, you are left with only one correction available: relaxing your ship quality criteria.