A3.2 · Small batches · dive 3
Continuous feedback
The third Extreme Programming practice: a review after every increment, not at the end. The loop closes between rungs, so a wrong assumption is caught one rung deep rather than nine.
Continuous feedback is the practice that makes the other two pay: small releases and incremental design lower risk only if a reviewer is in the loop at every release. Set how often a review fires on the right and watch the feedback rounds and worst-case rework move over the Portal’s F6 ladder.
Review points on the F6 ladder · set how often
Reviewing after every rung catches a wrong assumption one rung deep; the fewer rungs between reviews, the less rework a wrong assumption can cause.
What continuous feedback is
Continuous feedback is a review after every increment, not one review at the end. After a rung ships, it is demoed, reviewed, and the review returns feedback — before the next rung is planned. The full per-rung loop is sharpen → build → ship → demo → review → feedback → adapt. Closing the loop every rung means a wrong assumption surfaces with one rung built on it, not nine; the worst-case rework is the number of rungs between two reviews.
The practice carries one rule about where feedback lands: feedback edits the spec, the single source of truth, and the build follows the spec. Feedback never patches a shipped page in isolation. That rule is what keeps the source of truth from forking — the subject of the next section. Continuous feedback is what makes small releases and incremental design pay: both lower risk only because a reviewer meets the work at every release.
- continuous feedback
- A review after every rung, not one review at the end.
- the loop
- Per rung: sharpen → build → ship → demo → review → feedback → adapt.
- worst-case rework
- Rungs built on an unreviewed assumption between two reviews — one rung when the review fires every rung.
- feedback edits the spec
- Feedback changes the single source of truth; the build follows the spec, and no shipped page is patched in isolation.
Continuous feedback only protects the system if the feedback lands in the right place; the next section renders what happens when it edits the spec versus when it patches the shipped page.
Where feedback lands
A review surfaces a wrong assumption, and there are two places the feedback can land. It can edit the spec — the single source of truth — and let the build follow, so every downstream artifact is regenerated from one place. Or it can patch the shipped page directly, leaving the spec describing a system that no longer exists. The first keeps the source of truth single; the second forks it. Switch the choice to render which artifact stays authoritative and what drifts.
Feedback edits the spec, or patches the page · switch
Feedback that edits the spec keeps the source of truth single; feedback that patches the page forks it and the spec starts to lie.
Continuous feedback on the Portal
The F6 roadmap states the loop word for word: “sharpen → build → ship → demo → review → feedback → adapt. Feedback edits the spec, because the spec is the single source of truth; the build follows the spec.” Every rung carries one feedback question for the review to answer — F6.1 asks “shell and layout right?”, F6.5 asks “layout, UX, error wording?”, F6.7 asks “what should propagate; count semantics?” The Operator reviews the shipped increment and returns feedback asking for the next rung’s specs or a change to a shipped one.
The Author makes each round cheap. A Claude agent ships one PR-sized rung with a green harness, so the review meets working software at every release rather than once at the end — and the feedback it returns edits the spec, never the shipped page, so the source of truth never forks.
# The F6 loop, per rung (verbatim from phoenix.roadmap.md): # sharpen → build → ship → demo → review → feedback → adapt # Each rung asks ONE feedback question: # F6.1 shell and layout right? # F6.5 layout, UX, error wording? # F6.7 what should propagate; count semantics? # Feedback edits the SPEC — the single source of truth — and the build follows it. id = Portal.ID.generate(:event) # the rung ships, is demoed, and earns feedback before the next
The principle
Continuous feedback: review every increment, and let feedback change the definition — the spec — not the shipped artifact, so the source of truth stays single.
On the Portal
Each F6 rung runs the loop and asks one feedback question; feedback edits the spec, the build follows,
and the next rung is planned from it — the Author makes each round cheap.
Feedback after every rung catches a wrong assumption one rung deep; it edits the spec, never the shipped page, so the source of truth never forks.
Recap — the module closes
Continuous feedback reviews every increment and lets feedback edit the spec, not the shipped page, so a wrong assumption is caught one rung deep and the source of truth stays single. It is the practice that makes small releases and incremental design pay. Together the three — small releases, incremental design, and continuous feedback — are the cadence the F6 ladder runs at: nine rungs, each grown behind the facade, shipped, demoed, and reviewed before the next. A Claude agent makes that batch of one cheap enough to be the default. That closes A3.2.
Back to the module hub: A3.2 · Extreme Programming for small batches.
References
Primary sources for continuous feedback and the feedback loop, and where this dive connects in the course and to the real F6 chapter.
Sources
- Beck, K. — Extreme Programming Explained — continuous feedback and the inspect-and-adapt loop as core practices.
- Humble, J. & Farley, D. — Continuous Delivery — fast feedback at every increment as the discipline of releasable software.
- Hunt, A. & Thomas, D. — The Pragmatic Programmer — feedback loops and a single source of truth over duplicated, drifting copies.
Related in this course
- A3.2 · Small batches — the module hub.
- A3.2.2 · Incremental design — the previous dive.
- A1.03 · The Author/Operator loop — the cadence this feedback closes.
- A2.07 · Workshop — the run that produced the F6 ladder these reviews walk.
- Companion · Phoenix (F6) — the real ladder, reviewed one rung at a time.