Iterative and Incremental Development: A Brief History
Full text: author page ↗
Larman and Basili walk through forty years of software projects that used iterative and incremental development — from Mercury and the early space programme through shuttle avionics to the first large commercial systems — and demolish the myth that iteration is a recent invention of "agile".
The paper's value is historical and polemical in equal parts: every practice celebrated today was already practised somewhere, and the dominance of waterfall was always narrower than the literature suggested.
For product direction the piece is humbling — many of the "new" ideas you are asked to adopt are older than most organisations adopting them.
It is a useful antidote to amnesia. Read it right after Royce and the picture of how the industry confused itself for decades becomes vivid.
Central argument
Larman and Basili argue that iterative and incremental development is not a modern invention born from the agile movement, but a practice with documented roots stretching back to the 1930s PDSA cycles of Walter Shewhart and confirmed software applications from the late 1950s onward. Their central finding is that the framing of IID as a 'replacement' for waterfall inverts the actual history: waterfall was the deviation, not the norm. They demonstrate this through a chronology of real projects—NASA's Project Mercury, IBM FSD's Trident submarine system, TRW's ballistic missile defense software—showing that large, life-critical systems were successfully delivered iteratively decades before Scrum or XP had names.
Critique
The paper's chronological structure prioritizes existence over causation: it documents that IID was practiced but does not rigorously analyze why waterfall nevertheless became the dominant institutional and contractual norm through the 1970s–1990s. This is a meaningful gap—if IID was so well-established and demonstrably successful, the more interesting and practically useful question is what organizational, procurement, and regulatory forces systematically suppressed it. Without that analysis, the history risks functioning as a rhetorical device to grant agile methods legitimacy rather than as a genuine explanatory account.
Why it matters for product
For a CPO, the most operationally relevant implication is that resistance to iterative delivery within organizations is rarely technical or epistemic—it is structural, rooted in contracting models, governance gates, and risk-accounting practices that were layered on top of a field that never actually needed them. This reframes the product leader's job when pushing for shorter cycles or continuous delivery: the obstacle is not convincing people that iteration works, but dismantling the institutional scaffolding—stage-gate funding, annual roadmap commitments, fixed-scope contracts—that encodes a waterfall logic regardless of what teams believe. The LAMPS project's 45 one-month time-boxed iterations on a 200-person-year defense program also serves as a concrete historical counterargument when stakeholders claim that 'our domain is too complex or regulated for agile delivery.'