A3.1 · The roadmap layer
Agile, distilled
Working software in short cycles, responding to change, inspect-and-adapt. A handful of principles actually drive the workflow — separated from the ceremony that does not.
Most Agile process exists to coordinate a team of people. The Author/Operator pair is not a team, so a lot of that process is ceremony here — not wrong, only answering a problem the pair does not have. This module keeps the load-bearing few, each of which names a concrete move in the loop, and drops the rest. Three dives: the values, the inspect-and-adapt engine, and what we keep versus what we drop — all landed on the Portal.
Load-bearing, or ceremony
There is a single test for whether an Agile principle earns its place in this workflow: does it name a move the Author/Operator loop already needs? The loop runs sharpen → build → ship → demo → review → feedback → adapt on every rung. A principle is load-bearing when it drives one of those moves, and ceremony when it adds process around the loop without adding a move.
Select a principle below. The readout reports its kind and, if it is load-bearing, the loop move it drives; the dataset holds eight principles, five load-bearing and three ceremony. The default selection is responding to change — the value that becomes the loop's adapt.
Classify a principle · does it drive a loop move?
A principle earns its place by naming a move in the loop. Everything else is ceremony the pair can drop without losing a thing the loop needs.
The principle
Keep only the principles that drive a move; drop the ceremony that does not. The test is whether a practice adds a move the one-agent / one-reviewer loop already needs.
On the Portal
The F6 roadmap runs sharpen → build → ship → demo → review →
feedback → adapt per rung — five load-bearing principles, each a named move; the team
rituals are dropped for the Author/Operator pair.
Agile distilled is the handful of principles that name a move in the loop — the rest is ceremony.
The three dives
Each dive takes one part of the distillation, in the arc the values → the engine → the sort: the four Agile values and which the loop relies on, the inspect-and-adapt engine under every practice, and the keep-versus-drop test for a one-agent pair. Read them in order — A3.1.1 starts.
The values
The four Agile value preferences, and the two the loop is built on: working software in short cycles, and responding to change. Each value read off as a loop move.
Inspect and adapt
The empirical engine under every practice: build, inspect, adapt the plan. On the Portal it is
demo → review → feedback → adapt — and the spec is what adapts.
Keep vs ceremony
The sort: keep what drives a loop move, adapt what survives in a one-pair form, drop the team coordination the Author/Operator pair does not need.
After A3.1, the next module — A3.2 · Extreme Programming for small batches — takes the kept set further: why small releases lower risk and raise learning, re-cast for an Author/Operator pair. Return to the A3 module navigation to continue.
References
The Agile tradition this module distils — small batches, continuous feedback, and the first thin increment — and where the loop it lands on is drawn in the course.
Sources
- Humble, J. & Farley, D. — Continuous Delivery — working software in short cycles, kept releasable at every increment.
- Beck, K. — Extreme Programming Explained — the values, small batches, and the inspect-and-adapt loop.
- Hunt, A. & Thomas, D. — The Pragmatic Programmer — pragmatism over ceremony: keep what earns its place.
Related in this course
- A3.1.1 · The values
- A3.1.2 · Inspect and adapt
- A3.1.3 · Keep vs ceremony
- A1.03 · The Author/Operator loop — the loop these principles drive.
- A1 · Why an Agile Agent Workflow — the case for thin, provable slices.
- A2 · Decomposition — the backlog the loop runs on.
- A3 · The roadmap layer — the artifact that orders this delivery.
- Companion · Phoenix (F6) — the real chapter run on this cadence.
- Companion · Functional Programming in Elixir — the Portal’s foundations.