Evolutionary Delivery is a lifecycle model that strikes a balance between Staged Delivery's control and Evolutionary Prototyping's flexibility. It provides its rapid-development benefit by delivering selected portions of the software earlier than would otherwise be possible, but it does not necessarily deliver the final software product any faster. It provides some ability to change product direction mid-course in response to customer requests. Evolutionary Delivery has been used successfully on in-house business software and shrink-wrap software. Used thoughtfully, it can lead to improved product quality, reduced code size, and more even distribution of development and testing resources. As with other lifecycle models, Evolutionary Delivery is a whole-project practice: if you want to use it, you need to start planning to use it early in the project.
Efficacy
Potential reduction from nominal schedule: | Good |
Improvement in progress visibility: | Excellent |
Effect on schedule risk: | Decreased Risk |
Chance of first-time success: | Very Good |
Chance of long-term success: | Excellent |
Major Risks
Feature creep
Diminished project control
Unrealistic schedule and budget expectations
Inefficient use of development time by developers
Major Interactions and Trade-Offs
Draws from both Staged Delivery and Evolutionary Prototyping
Success depends on use of designing for change
Some people go to the grocery store carrying a complete list of the groceries they'll need for the week: "2 pounds of bananas, 3 pounds of apples, 1 bunch of carrots," and so on. Other people go to the store with no list at all and buy whatever looks best when they get there: "These melons smell good. I'll get a couple of those. These snow peas look fresh. I'll put them together with some onions and water chestnuts and make a stir-fry. Oh, and these porterhouse steaks look terrific. I haven't had a steak in a long time. I'll get a couple of those for tomorrow." Most people are somewhere in between. They take a list to the store, but they improvise to greater and lesser degrees when they get there.
In the world of software lifecycle models, Staged Delivery is a lot like going to the store with a complete list. Evolutionary Prototyping is like going to the store with no list at all. Evolutionary Delivery is like starting with a list but improvising some as you go along.
The Staged Delivery lifecycle model provides highly visible signs of progress to the customer and a high degree of control to management, but not much flexibility. Evolutionary Prototyping is nearly the opposite: like Staged Delivery, it provides highly visible signs of progress to the customer—but unlike Staged Delivery, it provides a high degree of flexibility in responding to customer feedback and little control to management. Sometimes you want to combine the control of Staged Delivery with the flexibility of Evolutionary Prototyping. Evolutionary Delivery straddles the ground between those two lifecycle models and draws its advantages and disadvantages from whichever it leans toward the most.
CROSS-REFERENCE
For details on these kinds of support for rapid development, see the introductions to Chapter 21, Chapter 21, and Chapter 36, Chapter 36.
Evolutionary Delivery supports rapid development in several ways:
It reduces the risk of delivering a product that the customer doesn't want, avoiding time-consuming rework.
For custom software, it makes progress visible by delivering software early and often.
For shrink-wrap software, it supports more frequent product releases.
It reduces estimation error by allowing for recalibration and reestimation after each evolutionary delivery.
It reduces the risk of integration problems by integrating early and often—whenever a delivery occurs.
It improves morale because the project is seen as a success from the first time the product says, "Hello World" until the final version is ultimately delivered.
As with other aspects of Evolutionary Delivery, the extent to which it supports rapid development in each of these ways depends on whether it leans more toward Staged Delivery or Evolutionary Prototyping.
To use Evolutionary Delivery, you need to have a fundamental idea of the kind of system you're building at the outset of the project. As Figure 20-1 suggests, in the evolutionary-delivery approach, you start with a preliminary idea of what your customer wants, and you create a system architecture and core based on that. That architecture and core serve as the basis for further development.
Figure 20-1. The Evolutionary Delivery lifecycle model draws from Staged Delivery's control and Evolutionary Prototyping's flexibility. You can tailor it to provide as much control or flexibility as you need.
The architecture should anticipate as many of the possible directions the system could go as it can. The core should consist of lower-level system functions that are unlikely to change as a result of customer feedback. It's fine to be uncertain about the details of what you will ultimately build on top of the core, but you should be confident in the core itself.
Properly identifying the system core is one key to success in using Evolutionary Delivery. Aside from that, the most critical choice you make in Evolutionary Delivery is whether to lean more toward Evolutionary Prototyping or Staged Delivery.
In Evolutionary Prototyping, you tend to iterate until you and the customer agree that you have produced an acceptable product. How many iterations will that take? You can't know for sure. Usually you can't afford for a project to be that open-ended.
In Staged Delivery, on the other hand, you plan during architectural design how many stages to have and exactly what you want to build during each stage. What if you change your mind? Well, pure Staged Delivery doesn't allow for that.
With Evolutionary Delivery, you can start from a base of Evolutionary Prototyping and slant the project toward Staged Delivery to provide more control. You can decide at the outset that you will deliver the product in four evolutionary deliveries. You invite the customer to provide feedback at each delivery, which you can then account for in the next delivery. But the process will not continue indefinitely: it will stop after four deliveries. Deciding on the number of iterations in advance and sticking to it is one of the critical factors to success in this kind of rapid development (Burlton 1992).
With Evolutionary Delivery, another option is to start from a base of Staged Delivery and slant the project toward Evolutionary Prototyping to provide more flexibility. You can decide at the outset what you will deliver in stages 1, 2, and 3, but you can be more tentative about stages 4 and 5, thus giving your project a direction but not an exact road map.
Whether you slant more toward Evolutionary Prototyping or Staged Delivery should depend on the extent to which you need to accommodate customer requests. If you need to accommodate most requests, set up Evolutionary Delivery to be more like prototyping. Some experts recommend delivering the software in increments as small as 1 to 5 percent (Gilb 1988). If you need to accommodate few change requests, plan it to be more like Staged Delivery, with just a handful of larger releases.
You use Evolutionary Delivery when you're not exactly sure what you want to build. But unlike Evolutionary Prototyping, you do have at least some idea, so you should map out a preliminary set of deliveries at the beginning of your project, while you're developing the system architecture and system core.
CROSS-REFERENCE
For details on the value of mapping out possible changes to a system at design time, see Define Families of Programs in Using Designing for Change.
Your initial delivery schedule will probably contain some functionality that will definitely be in the final system, some that will probably be, and some that might not be. Still other functionality will be identified and added later.
Be sure that you structure your delivery schedule so that you develop the functionality you are most confident in first. You can show the system to your customers, elicit their feedback, and gain confidence that the remaining functionality is really what they want—before you begin working on it.
If you understand your system so well that you don't expect many surprises, you will be better off using Staged Delivery than Evolutionary Delivery. You have more control over the project when you map out exactly what will be delivered at the end of each stage ahead of time. That style of development is most often appropriate for maintenance releases or product upgrades in which you already understand the product area thoroughly and don't expect to discover any revolutionary insights along the development path.
CROSS-REFERENCE
For a related discussion of planning decisions that depend on how well-understood your system is, see Team-Structure Considerations, "Team- Structure Considerations."
If your system is poorly understood and you expect a lot of surprises, including surprises that are likely to affect the system in fundamental ways, you will be better off using Evolutionary Prototyping than Evolutionary Delivery. Evolutionary Delivery requires that you know enough about the project at the outset to design an architecture and to implement core functionality. With Evolutionary Prototyping, you don't have to do those things at the beginning.
Evolutionary Delivery isn't limited to completely new systems. On an existing system, each new delivery can replace part of the old system and can also provide new capabilities. At some point, you'll have replaced so much of the old system that there's nothing left. The architecture of the new system needs to be designed carefully so that you can transition to it without being infected by the old system's restrictions. That might mean that you can't create certain portions of the new system right away; you might want to wait until the new system can support those portions without kludges.