Incremental, Iterative and Spiral Models: Surfacing Risk Early

Version note: This post is based on Barry Boehm's 1988 Spiral model paper (IEEE Computer, volume 21, issue 5), Alistair Cockburn's 2008 article "Using Both Incremental and Iterative Development" and Jeff Patton's incremental/iterative comparison from the same year.

Guess First

The Bookstore team will ship the new checkout flow in three iterations of two weeks each. The scope is clear: payment, shipping and returns. Two plans are on the table. Plan A: finish payment completely in the first iteration, shipping in the second, returns in the third. Plan B: build a rough version of all three in the first iteration, then mature all of them in the next two.

Which plan surfaces risk earlier? Which one gives the customer something truly usable at the end of the first iteration? If the answers point to different plans, maybe the right question isn't "which one?" but "how do I combine them?"

Incremental and Iterative Are Not the Same Thing

The two words are used interchangeably in everyday conversation, but they describe different strategies. Alistair Cockburn's distinction is the clearest: incremental development is a staging and scheduling strategy; different parts of the system are developed at different times and added to the whole as they become ready. Iterative development is a rework scheduling strategy; time is set aside up front to revisit and improve a part.

Jeff Patton explains the same difference with a painting analogy. A painter working incrementally finishes the painting piece by piece: first the top-left corner in full, then the piece next to it. It is like a paint-by-number book; every area and color has to be known in advance, so you have to get it right the first time. A painter working iteratively first sketches the whole painting roughly, then the underpainting, then the details. In each round they look at the whole and change it. Patton's warning matters too: most teams that call themselves "iterative" never plan to iterate, that is, they never set aside time to rework something.

Plan A is purely incremental. At the end of the first iteration payment really works, but there is no information about shipping or returns; you learn in week six whether the payment design conflicts with shipping. Plan B is purely iterative. You see how the three parts connect in the first two weeks, but at the end of the first iteration no part is complete enough to give to the customer. Cockburn's advice is to use both together: in every iteration, add a new part and rework the earlier ones.

Walking Skeleton: Where Does Bookstore's Checkout Start?

The practical way to combine the two is a walking skeleton. The term is Cockburn's: the thinnest possible implementation of the system that performs a small end-to-end function. It passes through every architectural layer, but each layer has only as much code as it needs.

In Bookstore's checkout, the first week of the first iteration goes to this: a single "Complete order" button in Angular, the ASP.NET Core 10 endpoint that button calls, a single record written to the Order table with EF (Entity Framework) Core, and all of it going through the CI (Continuous Integration) pipeline and being deployed to staging. No payment, no shipping, no returns. But now it is known that every layer is connected and that the build and deployment work. If a deploy permission is missing or a database migration doesn't run on staging, those show up in the first week.

The following iterations add slices to the skeleton: a real test payment with the payment provider in the second iteration, the shipping fee calculation and delivery event in the third, returns in the fourth. That is the incremental part. Revisiting the previous slice in every iteration is the iterative part: the payment slice initially supported only one card type, and it was reworked to include the shipping fee in the payment amount when the shipping slice was added. This rework is not a mistake but a step in the plan.

The Spiral Model: A Loop Whose Rounds Are Set by Risk

In his paper published in IEEE Computer in 1988, Barry Boehm took the iterative idea one step further: let risk, not documents or code, decide how many times the loop turns and what is done in each round. Boehm presented this as a risk-driven approach in contrast to document-driven and code-driven processes.

Each round of the spiral goes through four activities. First the round's objectives, alternatives and constraints are determined. Then the alternatives are evaluated and the biggest risks are identified and resolved; prototypes, simulations or benchmarks are used for this. Next the next-level product is developed and verified. Finally the next round is planned and the stakeholders decide whether to continue. The spiral's outward growth represents cumulative cost: every round is more expensive, so risk needs to be resolved in early rounds, while it is cheap.

Applied to Bookstore's checkout, the first round's question is: what is most likely to go wrong in this project, and what would be most expensive if it did? If the answer is the payment provider integration, the first round goes not to a screen design but to a small prototype that tries the 3-D Secure (additional cardholder verification) flow in the provider's test environment. As risk decreases, the rounds turn to more mature versions of the product. That is why Spiral is less a "model" than a frame that lets you choose how much of which model to use based on risk; in the paper Boehm explains that with the right risk profile the spiral can also turn into a path resembling Waterfall.

Prototyping and RAD

The prototype, Spiral's tool for resolving risk, is built for two different purposes, and confusing them is expensive. A throwaway prototype is written to answer a question and thrown away once the answer is in: like a console application that answers the question "does the payment provider's webhook really arrive within 30 seconds?" An evolutionary prototype is written to become the product and is grown from the start with production-quality tests, error handling and observability. A walking skeleton is an example close to the second kind.

In the early 1990s James Martin's RAD (Rapid Application Development) approach put prototyping at the center: intensive workshops with users, short development cycles fitted into timeboxes, and tools for quickly producing screens. RAD's most lasting idea is the timebox, which fixes time and keeps scope variable; this idea lives on in the sprints and iterations of Agile methods.

RUP: Four Phases and the Iterations Inside Them

In the late 1990s Rational Software's RUP (Rational Unified Process) packaged iterative development at enterprise scale. RUP splits a project into four phases: Inception (the business case and scope become clear), Elaboration (architectural risks are resolved and a working architectural skeleton appears), Construction (most features are developed in iterations) and Transition (the product is handed over to users, with beta and training). Each phase consists of one or more iterations, and in every iteration requirements, design, implementation and testing happen together; only their weight changes from phase to phase.

RUP's Elaboration phase is the process-language counterpart of the walking skeleton idea: getting the architecture running early, including its risky parts. The often-criticized side of RUP was that it was a comprehensive process catalog; many organizations tried to apply everything in the catalog and ended up with a heavy process. The idea behind the phases and risk-driven iterations still holds.

Production Notes

The best measure of whether an iteration really is one is the product at its end. If at the end of the iteration there is no increment that is integrated, tested and deployed at least to staging, those two weeks are a planning unit, not a feedback loop. The Bookstore team made it a rule that on the last day of every iteration one person tries the checkout end to end on staging, against the real payment provider's test environment.

The safe way to take unfinished slices to production is a feature flag. The payment slice is deployed to production but enabled only for internal users; this separates deployment from release. The details of this technique are in the CI/CD Fundamentals series and in the engineering practices post of the Scrum series.

Plan the rework. A team that doesn't set aside part of every iteration's capacity for improving earlier slices isn't working iteratively, only incrementally. Patton's suggestion is simple: write a separate backlog item for every revision you expect.

Common Pitfalls

A mini-Waterfall under the name of iteration is the most common pitfall. If the first three days of a two-week iteration are analysis, the next five coding and the last two testing, all of Waterfall's problems are lived in a smaller form: testing gets squeezed into the last days and the defects found slip into the next iteration. The anti-patterns post of the Scrum series covers this situation under the name "mini-Waterfall sprint".

The second is a prototype turning into production code. A prototype written as throwaway looks great in the demo, and someone says "it already works, let's use it". Code without tests, error handling or logging thus becomes the foundation of the product. Declare the prototype's kind up front while writing it, and keep the throwaway one in a separate repo.

The third is incremental without integration. If slices are developed separately and combined at the very end, the team has split Waterfall's late integration risk into slices, but hasn't removed it.

The fourth is applying Spiral as an obligation to produce a heavy risk analysis document every round. Risk analysis is the answer to a question, not a document template.

A Small Experiment

★☆☆ Look at your team's last two weeks: how much of the work was adding a new slice, and how much was reworking an existing one? If the second share is zero, are you really working iteratively?

★★☆ Describe a walking skeleton for the system you work on: which layers does it pass through, what does it prove in the first week, which risks does it surface?

★★★ Write down the three biggest risks of your upcoming project and, for each, design a prototype for Spiral's first round that takes at most two days. Which prototypes should be throwaway, and which evolutionary?

Every model we have seen from Royce to Spiral gives a different answer to the same question: how long does it take for feedback to arrive? In the next post we explain how that time shrank from months to hours, the conditions that gave rise to the Agile Manifesto and DevOps, and how that shrinking is measured.