Alistair Cockburn
Human and Technology
7691 Dell Rd, Salt Lake City, UT 84121
(801)943-7772 fax: 801/943-8499
email: arc@acm.org

To the person owning the project calendar, time flows only in one direction - forward. It does not loop around. Spiral, fountain, tornado (etc.) development is therefore difficult for most project managers and team leaders to apply. We have been applying the "validation V" and project management "W" [Cockburn95] on fairly large projects for three years now. The V-W staging vocabulary lets developers work in the incremental, iterative manner they need, and lets the calendar owner map that work to straight calendar time. On our latest project, the new vocabulary of V's and W's let everyone on the team breathe heavy sighs of relief, as they could finally describe what they were doing, and planning on doing.

Iterative development has remained hard to describe and apply, starting from its presentation as spiral development in 1988 [Boehm88]. Since that time, many people have given colorful names to it, such as fountain, tornado, whirlpool, and so on.

The key difficulty is that the project calendar does not show circles, fountains or spirals. Time moves inexorably forward. Most attempts to explain iterative development center around trying to teach the project manager to think in spirals. In contrast, this paper's explanation of V-W staging maps the developers' spiraling timeline to a linear timeline. Each one pass around the spiral / circle / fountain corresponds to a 'V'. The 'V' maps to the spiral and it also maps to linear time. An incremental and iterative staging process is built as a set of adjacent, overlapping, or superimposing 'V' (hence the "W") to build the project schedule. The V-W structure also shows visibility, internal releases and internal increments hiding within public releases and increments.

We introduced the V-W staging terminology to a fairly large project. Some of the team leaders were already doing V-W staging (without naming it so), and were content to see that their way of working was going to get executive approval. Other team leaders saw that it permitted them to improve their manner of work, and adopted it overnight. Others saw, over time, that it permitted them to describe where they were in their work and what they were trying to accomplish. The project managers and team leaders now have a vocabulary for talking about iterations and mapping them to Gantt charts.

 

V-W Staging

The developer lives in a non-linear world (Figure 1). A subsystem does not just "develop". Its design goes backwards and forwards, progresses sometimes slowly, and sometimes quickly, loops around in unpredicted ways. For all that, it is safe to say that the subsystem does not ship without being validated, cannot be validated until it the bugs are removed, cannot be tested until it is built, cannot be built without design, is not designed without requirements. This much is as true for a prototype as for a final product. This is the "validation V" (see Figure 2).

The validation V is a fact of life, not a falling back to waterfall development. It is inescapable. And, it lets us build iterations and increments, mapping those to a linear time scale (Figure 3 and Figure 4)

By "incremental development", I specifically mean a staging and scheduling strategy in which the various parts of the system are developed at different times or rates, and integrated as they are completed. It neither implies, requires nor precludes iterative development or waterfall development - both of those are rework strategies. The alternative to incremental development is to develop the entire system with a "big bang" integration.

By "iterative development", I specifically wish to mean a rework scheduling strategy in which time is set aside to revise and improve parts of the system. It does not presuppose incremental development, but works very well with it. As shown in the figures, the difference is that an increment may actually ship, whereas an iteration is examined for modification.

In terms of the validation V, what is called waterfall development is a project plan with only one V. A one-pass, incremental development plan has a simple series of V's. An iterative, incremental plan has V's within V's (as we shall see).

The termination of each V, whether it is a prototype, a running user demo, or a subsystem or set of functions moving to QA, constitutes a milestone for the person who owns the calendar. Figure 5 shows how the V fits to the Gantt chart.

A 'V' can fit within another 'V'. One is for iterations, the other is for management visibility. Both are illustrated in the same picture, Figure 6. Suppose you decide to run two user demos before settling the design. You would have an outer 'V' for the increment (the final design), with three inner 'V's, one for each iteration. The end of each V is a project milestone, as before. The final V ends the increment as it goes to test.

Suppose that you are given 10 months for your increment, and you wish to subdivide that. Then you publish the outer V to the executive sponsors, but run three small increments, the three inner V's, within your group.

Finally, you can use the V's to run the schedules of multiple, lightly synchronized teams (Figure 7). The teams can declare different length V's, with different synchronization points, as they need. The V's show when they get gone, with what level of visibility.

We have had good experience applying the V-W vocabulary on two fairly large projects, and have used it to capture discussions with other people who successfully manage iterative, incremental projects.

On one project, the impact of the vocabulary was particularly striking. There were three teams, in particular, who worked in quite different ways.

• The first team already developed in three-month increments, with one user-demo in the middle. They viewed the V-W technique as little more than an interesting vocabulary for describing what they were already doing. They were, however, relieved that their way of working could be explained to the project executives.
• The second team was following a big-bang, waterfall approach, and not comfortable with it. The team lead immediately saw the point and value, and had his schedule changed to V's overnight. He was relieved to be able to both protect his iterations, and show frequent milestones to his executives.
• The third team was following a big-bang, iterative approach, and was having trouble explaining it. They were relieved to see each user demo appear as a complete pass through a V. They could describe which V they were in, and where they were, in it. Over time, they shifted to increments, with a number of user demos (little-V's) within each.
• The teams could use the V's to explain progress of inter-team deliverables to each other, and we used them also for monitoring subsystem stability.
• The project executives were happy to know what it meant to be within a prototyping-V, a user-demo-V, or a final-integration-V, and to see meaningful milestones progressing along the calendar. Previously, milestones might have meant "requirements complete", "analysis complete", etc., but those milestones were not meaningful on a project of this size.

V-W staging is a way of talking about incremental, iterative, spiral, and prototyping strategies. It provides a way for the project manager to:

• uncurl the spiral of spiral development so that the activities lie flat against the project time-line,
• arrange prototypes and iterations without sacrificing the notion of continuous progress,
• derive effective progress indicators based on delivered function rather than "phase deliverables",
• manage subcontractors on delivered increments instead of phase deliverables,
• get the value of "gestalt round-trip" without having to study Zen.

[Boehm88] Boehm, B. "A spiral model of software development and enhancement", Computer, May 1988, pp.61-72.

[Cockburn] Cockburn, A., "Unraveling Incremental Development", Object Magazine, Jan. 1995, pp. 49-51.