Progress iteratively with feedback

Large changes delivered in one piece are risky. By the time they arrive, needs may have changed, problems may have been built in from the start, and the investment may be too large to abandon even when it is clearly failing. The third guiding principle offers an alternative: break work into smaller pieces that can be completed in a short time, deliver each one, gather feedback and use it to steer the next. This lesson explains how iteration and feedback work together, how to size iterations, how to design useful feedback loops and how to avoid the trap of iterating without learning.

What the principle asks

Progress iteratively with feedback means: resist the temptation to do everything at once. Even huge initiatives must be accomplished iteratively. Organizing work into smaller, manageable sections that can be executed and completed in a timely manner keeps the focus sharper on each effort. Feedback before, during and after each iteration ensures that actions are focused and appropriate, even when circumstances change.

Applying the principle involves:

• Comprehending the whole, but doing something: understanding the overall goal without waiting for a perfect plan before starting.
• Recognizing that the ecosystem is constantly changing, so feedback is essential to stay on course.
• Understanding that fast does not mean incomplete: each iteration should deliver something usable.
• Designing feedback loops so that information returns quickly to the people who can act on it.

Iterations and feedback loops

An iteration is a set of activities designed to produce a specific, valuable result in a fixed period. Iterations can exist at many levels. A whole program can be broken into phases; each phase into releases; each release into sprints or work items. At each level, the pattern is the same: plan a little, do it, check the result and adjust.

A feedback loop is a situation in which part of the output of an activity is used as new input. Feedback can come from consumers (do they find the change useful?), from operations (does it run reliably?), from data (did the measure move?) and from the team itself (what slowed us down?). The shorter the loop, the sooner the organization learns and the cheaper it is to correct mistakes.

Why iteration reduces risk

Iteration reduces risk in several ways. Problems are found earlier, when they are cheaper to fix. Value is delivered sooner, so the organization benefits even if later iterations are canceled. Plans can change as understanding improves, rather than being locked in at the start. And the organization can stop an initiative that is not working after a small investment rather than a large one.

How big should an iteration be?

There is no single answer. Iterations should be large enough to produce something useful and small enough that feedback arrives while it can still shape the next step. Factors to weigh include the cost of each release (if every release needs lengthy testing, very small iterations may be uneconomic), the pace at which the environment changes, and how quickly consumers can give meaningful feedback.

Prioritizing what goes into each iteration

If work is delivered in pieces, the order matters. A common technique is to prioritize by value relative to effort, or by Weighted Shortest Job First (WSJF), a method from the Scaled Agile Framework. WSJF divides the cost of delay of each item by its job size, so items that deliver much value quickly come first.

The formula is \( \text{WSJF} = \dfrac{\text{cost of delay}}{\text{job size}} \). It is a heuristic, not a law: scores are judgments, and the method works best when the people scoring discuss and agree on them.

Designing good feedback

Feedback is only useful if it is timely, relevant and acted on. Some practical guidelines:

• Decide before each iteration what feedback you will collect and how you will judge success.
• Collect feedback from the people affected, not only from those who requested the work.
• Shorten the delay between action and feedback; a monthly report is too slow for a weekly iteration.
• Make sure feedback reaches the people who can act on it, and that they have the authority to change course.
• Close the loop: tell those who gave feedback what was done with it, so they keep giving it.

Iterating without learning

Iteration is not valuable in itself. A team that runs two-week sprints but never reviews the results, never changes direction and never talks to consumers is merely dividing work into chunks. The value comes from the feedback. Typical signs of trouble include retrospectives that produce the same actions every time, feedback collected but never read, and plans that never change despite new information.

There is also an opposite trap: changing direction so often that nothing is completed. The principle says "fast does not mean incomplete". Each iteration should finish something usable before the next begins, so that value accumulates.

Links to Agile, DevOps and Lean

This principle is closely aligned with Agile methods, such as Scrum, which deliver work in short sprints with reviews and retrospectives; with DevOps, which uses automation and monitoring to shorten feedback loops from production; and with Lean, which emphasizes small batch sizes and rapid learning. The continual improvement model in lesson 11 is itself iterative: each improvement is one turn of a loop that the organization repeats over time.

Iteration in operations, not only projects

The principle is often associated with software development, but it applies just as well to operational work. A service desk can introduce a new knowledge article format for one category of incidents, check whether first-contact resolution improves, and then extend it. A change management team can trial delegated approval for one type of low-risk change for a month before widening it. A supplier relationship can be improved through quarterly reviews, each agreeing one or two improvements rather than renegotiating everything at once.

In each case the pattern is the same: a small, reversible step, a clear measure of success decided in advance, a short period of operation and a review that decides whether to continue, adjust or stop. Small operational experiments like these carry little risk, build confidence and generate evidence that makes larger decisions easier.