A3.1 · Agile, distilled · dive 1
The values
The Agile Manifesto is four value preferences — each names a thing valued more and a thing valued less. Two of the four are the engine of the loop.
A value is a tie-breaker, not a rule: a stated preference that biases a decision under uncertainty. The loop is built on two of them — working software over comprehensive documentation, and responding to change over following a plan. Switch the view on the right to weigh each value by how load-bearing it is for the loop.
The four values · weighed by the loop
Four preferences, not four rules
The Agile Manifesto states four preferences, each in the form X over Y. The form matters: the right side still has value, but when the two pull against each other, the left side wins. They are not commandments and they are not a process — they are tie-breakers for decisions made under uncertainty.
Two of the four are what make the Author/Operator loop turn. Working software over comprehensive documentation says a rung is judged by running software, not by the document around it — the loop's ship. Responding to change over following a plan says feedback re-orders the work between rungs — the loop's adapt. The other two — customer collaboration and individuals over processes — steady the roles, but they are not the engine.
- a value
- A stated preference, “X over Y” — a tie-breaker that biases a decision under uncertainty, not a rule and not a process.
- working software
- Over comprehensive documentation: a rung is judged by running software. Load-bearing — the loop's ship.
- responding to change
- Over following a plan: feedback re-orders the work between rungs. Load-bearing — the loop's adapt.
- the other two
- Customer collaboration and individuals over processes: supporting — they steady how the roles meet, but they do not turn the loop.
A value is the coarsest layer of Agile: it tells you which way to lean. The next dive takes the engine those leanings drive — inspect-and-adapt.
Each value, read as a loop move
A value is abstract until it names a concrete move. The loop runs sharpen → build → ship → demo → review → feedback → adapt, and four of those stages are exactly where a value lands: ship honours working software, adapt honours responding to change, sharpen honours customer collaboration, and review honours individuals over processes — the human judges, the tools assist.
Select a stage to read which value it honours. Reading the values this way — as moves rather than slogans — is what keeps them load-bearing: a value that does not name a stage the loop runs is not doing any work here.
A loop stage · which value it honours
A value earns the word load-bearing only when it names a stage the loop runs — ship, adapt, sharpen, review.
The values on the Portal
On the Portal — the learning platform this course builds — the web chapter F6 climbs nine rungs. Each rung ships running web surface, not a design document: F6.1 serves the engine as a web app, F6.5 renders the catalog, F6.6 makes it interactive. That is working software over comprehensive documentation, made concrete as the loop's ship.
Between rungs, the roadmap is re-ordered by feedback — the F6 plan even carries a feedback column (“route shape and scopes right?”, “does the interaction feel right?”) so the next rung's specs can change before it is built. That is responding to change over following a plan, made concrete as the loop's adapt. Two values, two moves, run every rung.
# F6 — the Portal on the web — runs the loop per rung, and two Agile values name two moves. # working software over comprehensive documentation → the loop's "ship" # F6.1 ships the engine served as a web app; F6.5 ships the rendered catalog. id = Portal.ID.generate(:course) # running software, not a doc about it # responding to change over following a plan → the loop's "adapt" # feedback ("route shape right?") re-orders the roadmap and edits the next rung's spec. assert Portal.ID.decode(id).type == :course
The principle
Prefer working software and responding to change; the other two values are tie-breakers that steady the roles, not the engine that turns the loop.
On the Portal
On F6 each rung ships running web surface (working software) and the roadmap is re-ordered
by feedback (responding to change) — the two load-bearing values made concrete as ship
and adapt.
Two of the four Agile values run the loop; the other two steady the hands that run it.
Recap — the engine values
The Agile Manifesto is four preferences, each “X over Y”. Two are load-bearing for the Author/Operator loop — working software becomes ship, responding to change becomes adapt — and the other two steady how the roles meet. Read as moves rather than slogans, a value is doing work only when it names a stage the loop runs. With the values fixed, the next dive takes the engine they drive.
Next in A3.1: A3.1.2 · Inspect and adapt — the empirical engine under every Agile practice, and what the loop adapts (the spec, not the demo).
References
The sources for the values and the small-batch, feedback-driven delivery they imply, and where the loop they drive is drawn in the course.
Sources
- Beck, K. — Extreme Programming Explained — the values behind Agile and the practices that follow from them.
- Humble, J. & Farley, D. — Continuous Delivery — working software, kept releasable at every increment.
- Hunt, A. & Thomas, D. — The Pragmatic Programmer — responding to change as a craft discipline.
Related in this course
- A3.1 · Agile, distilled — the module hub.
- A3.1.2 · Inspect and adapt — the next dive.
- A1.03 · The Author/Operator loop — the loop these values drive.
- A1 · Why an Agile Agent Workflow — the case for thin slices.
- A3 · The roadmap layer — the plan these values re-order.
- Companion · Phoenix (F6) — the rungs that ship running software.