Iteration

Iteration is software's native motion: build a small piece, put it in front of reality, adjust, repeat. The word sounds like mere repetition — it is actually compounding: each loop starts from what the last one learned. Almost every modern delivery practice is a machine for shortening this loop.

What It Is

Iteration is the practice of delivering in repeated cycles, each incorporating feedback from the last: build-measure-learn, repeated. In engineering it appears as sprints and increments; in product, as MVP-to-validated-learning loops; in design, as prototype-test cycles; in operations, as the improvement kata. What distinguishes iteration from rework is the feedback discipline — each cycle is deliberately shorter than the risk horizon it serves, so course corrections happen before sunk cost accumulates. The counter-model is the big-bang delivery: one long build, one reveal, one expensive moment of truth.

Why It Matters to You

Iteration is the executive's structural answer to the oldest problem in technology: nobody — not users, not product owners, not founders — fully knows what they want until they use it. Iteration prices that discovery cheaply; big-bang delivery prices it catastrophically. The governance implication is budgeting: iterative programmes are funded by slices (prove this, then fund the next) rather than by full specification up front — uncomfortable for annual planning, dramatically better for hit rate. The failure mode is iteration without convergence: loops that generate feedback no one acts on, forever, which is churn wearing iteration's clothes.

When You'll Meet It

In planning models, budget design, and delivery reviews. The test of a healthy iterative programme: are the loops short, is feedback actually changing direction, and is there a stated theory of convergence?