Different situations call for different levels of commitment to development speed. In some cases, you'd like to increase development speed if you can do it easily and without additional cost or product degradation. In other cases, circumstances call for you to increase development speed at all costs. Table 2-1 describes some trade-offs among different development approaches.
Table 2-1. Characteristics of Standard Approaches to Schedule-Oriented Development
Effect of Development Approach On… | |||
---|---|---|---|
Development Approach | …Schedule | …Cost | …Product |
Average practice | Average | Average | Average |
Efficient development (balancing cost, schedule, and functionality) | Better than average | Better than average | Better than average |
Efficient development (tilted toward best schedule) | Much better than average | Somewhat better than average | Somewhat better than average |
All-out rapid development | Fastest possible | Worse than average |
As you can see from Table 2-1, average practice is…average. The second approach listed in the table is what I call "efficient development," which is the combination of the first three pillars of maximum development speed as shown in Figure 2-4. That approach produces better than average results in each of the three categories. Many people achieve their schedule goals after they put the first three pillars into place. Some people discover that they didn't need rapid development after all; they just needed to get organized! For many projects, efficient development represents a sensible optimization of cost, schedule, and product characteristics.
CROSS-REFERENCE
For an example of the benefits of efficient development, see Technical Fundamentals, Technical Fundamentals and Chapter 4, "Software Development Fundamentals," generally.
Figure 2-4. Efficient development. The first three steps in achieving the best possible schedule make up "efficient development." Many project teams find that efficient development provides all the development speed they need.
Can you achieve shorter schedules without first attaining efficient development? Maybe. You can choose effective, schedule-oriented practices and avoid slow or ineffective practices without focusing on efficient development per se. Until you attain efficient development, however, your chances of success in using schedule-oriented practices will be uncertain. If you choose specific schedule-oriented practices without a general strategy, you'll have a harder time improving your overall development capability. Of course, only you can know whether it's more important to improve your overall development capabilities or to try completing a specific project faster.
Another reason to focus on efficient development is that for most organizations the paths to efficient development and shorter schedules are the same. For that matter, until you get to a certain point, the paths to shorter schedules, lower defects, and lower cost are all the same, too. As Figure 2-5 shows, once you get to efficient development the roads begin to diverge, but from where they are now, most development groups would benefit by setting a course for efficient development first.
CROSS-REFERENCE
For more on the relationship between quality and development speed, see Quality-Assurance Fundamentals, Quality-Assurance Fundamentals.
The third development approach listed in Table 2-1 is a variation of efficient development. If you are practicing efficient development and find that you still need better schedule performance, you can choose development practices that are tilted toward increasing development speed, reducing schedule risk, or improving progress visibility. You'll have to make small trade-offs in cost and product characteristics to gain that speed or predictability; if you start from a base of efficient development, however, you'll still be much better off than average.
CROSS-REFERENCE
For more on deciding between speed-oriented and schedule-risk–oriented practices, see Attaining Rapid Development, Attaining Rapid Development, and What Kind of Rapid Development Do You Need?, What Kind of Rapid Development Do You Need?
The final schedule-oriented development approach is what I call "all-out rapid development"—the combination of efficient and inefficient schedule-oriented practices. There comes a point when you're working as smart as you can and as hard as you can, and the only thing left to do at that point is to pay more, reduce the feature set, or reduce the product's polish.
CROSS-REFERENCE
For more on nominal schedules, see Nominal Schedules in Estimate Refinement. For more on the costs of schedule compression, see "Two Facts of Life" in Estimate Refinement.
Here's an example of what I mean by an "inefficient" practice: you can compress a project's nominal development schedule by 25 percent simply by adding more people to it. Because of increased communications and management overhead, however, you have to increase your team size by about 75 percent to achieve that 25-percent schedule reduction. The net effect of a shorter schedule and larger team size is a project that costs 33 percent more than the nominal project.
The move to all-out rapid development is a big step and requires that you accept increased schedule risk or large trade-offs between cost and product characteristic—or both. Few projects welcome such trade-offs, and most projects are better off just choosing some form of efficient development.
CROSS-REFERENCE
For more on whether you need all-out rapid development, see What Kind of Rapid Development Do You Need?, What Kind of Rapid Development Do You Need?
18.116.50.87