Staged Delivery is a lifecycle model in which software is developed in stages, usually with the most important capabilities being developed first. Staged Delivery doesn't reduce the time needed to build a software product, but it substantially reduces the risks involved in building one and also provides tangible signs of progress that are visible to the customer and useful to management in assessing project status. Keys to success include being sure that the product architecture is solid and defining delivery stages carefully. Staged Delivery can improve overall code quality, reduce the risk of project cancelation, and support build-to-budget efforts.
Efficacy
Potential reduction from nominal schedule: | None |
Improvement in progress visibility: | Good |
Effect on schedule risk: | Decreased Risk |
Chance of first-time success: | Very Good |
Chance of long-term success: | Excellent |
Major Risks
Feature creep
Major Interactions and Trade-Offs
Can plan each delivery stage using Miniature Milestones
Success depends on defining a family of programs (part of Designing for Change)
Less flexibility than Evolutionary Delivery or Evolutionary Prototyping; can serve as a basis for Evolutionary Delivery
Trades increased planning effort for increased progress visibility
Staged Delivery is a lifecycle model in which you develop software in successive stages and either show it to the customer or actually deliver it at the end of each stage. Figure 36-1 provides a graphical depiction of this lifecycle model.
As Figure 36-1 suggests, with Staged Delivery you go through the waterfall model steps of defining the software concept, analyzing requirements, and creating an architectural design. You then proceed to do detailed design, coding, debugging, and testing within each stage, creating a releasable product at the end of each stage.
Figure 36-1. The Staged Delivery lifecycle model. Staged Delivery allows you to deliver a product in stages after first developing requirements and architectural design in a traditional way.
Staged Delivery supports improvements in the perceived schedule more than in the actual schedule.
More visible progress for custom-software development. With some software-development approaches, you complete large sections of the lifecycle almost in secret. Technical projects often provide status reports such as "90 percent complete." That's not enough for customers who have learned the hard way that if the first 90 percent of a project takes 90 percent of the time, the last 10 percent of the project can take another 90 percent of the time. It's easier to keep your customers happy when you're regularly showing them evidence of your progress.
For custom software, an approach that puts something in front of the customer on a regular basis increases the customer's confidence that you will eventually complete the project. Your progress is obvious. The customer's perception of your speed improves.
Shorter product-release cycles for shrink-wrap software development. With typical development approaches for shrink-wrap software, you define version 1 and then design, code, and test until you complete it. If development takes longer than planned, the product ships late and revenue from the product comes in late. If your company's finances are shaky and you're slow in finishing version 1, you might never get a chance to start version 2.
Using the Staged Delivery practice, you can define internal versions at a finer granularity than version 1 and version 2. You can define versions 2a through 2f and plan to have them ready at 1-month intervals. You might plan to have 2a ready at 7 seven months into a 1-year schedule, 2b ready at 8 months, 2c ready at 9 months, and so on. If you meet your 1-year schedule, you'll have 2f ready and you can ship the full product. If you don't complete 2f, you'll still have a working product in 2c, 2d, or 2e. Any of those versions is an improvement over version 1, and you can ship it instead of 2f. Once you ship it, you can define new increments for version 3 and continue.
This approach supports more frequent and predictable product releases. From your customer's point of view, you've released two versions, 1 and 2, and you released those two versions on time. From your point of view, you've developed several versions but released only the two that were ready at the time your company needed them.
This approach requires sophisticated coordination with marketing and user-documentation efforts, but if you're working in the highly competitive world of packaged software, it can be an effective way to reduce the risk of a product-development cycle.
Early warning of problems. When you plan to deliver releases early and often, you get early, frequent, indisputable progress reports. Either the release is done on time or it isn't. The work's quality is obvious from the release's quality. If the development team is in trouble, you discover that within the first one or two releases; you don't have to wait until the project is "99 percent complete" and 0 percent functional.
Less overhead. Staged Delivery also goes a long way toward eliminating the administrative time that developers spend creating progress reports and other traditional progress-tracking reports. The working product is a more accurate status report than any paper report could ever be.
Makes more options available. Even if you're uneasy about releasing version 2c to your customer when you planned to release version 2f, using Staged Delivery provides you with something you can release if business needs call for it. You might ultimately decide that it's not in your best interest to release version 2c and defer release to version 2d. But if you don't use Staged Delivery, you won't have the option.
CROSS-REFERENCE
For more on refining estimates based on experience, see Recalibration in Further Reading.
Reduces estimation error. Staged Delivery sidesteps the problem of bad estimates by delivering early and often. Instead of making one large estimate for the whole project, you can make several smaller estimates for several smaller releases. With each release, you can learn from the mistakes in your estimates, recalibrate your approach, and improve the accuracy of future estimates.
CROSS-REFERENCE
For more on frequent integration, see Chapter 18, Chapter 18.
Integration problems minimized. A common risk to software projects is difficulty in integrating components that were developed separately. The likelihood of serious integration problems is related to the time between successive integration attempts. If the time between attempts is long, the chance of problems is large. When you deliver software early and often, as you do with Staged Delivery, you must also perform integration early and often. That minimizes potential integration problems.
In Staged Delivery, you start with a clear idea of the product you will ultimately deliver. Staged Delivery is a late-in-the-project development practice. If you're following a traditional waterfall lifecycle model, you don't need to start planning for it until after you've completed requirements analysis and architectural design.
Once you've completed architectural design, to use Staged Delivery you plan a series of deliveries. As Figure 36-1 on Further Reading suggests, within each stage you do a complete detailed design, construction, and test cycle, and at the end of each stage you deliver a working product. For example, if you were developing a word processing program, you might create the following delivery plan:
Table 36-1. Example of a Staged-Delivery Schedule for a Word Processor
Stage 1 | Text editor is available, including editing, saving, and printing. |
Stage 2 | Character and basic paragraph formatting is available. |
Stage 3 | Advanced formatting is available, including WYSIWYG page layout and on-screen formatting tools. |
Stage 4 | Utilities are available, including spell checking, thesaurus, grammar checking, hyphenation, and mail merge. |
Stage 5 | Full integration with other products is complete. |
The first delivery should be the germ of the product you will ultimately deliver. Subsequent releases add more capabilities in a carefully planned way. You deliver the final product in the last stage.
Planning for the first release is unique in that it needs to include some global architectural thinking, which raises questions such as: "Is the software architecture open enough to support modifications, including many that we haven't fully anticipated?" It's also a good idea to plot a general direction for the software at the beginning of the project—although, depending on whether you intend to use a pure Staged Delivery approach or an Evolutionary Delivery approach, that general direction might just be a best guess that you'll override later.
You don't have to deliver each release to a customer to use the Staged Delivery practice, and you can implement it on a technical-lead level. In the case of the word processor, you might not even release a version to your customer until delivery 3 or 4 or even 5. But you could use Staged Delivery as an aid to track progress, coordinate drops to quality assurance, or reduce the risk of integration problems.
For the approach to work well, each stage should include size, performance, and quality targets in addition to functionality targets. Too much hidden work accumulates as you go along if you don't deliver a truly releasable product at the end of each stage.
As a general goal, try to deliver the software's capabilities from most important to least important. Defining the deliveries in this way forces people to prioritize and helps to eliminate gold-plating. If you do a good job of this, by the time you've delivered 80 percent of the product your customer will be wondering what could possibly be left in that last 20 percent.
In a single large release, the order of component delivery doesn't matter much. Multiple small releases of a product require more planning than a single large release does, and you have to be sure that you haven't overlooked any technical dependencies in your planning. If you plan to implement autosave in delivery 3, you'd better be sure that manual save isn't planned for delivery 4. Be sure that the development team reviews the delivery plan with an eye toward technical dependencies before you promise specific features at specific times to your customers.
Staged Delivery requires that each developer meet the deadline for each stage. If one developer misses a deadline, the whole release can slide. Some developers are used to working solo, performing their assignments in whatever order they choose. Some developers might resent the restrictions that a Staged Delivery plan imposes. If you allow developers the amount of freedom they are used to, you'll miss your delivery dates and lose much of the value of staged deliveries.
With Staged Delivery, developers can't follow their noses as much as they're used to doing. You need to be sure that the developers have bought into the delivery plan and agreed to work to it. The best way to ensure developer buy-in is to involve developers intimately in the creation of the plan. If the delivery plan is their delivery plan—and if there was no heavy hand influencing their work—you won't have to worry about getting their buy-in.
A good way to define the stages is to use themes for each incremental release (Whitaker 1994). Defining releases can give rise to feature-by-feature negotiations that can take up a lot of time. The use of themes raises those negotiations to a higher level.
CROSS-REFERENCE
For details of another kind of theme, see Shared, Elevating Vision or Goal in Creating a High-Performance Team.
In the delivery schedule mapped out in Table 36-1 on Using Staged Delivery, the themes are text editing, basic formatting, advanced formatting, utilities, and integration. These themes make it easier to decide into which release to put a particular capability. Even if the feature straddles a gray area—you could classify automatic list numbering as either advanced formatting or a utility, for example—your job will be easier because you only have to decide which of the two themes is most appropriate. You don't have to consider every feature for every release.
When you use themes, you probably won't be able to deliver features in exact priority order. Instead, plan to prioritize the themes in order of importance, and then deliver the themes in priority order.
The use of themes, shouldn't be taken as an invitation to abbreviate release planning. Map out exactly which features you plan to have in each release. If you don't, you won't know exactly what to expect at each delivery stage, and you'll lose much of the project-tracking benefit of this lifecycle model.
CROSS-REFERENCE
You can use the Miniature Milestones practice to track progress during each stage. For details, see Chapter 27, Chapter 27.
Staged Delivery works best for well-understood systems. If you're not sure what features your product should have, then the Staged Delivery practice isn't a good choice. You have to understand the product well enough to plan the stages by the time you're done with architectural design.
Staged Delivery works especially well when your customers are eager to begin using a relatively small portion of the product's functionality. You can provide a valuable service to your customers if you can provide the 20 percent of the product they most need in a fraction of the development time needed for the complete product.
Staged Delivery is also an appropriate practice for very large projects. Planning a series of four 9-month projects is considerably less risky than planning a single 3-year project. You would probably have stages within stages for a project of that size; even a 9-month project is too large to provide good progress visibility to your customer, and you should break it up into several incremental releases.
Staged Delivery works well only for systems in which you can develop useful subsets of the product independently. Most end-user products can be defined in such a way that you can make meaningful intermediate deliveries before you deliver the final product. But operating systems, some kinds of embedded systems, and some other kinds of products might not be usable without complete or nearly complete functionality; for those kinds of systems, Staged Delivery is not appropriate. So if you can't figure out how to break the delivery of your product up into stages, Staged Delivery is not the right approach for you.