03 Life-Cycle Models When Iteration Is Cheap

Learning objectives

After this chapter you should be able to:

1. Explain what Royce (1970) actually argued, and what sets phase boundaries and loop length in the V-model, incremental delivery, the spiral, Scrum and XP.
2. Explain the cost-of-change curve and the evidence for and against it.
3. State the load-bearing assumption of classical life-cycle models and show with the negation test why it is load-bearing.
4. Distinguish a code-generation cycle from a stakeholder-feedback cycle and a release cycle, and say which one agents shorten.
5. Size a loop from review capacity as a conditional model, place human gates, and audit a pipeline with the "while you sleep" test.
6. State what evidence would overturn the verdict.

Opening case

A composite case, not a real engagement.

A consultant and two engineers are building an internal dispatch dashboard for a regional logistics company. The client runs every project in two-week sprints, so the team does too. Planning follows the usual rule: pull in what the team's velocity says it can build. That velocity comes from a project before the team used coding agents, and everyone has watched an agent produce a working feature in an hour. The team pulls in the whole backlog, because the arithmetic says construction will be finished by Tuesday.

The chapter continues from here.

What the chapter covers

1. 3.1 The classical method
   • 3.1.1 Royce, read closely
   • 3.1.2 The V-model, and when plan-driven is the right call
   • 3.1.3 Incremental delivery and the spiral model
   • 3.1.4 Agile: the manifesto, Scrum and XP
   • 3.1.5 The cost-of-change curve, and the economics under every model
   • 3.1.6 What the classical models got right
2. 3.2 The assumption it depends on
3. 3.3 What agents change
   • 3.3.1 The code-generation cycle runs in minutes, and the expensive part moved
   • 3.3.2 Practices once unaffordable return
   • 3.3.3 The automation ladder: risk relocates
   • 3.3.4 Gates at decision points, and the 51st approval
   • 3.3.5 Autonomy levels and checkpoints
4. 3.4 The verdict
5. 3.5 What replaces it: design the life cycle around review attention
   • 3.5.1 Sizing a loop: a conditional model
   • 3.5.2 Placing gates
   • 3.5.3 Worked example: a Dispatch sprint redesigned
   • 3.5.4 The "while you sleep" audit
   • 3.5.5 Spec-first: a waterfall front end without the step list
6. 3.6 Lab: Map your human touchpoints
7. 3.7 What would make this verdict false

Lab and prediction

The lab tests this prediction from the working paper the book grows from (Smith 2026a):

• P1 Share of human hours on review and verification exceeds the share on construction from the first milestone on

A result that contradicts a prediction, honestly reported, is a result. You are graded on accurate records and reasoned interpretation, not on agreeing with the book.

Summary

• At their strongest (Royce's five additions, the spiral's risk analysis and commitment review, Scrum's Definition of Done, XP's flat cost of change), classical models set phase boundaries, loop length and gates by the cost of rework, which was the cost of builders' time.
• Agents shorten the code-generation cycle to minutes. They do not shorten the stakeholder-feedback or release cycles, which people and policy pace.
• Load-bearing assumption: iteration is expensive, so phase boundaries and loop length are set by the cost of rework. Verdict: recalibrate. Where review binds, the quantity that sizes a loop changes from builders' capacity to review capacity.
• Replacement: a conditional sizing rule, W ≤ h × T / k; human gates at decisions and irreversible actions; and the audit "would this reach the next decision gate unattended?"
• The cost-of-change curve splits: regenerating is cheap, while re-verifying and changing shipped decisions are not.
• Evidence is indirect, and I know of no study that measures loop length against reviewer capacity; the lab does.

Key terms

Loop / loop length

one pass from decision to evidence, and its calendar time.Also used in 2, 7

Phase boundary

what must be settled before the next kind of work begins.

Code-generation cycle

the loop from a specification to code and its checks.

Stakeholder-feedback cycle

the loop from a working increment to a decision by the people it is for.Also used in 4

Release cycle

the loop from a merged change to use in production.

Cost-of-change curve

the claim that the cost of fixing a defect or decision rises the longer it persists.

Decision gate / execution gate

a human choice among alternatives the pipeline cannot rank; a human approval of work the pipeline is doing as designed.

Verification load (k)

hours of review and verification, with rework, per delivered line.

Review capacity

the hours per week reviewers can give (h), and what they can verify in a loop (h × T / k).Also used in 6, 7, 9

Change rate

the share of approvals at a touchpoint after which the human changed or rejected the work.

Read-time ratio

observed time to approve divided by the time reading would take at your review rate.

Connections

Where this chapter and another point to each other most often.

• Chapter 2: The Assumption Audit: A Method That Outlasts the Tools
  The load-bearing assumption is: > Iteration is expensive, so phase boundaries and loop length are set by the cost of rework. It is an assumption about the process (Chapter 2).
• Chapter 4: Requirements as the Primary Artifact
  Chapter 4 treats clarification as a capability a workflow can require.
• Chapter 6: Cost and Schedule Estimation After COCOMO
  It is the schedule bound of Section 6.5.2 applied to one loop.
• Chapter 7: Project Management and Where Value Is Earned
  Where review binds, the slot in sprint planning that held builder capacity holds reviewer capacity, and "done" moves from code-complete to verified (Chapter 7).
• Chapter 16: Roles and the Four Conditions for Assurance
  Name the conditions of Chapter 16 you would require. ## Claim audit Hassan (2026, §6.4.9, p. 196) states that humans who must approve 50 routine transitions "will rubber-stamp the fifty-first." Find the evidence for a threshold of this kind.
• Chapter 18: Running the Whole Life Cycle: The Engineer as Manager of an Agent Team
  From Chapter 18: That is prediction P1 (Smith 2026a): from the first milestone on, review and verification hours exceed construction hours (prompting, hand-coding and debugging; Chapter 3).

See it on the map

Further reading

• Royce (1970), "Managing the Development of Large Software Systems." Nine pages. Read the five steps and Figures 3 and 4, then say whether it describes the "waterfall" you were taught.
• Boehm (1988), "A Spiral Model of Software Development and Enhancement." The typical cycle, the TRW example and the transform model.
• Schwaber and Sutherland (2020). The Scrum Guide: the Definition of Done, and the separation of review from release.
• Parasuraman, Sheridan and Wickens (2000). Types and levels of automation, with the human-performance consequences of each.
• Menzies et al. (2017). An empirical test of the cost-of-change curve.