Agile, explained with a thermostat: the customer doesn't know what they want, but they pay (and they're always right)

Monday, 9:36 a.m. The fifteen-minute daily stand-up has just ended, after forty-five. The perfect moment to talk about Agile, the methodology that starts from an honest and slightly awkward admission: the customer doesn't know what they want. And immediately adds another: but they pay, so they're always right.

It sounds like a contradiction. It isn't, and it's the most engineering-minded thing about Agile. First we'll explain it with control theory, then translate the jargon with a small Agile–English dictionary, and finally look at what the customer is really always right about (and what they aren't).

Agile in one sentence of control theory

Every engineer who has studied control systems knows the difference between open loop and closed loop. An open-loop toaster heats for two minutes, whatever happens to the bread. A closed-loop thermostat measures the temperature, compares it with the target and corrects. The first works as long as the world is exactly as predicted. The second works even when the world changes.

The waterfall model is an open-loop system: you write the specification at the start, plan the whole route and execute without measuring anything until delivery. Agile is a closed loop: you build a piece, show it (the sensor is the demo), measure the gap between what the customer wanted and what they saw, and correct. The sprint is the sampling period.

The key point is that the "set point" is not fixed: the customer changes their mind because the market changes, because competitors do something, and above all because seeing the software makes them realise what they actually want. It's a moving target. Here is a small simulation: the customer's wish drifts a little at random every day for a year, and we compare different strategies.

import random

def project(sprint, gain=0.7, months=12, seed=42):
    rnd = random.Random(seed)
    wish = product = 0.0
    error = 0.0
    days = months * 20                          # working days
    for d in range(1, days + 1):
        wish += rnd.gauss(0, 1)                 # the customer changes their mind, a little every day
        if sprint and d % sprint == 0:          # demo: measure the gap and correct
            product += gain * (wish - product)
        error += abs(wish - product)
    return error / days

# waterfall (frozen spec)                         mean gap:   10.9
# 2-week sprints                                  mean gap:    1.5
# 1-week sprints                                  mean gap:    1.0
# daily, giving in to every whim                 mean gap:  235371809.3

With other random seeds waterfall swings between 4 and 11, while sprints stay steadily around 1–2. The last line is the most instructive. A team that corrects every day with too high a gain (here 2.1, meaning it corrects by more than twice the measured gap) doesn't converge: it diverges. It's the team that does exactly what the last person to speak in the meeting said, and every day moves the product further than the wish actually moved. In control theory that's called instability. In a company it's called "priorities changed again".

Two lessons follow that are worth more than any certification:

1. If your feedback loop is longer than the time it takes the customer to change their mind, you're doing waterfall, whatever you call it.
2. Listening to the customer doesn't mean amplifying every signal. A good controller filters out noise.

The Agile–English dictionary

Waterfall — Ironic definition: how people used to work, badmouthed at every conference. Really: by an irony of history, the name comes from a 1970 paper by Winston Royce that described the waterfall model in order to criticise it. Royce wrote that the approach "is risky and invites failure" and recommended iterating, even "doing it twice". For years the industry quoted the diagram without reading the text.

Agile Manifesto — Ironic: a document signed by seventeen people at a ski resort. Really: that's exactly what it is. In February 2001, at Snowbird, Utah, seventeen developers wrote four values and twelve principles. The second principle explains everything: "Welcome changing requirements, even late in development." Changes aren't an accident to be avoided: they're the reason the process exists.

Scrum — Ironic: a rugby scrum where the ball is the backlog. Really: the name does come from rugby, via a 1986 Harvard Business Review article by Takeuchi and Nonaka about Japanese product teams. Schwaber and Sutherland formalised it at OOPSLA in 1995.

Sprint — Ironic: a marathon split into two-week chunks, each run at 100-metre pace. Really: a fixed time box at the end of which there is something working to show. It's the sampling period of the control loop: long enough to produce something measurable, short enough to change course before it's too late.

Backlog — Ironic: the graveyard of the customer's ideas, sorted by priority. Really: the ordered list of everything that could be done. The important word is "ordered": a backlog without priorities is just a wish list.

User story — Ironic: "As a user I want a button, so that there is a button." Really: the "As a <role> I want <what> so that <why>" format exists mainly for the why, which is precisely the part most often left empty. Without the why you can't propose a better solution than the one the customer imagined.

Story point — Ironic: a unit of measurement that measures nothing, but that everyone wants to convert into days. Really: a relative estimate of complexity, invented precisely to avoid converting to hours. Ron Jeffries, one of the Manifesto's signatories, wrote in 2019: "I may have invented story points, and if I did, I'm sorry now."

Velocity — Ironic: the number management compares across teams to see who works hardest. Really: a team's internal forecasting tool. As soon as it becomes a target, Goodhart's law kicks in: when a measure becomes a target, it ceases to be a good measure. Estimates inflate, velocity goes up, the product doesn't.

Daily stand-up — Ironic: fifteen minutes on your feet that last forty-five, after which everyone sits down exhausted. Really: a quick sync to find out who is blocked. It is not a progress report for the boss. If it becomes one, it also becomes long.

Sprint review (demo) — Ironic: the moment the customer sees the software and says "yes, but I meant something else". Really: that is exactly the point of the demo. That sentence isn't a failure: it's the sensor working. Finding out after two weeks is cheap. Finding out after eighteen months, at acceptance testing, costs a whole project.

Retrospective — Ironic: the meeting where you write the same problems as last time on sticky notes. Really: the second control loop, on the process rather than the product. If the agreed actions never get done, this loop is open too.

Definition of Done — Ironic: "Works on my machine." Really: the explicit list of what must be true for something to count as finished: tests, review, documentation, production release. Without it, "done" means different things to different people, and velocity measures how much work was left half-finished.

MVP (Minimum Viable Product) — Ironic: the version of the product with all the bugs and none of the features. Really: the smallest product that lets you learn something from the market (Eric Ries, The Lean Startup, 2011). Henrik Kniberg explained it with a famous drawing: if the customer wants a car, you don't deliver a wheel, then a chassis, then the bodywork. You deliver a skateboard, then a scooter, then a bicycle. Each version is usable, and each one teaches you something about the next.

Product Owner — Ironic: the person who translates "the customer is always right" into "the customer is always right, but one thing at a time". Really: that's exactly the role. The Product Owner is the filter in the control loop: they collect the signals (customer, users, market), remove the noise and decide the order. Without this role you're straight back to the 2.1 gain from the simulation.

Technical debt — Ironic: what piles up every time someone says "let's do it this way for now". Really: the metaphor is Ward Cunningham's (1992): shipping fast is like taking out a loan, and that's fine as long as you pay it back. Agile with no time to pay down debt is like paying off one credit card with another.

Agile transformation — Ironic: an eighteen-month waterfall project to become agile, complete with a Gantt chart. Really: it happens more often than you'd think. In 2014 Dave Thomas, one of the Manifesto's signatories, wrote a piece titled "Agile is Dead (Long Live Agility)": the word had become a product to sell, while the idea (agility, the noun) still holds.

The customer is always right. About what, exactly?

The phrase comes from early twentieth-century retail: it's attributed to Harry Gordon Selfridge and Marshall Field, while César Ritz said "le client n'a jamais tort". It wasn't coined for software, but in software it has a precise meaning, if you read it carefully.

The customer is always right about the problem. They know what wastes their time, what costs them money, what their own customers want. They know how much a solution is worth to them: that's why they pay, and that's why they set the priorities.

The customer isn't necessarily right about the solution. When they say "I want a button that exports to Excel", the real problem is often "every Monday I have to send a report to my boss". Maybe the best solution is an automatic email report, and no button at all. The engineer's job is to work back from the requested solution to the real problem. Incidentally, Henry Ford's famous line about "faster horses" was probably never said by Ford. There's no evidence. Even the favourite quote of people who say "the customer doesn't know what they want" is, in a way, a made-up requirement.

The customer pays, so money is the most honest signal. The seventh principle of the Manifesto says: "Working software is the primary measure of progress." Not documents, not diagrams, not velocity. Working software that someone is willing to pay for.

The contract, on the other hand, is where many companies slip back into waterfall without noticing. A fixed-price, fixed-time, fixed-scope contract locks all three corners of the so-called iron triangle. When the customer changes their mind, and they will, someone has to pay the difference, usually the team in overtime. Alternatives exist: fixed price and time with flexible scope, or the arrangement Jeff Sutherland calls "Money for Nothing, Change for Free". The customer can change priorities at no cost as long as they swap features of equal size, and can end the project early once they already have the value they need.

In short

Agile is not a set of meetings, roles and sticky notes. It's a precise engineering choice: when the set point moves, you need a closed loop with a short sampling period and a filter that doesn't amplify noise. The customer doesn't know what they want because nobody does until they see it. They pay, so they set the priorities. And they're always right, about the problem. For the solution, thankfully, there are still engineers.

See you at the next bit's tale. Same time, same sprint. 🏃