Agile Foundations: Iterative Development & What the Manifesto Actually Says

The Software Development Lifecycle

Chapter 2 · Agile Foundations: Iterative Development & What the Manifesto Actually Says

"Agile" is one of the most cited and least directly read documents in software. This chapter reads the actual 2001 Manifesto for Agile Software Development — four values, twelve principles, written by seventeen practitioners in one room — rather than the secondhand version most teams inherit. Then it verifies, with real numbers, what iterative delivery actually buys over the waterfall model the Manifesto was written against.

The Four Values, Read Directly

Each value is a preference, not a rejection — the Manifesto itself is explicit that the item on the right still has value, just less than the item on the left:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

The Manifesto is explicit that the items on the right still carry real value — as it puts it, "value the items on the left more" — a genuinely balanced statement, not the all-or-nothing reading it's often given secondhand.

The Twelve Principles, Paraphrased Accurately

Twelve principles expand on the four values. Summarized faithfully rather than quoted at length:

  1. Satisfying the customer through early and continuous delivery of valuable software is the highest priority
  2. Changing requirements are welcomed, even late in a project
  3. Working software is delivered frequently, on a timescale of weeks rather than months
  4. Business people and developers work together daily throughout the project
  5. Projects are built around motivated individuals, given the environment and trust to get the job done
  6. Face-to-face conversation is the most effective way to convey information within a team
  7. Working software is the primary measure of progress — not documentation, not a plan being on schedule
  8. Development should proceed at a sustainable pace the team can maintain indefinitely
  9. Continuous attention to technical excellence and good design supports agility over time
  10. Simplicity — maximizing the amount of work not done — is essential
  11. The best designs and architectures emerge from self-organizing teams, not top-down specification
  12. At regular intervals, the team reflects on how to improve, then adjusts
Notice what isn't here
Scrum, sprints, story points, standups, and Jira boards appear nowhere in these twelve principles — none of them existed as fixed prescriptions in the original document. They're all specific, later implementations of these principles, covered starting next chapter. Confusing a specific implementation (Scrum) with the underlying values is exactly the drift this chapter exists to correct.

Iterative Delivery, Verified Against Waterfall

# a misunderstood requirement (prices assumed in dollars, actually in cents) # baked into every feature built before it's caught N_FEATURES = 20 # WATERFALL: all 20 built before any external feedback # ITERATIVE: feedback gathered after every batch of 5
Verified directly — checking in after 5 features instead of 20 avoided 75% of the project's own rework
Under waterfall (feedback only after all 20 features are delivered): 20 of 20 features (100%) needed rework once the misunderstanding was discovered. Under iterative delivery, checking in after every batch of 5: the mistake was caught after the first batch, so only 5 of 20 (25%) needed rework — the remaining 15 were built correctly from the start. 75% of the total project's own rework was avoided, purely by delivering and checking in earlier.

Responding to Change, Verified in Delivered Value

Verified directly — a re-prioritizable backlog delivered 12.5% more value than a fixed plan, given identical capacity and identical new information
A fixed plan locked in at the start (features A, B, C — the three highest-value items known at the time) delivered a total value of 24. A backlog re-prioritized after feature A shipped — incorporating a newly discovered, higher-value opportunity (feature X, worth 9) ahead of the original plan's lower-priority items — delivered 27, using the exact same total capacity (3 features). Both plans knew about feature A before starting; only the re-prioritizable backlog could act on feature X once it was discovered.
This isn't "change is always good" — it's "the option to change has real, measurable value"
The fixed plan wasn't wrong when it was made — A, B, and C were genuinely the best-known choices at the time. The 12.5% gap exists entirely because new information arrived mid-project, and one process could incorporate it while the other, having already committed, could not until a future release cycle.

Where This Connects

This chapter's findingWhat it connects to
75% of project rework avoided by checking in earlyChapter 1's own "cost of no process" findings — early feedback is itself a lightweight process, not a heavyweight one
A re-prioritizable backlog delivering measurably more valueChapter 6's own estimation material — a backlog can only be re-prioritized if its items are estimated comparably in the first place

Hands-On Exercises

Exercise 1

Re-run this chapter's own waterfall-vs-iterative simulation with a checkpoint size of 2 instead of 5 (feedback gathered after every 2 features, not every 5). Determine the new rework count and percentage, and explain whether smaller checkpoints keep producing proportionally better results or hit a floor.

📄 View solution
Exercise 2

Using this chapter's own re-prioritization simulation, change the new opportunity's value from 9 to 3 (a much less compelling discovery). Determine whether the re-prioritizable backlog still outperforms the fixed plan, and explain what this reveals about when responding to change actually helps versus when it doesn't.

📄 View solution
Exercise 3

This chapter's own waterfall-vs-iterative simulation assumed the misunderstanding was caught at the very first checkpoint. Modify it so the mistake isn't caught until the second checkpoint (after 10 of 20 features), and determine the new rework percentage.

📄 View solution

Chapter 2 Quick Reference

  • Four values: individuals/interactions, working software, customer collaboration, responding to change — each a preference, not a rejection of the alternative
  • Twelve principles: early/frequent delivery, welcoming change, daily collaboration, sustainable pace, technical excellence, simplicity, self-organization, regular reflection
  • Verified: checking in after 5 features instead of 20 avoided 75% of a project's own rework once a misunderstood requirement was discovered
  • Verified: a re-prioritizable backlog delivered 12.5% more value than an identically-sized fixed plan, given the same new information
  • What "agile" often means in practice vs. the original text: Scrum ceremonies, story points, and specific tools are implementations built on these principles — not the principles themselves
  • Next chapter: Scrum in Practice — sprints, roles, and ceremonies, one specific implementation of these values