What About Iterative Development?

All that I have said is somewhat introductory to the notion that we don't do projects in one fell swoop, but break them down into iterations. Each iteration has its own rhythm, so the graphs described in this chapter are really only an approximation. For example, for a project with four iterations, the percent complete curve would probably look more like Figure 12.7.

Figure 12.7. Percent complete curve for a four-iteration project.

Here what we see are four S-curves stacked one on top of another. Percent complete is cumulative, and I have made the assumption that each iteration takes 25 percent of the time and gets us 25 percent along on the completion curve. In the following sections I will depart from this simplifying assumption.

Now let's jump to the velocity and acceleration (forces) curves that correspond to this four-iteration percent complete graph (see Figure 12.8).

Figure 12.8. Velocity and forces in a four-iteration project.

What do these graphs of the derivatives tell us?

What we see is that the velocity curve replicates itself four timesno surprise there. The project gains and loses velocity four different times, corresponding to each iteration having a somewhat similar rhythm. The second derivative curveacceleration^[15]has three discontinuities, which we can also "see" in the velocity curve.^[16] What this means is that at the start of each iteration after the first, you need to "kick" the project out of its residual negative force from the previous iteration and impart an initial positive force. This is what causes the velocity vector to change abruptly. Without this instantaneous, discontinuous force, you won't get going again without losing time.

^[15] By now you are used to the idea that the graphs can be labeled "acceleration" or "force" interchangeably.

^[16] It may be hard to see, but there is a difference between the four peaks at 100 percent on the velocity curve and the three troughs at about 10 percent. The passage through the maxima is smooth, with a zero derivative. On the other hand, the passage through the minima is not smooth; the slope changes abruptly. That is what leads to the discontinuity on the acceleration (force) curve.

Most good project managers know about this and apply the requisite force at the appropriate time. We shouldn't be all that surprised by the discontinuityafter all, we started at zero with a non-zero positive force to get the project underway. All I am saying is that at the end of the iteration we still have a residual negative force, and we need to jumpstart back to that positive force we began with.

Having applied this positive force, you need to once again build it until the iteration hits its "wall," and the inevitable negative forces set in. Then it's just a question of hitting the breakthrough for that iteration, the one that again reverses the negative force curve.

So now we know how to apply our model to a multiple-iteration project. It's the same game: Plot the percent complete curve, take the derivatives, and interpret the results. The only thing that has changed is that our percent complete curve is a little more complex at the outset. But the rules of the game are the same.

But all this is a bit boring when all the iterations look the same, not to mention that we have no insight regarding the real project at hand, because thus far in our analysis nothing truly mirrors reality. So let's get real.

Iterations and Phases

In real-life iterative development, we may have many iterations, divided up into distinct phases. How can I inject this sort of reality into the model?

Well, I'm not up to a multi-phase, multiple-iterations-per-phase graph. And it's not clear that we need that complexity anyway. After all, it is the phases that have the biggest difference in their characteristics, not the iterations within the phases. So, to keep things reasonably simple, let's model the phases and assume only one iteration per phase.

The Rational Unified Process defines four phases:^[17]

^[17] Kruchten, Philippe. The Rational Unified Process: An Introduction, Second Edition (Boston: Addison-Wesley, 2000).

Inception
Elaboration
Construction
Transition

These four phases do have different characteristics. Early in the project, we are doing a lot of discovery (new learning). In the middle of the project, we do somewhat less discovery but lots of invention; there is still a lot of learning going on. Later in the project, we are actually doing the activities that count for "completion;" some invention and lots of implementation. Learning drops off a bit as the project moves toward completion.^[18]

^[18] The relevant reference here is Grady Booch's Object Solutions: Managing the Object-Oriented Project (Menlo Park: Addison-Wesley, 1996), p. 61.

At this point it is necessary to decouple the ideas of "learning" and "completion." Until now I have been assuming they are the same. Table 12.1 shows numbers that my colleague Philippe Kruchten^[19] believes are applicable to the four phases.

^[19] The "completion" numbers come from work by Philippe Kruchten and Walker Royce in 1999 on the Rational Unified Process. See Footnote 17. The "learning" numbers are from a private communication with Philippe and represent his best estimate.

Table 12.1. Learning and Completion Metrics for Phases in the Rational Unified Process
Phase	Percent of Elapsed Time	Percent Learned	Percent Complete
Inception	0 10	0 10	0 5
Elaboration	10 40	10 60	5 25
Construction	40 90	60 90	25 90
Transition	90 100	90 100	90 100

What these numbers tell us is that we learn faster than we achieve completion when we do phased, iterative development. This accelerated learning is what helps us reduce risk. How do I introduce these ideas into our model?

I have only two modifications to make:

I plot "percent learned" and "percent complete" separately.
For each of these curves, I plot the S-curve segments according to Table 12.1, in order to model that level of reality.

Results

All the results are shown together in Figure 12.9.

Figure 12.9. Graphs for Table 12.1 learning and completion curves.

Discussion of Results

There would appear to be a lot of explaining to do.

First, let's address the difference in the shapes of the learning and completion curves. Basically, you achieve 60 percent of your learning in the first 40 percent of the project, and are only 25 percent complete at that point. This reflects the notion that in iterative development we emphasize learning early to reduce risk. The counterweight is that you don't make much "visible" or "tangible" progress, because often the learning does not have many artifacts that go along with it. In any event, as a project manager you are going to have the following conversation at the 40 percent point of your project:

Boss: "You've used up 40 percent of the time, but you show only 25 percent complete. You are in big trouble."
You: "Not really. In iterative development, learning is important in the first half. And we have accomplished 60 percent of the learning we set out to do."
Boss: "Really? That's great. Can you show me the 60 percent?"

At this point I would suggest having some additional arrows in your quiver. What I generally do is go back to the "risk list" I assembled at the beginning and show how the learning has eliminated or mitigated these risks.

Now let's look at the velocity curves. Let's defer discussion of the first and fourth phases to later, because it's more interesting to discuss these and their associated forces at the same time. For the moment, let's concentrate on the Elaboration and Construction phases, where there are interesting differences.

What we see is that learning velocity peaks during Elaboration, whereas completion velocity peaks during Construction. This is consistent with our model, in which we set out to get over the learning hump in Elaboration, sacrificing or deferring completion a bit. The idea is that the measurable artifacts of completion begin to show up only during Construction, so that is when that curve shows its peak.

You might ask why both velocity curves go down to almost zero at the 40 percent point and then back up. Wouldn't it be better if we could "keep" some of that velocity across the boundary? Yes, it would. The reason we can't is that the two S-curves join at the boundary. In fact, discontinuities in the force curve show up at the boundaries for this very same reason. The reality that corresponds to this mathematical artifact is that distinct phases cause disruption on any project. That is why many senior project managers try to blend things at the boundary; they sometimes try to get an "advance team" working on the next phase a little early (before the antecedent phase is actually done) to smooth the transition over the boundary. It is hard to pull this off. The other logical consequence of this effect is that the more phases you have, and the more iterations you have within phases, the more boundaries you create. If there is a fixed overhead at each boundary, then you increase your total overhead by increasing the number of phases and iterations.

The forces comparison for Elaboration and Construction is also pretty clear; the learning forces are stronger during Elaboration and relatively weak during Construction. On the other hand, I note that the completion forces have about the same peak values during both Elaboration and Construction, which is a good thing.

Now let's address the Inception and Transition phases. Each of these is accomplished over a short time intervalonly 10 percent of the project each. Because the S-curve causes its derivative curve to have a peak, accomplishing that turnaround in a short period of time causes the peak to be bigger. Correspondingly, the force curve necessary to turn around the velocity curve in this short interval also requires large peak forces. This is why when we get to the force curve, both for learning and completion, we see maximum peak forces in these intervals. It is a result of having a very short interval. The antidote, if you will, is to not have S-curve behavior during these short periods. If the progress curve here were simply linear over the interval, then the force would be less. S-curves and their derivatives do better over longer time periods. They are perhaps the right model for long periods, and a poor model for short intervals.

On the other hand, these "large" forces may be real and not artifacts of the S-curve compressed into short intervals. It is certainly the case that we have large forces at the end of the project, during Transition. Anyone who has ever had to finish a project will attest to that; it's what makes finishing so hardyou need a big push when the team is the most tired. And, there are also large forces early in the project, during Inception, because it is at the end of Inception that we have our first "go/no go" decision to face. If people working on the project are concerned about cancellation at this early branch point, then you can be sure that there will be large forces at work.