Inspect and adapt

Strip a standup, a retro, or a sprint review down to what it is for and the same engine appears: build a thing, inspect what it revealed, adapt the plan in response. That is the empirical core of Agile — decisions made from what a real increment showed, not from a plan committed to up front. The ceremony around it is variable; the engine is constant.

The Author/Operator loop is this engine, run by two roles. Its first half — sharpen → build → ship — produces a running increment. Its second half — demo → review → feedback → adapt — is inspect-and-adapt by another name: the Operator demos and reviews what shipped, gives feedback, and the plan adapts. The unit inspected is always a shipped, running rung; the thing that adapts is the plan, not the rung that was demoed.

Inspection and adaptation act on different things, and conflating them is the common mistake. What you inspect is the shipped increment — the demo. What you adapt is the plan: the spec, the single source of truth, and the order of the roadmap. The demo is read, not written; it is evidence, not a target. And the code is never patched in isolation — a patch that does not land in the spec forks the code from the source of truth, and the spec starts to lie about the system.

Select a candidate below to see whether feedback adapts it. Two of the four candidates are valid adapt targets — the spec and the roadmap order; the demo and the code-in-isolation are not. This is the rule that keeps inspect-and-adapt honest: feedback edits the plan, and the increment is regenerated from it.

On the Portal — the learning platform this course builds — the web chapter F6 runs this engine every rung. The roadmap's iteration table names, per rung, the demo (“hit the root, see a page”, “browse the catalog; create with inline errors”) and the feedback asked (“shell and layout right?”, “layout, UX, error wording?”). The Operator inspects the shipped rung against that demo, gives feedback, and the plan adapts before the next rung is built.

Crucially, what adapts is the spec, never the engine under it. Every F6 rung calls only the Portal facade, so when feedback edits a rung's spec, the read model and supervision tree below the facade do not change to suit it. Inspect the web surface; adapt the rung's spec; the engine underneath stays still.

# F6 runs inspect-and-adapt per rung: build → ship, then demo → review → feedback → adapt.

# BUILD: a thin rung becomes running software over the Portal facade.
id = Portal.ID.generate(:course)   # the shipped increment to inspect

# INSPECT: the Operator demos and reviews — "layout, UX, error wording?"
assert Portal.ID.decode(id).type == :course   # judged against the spec

# ADAPT: feedback edits the SPEC, not the demo or the code in isolation; the roadmap re-orders.
#        the engine under the facade never changes to suit the feedback.

Inspect-and-adapt is the empirical engine under every Agile practice: build a thing, inspect what it reveals, adapt the plan. It is the loop's second half — demo → review → feedback → adapt — and the thing adapted is the plan: the spec and the roadmap order, never the demo or the code in isolation. With the engine fixed, the closing dive sorts the practices around it — what to keep, what to adapt, what to drop.

The empirical, feedback-driven tradition this engine comes from, and where the loop it names is drawn in the course.