Agility and the cost-of-change argument

Agility is a response to change, not a speed setting

Agility in software engineering is the ability to respond effectively to change — change in requirements, in priorities, in staffing, in the market — while continuing to deliver working software. It is not a synonym for fast, and it is not a licence to stop writing things down. The word names a capability, and the capability is measured by a cost: an agile team is one that can absorb a change late in a project without the change costing more than the feature is worth.

That capability is built out of concrete arrangements, not attitude. Agility encourages team structures and communication habits that put the customer inside the team rather than across a contract from it. It de-emphasises intermediate work products — the documents that exist only to be handed to the next stage — in favour of running software. It treats the plan as a live object expected to be revised, not a commitment to be defended. And it delivers in short increments, because an increment is the only thing a customer can react to concretely enough to give feedback worth having.

The argument that carries the marks: the cost-of-change curve

Here is the whole case for agility, and you should be able to describe it from memory. In a conventional process the cost of accommodating a change rises non-linearly with time. Early — while you are still eliciting requirements — a change is an edit: a scenario is reworded, a function is added to a list. Late, the same change may require an architectural modification, three new components, edits to five more, a fresh set of tests, and a regression run over everything those edits could have disturbed. The curve climbs steeply, and it climbs faster than the project's willingness to pay.

Agile practices are an attempt to flatten that curve rather than to accept it. Incremental delivery keeps small the amount of built software a change can invalidate. Unit tests written and run continuously mean the regression cost of a change is paid by a machine rather than by a re-test campaign. Refactoring keeps the design from ossifying, so the architecture cannot accommodate that is heard less often. Pair programming and continuous integration surface incompatibilities within hours instead of at an integration milestone. How flat the curve really goes is still argued over; that it flattens at all is the claim, and the claim is the definition. Write "agile means less documentation" in an exam and you have described a side effect and missed the mechanism.

The three assumptions an agile process bets on

An agile process is a bet on three propositions about most software projects:

1. You cannot reliably predict which requirements will persist and which will change, nor how the customer's priorities will move while you build.
2. For many systems, design and construction are interleaved — you learn whether a design works by building it — so you cannot say in advance how much design is enough.
3. Analysis, design, construction and testing are less predictable, from a planning point of view, than we would like.

If those three hold for your project, a process that fixes the plan up front is optimising for a world you are not in. If they do not hold — the requirements are legislated, the interfaces are published standards, the domain has been built ten times before — the bet loses and a prescriptive model is the better engineering choice. Agility is a decision, not a virtue.

Worked example — one late change to BorrowBox, costed twice

BorrowBox is a neighbourhood tool library: members reserve a power tool in an app, collect it from a smart locker bank with a one-time QR token, and return it to any locker, where a librarian inspects and re-shelves it. A reservation places a two-hour hold on a specific tool copy. Nine weeks in, the depot manager brings back a real finding: members who cycle over after work miss the window, abandoned holds are stranding stock, and the hold must become four hours, configurable per depot.

Under a conventional process the change arrives during validation testing. The two-hour value is written into the reservation service, the expiry sweeper, the locker's display text and three test fixtures; the requirements specification and the design document both state it; a change request has to be raised, evaluated, approved and scheduled; every affected test artefact must be reissued. Call it three weeks of elapsed time, most of it not spent writing code.

On the agile team the same change arrives inside a two-week increment. The hold duration was never a constant — it had been a value in the depot configuration object since increment two, because the team had already delivered to real members and learned that depots differ. The change is a configuration edit, one new acceptance test, and a line in the sprint review. Call it a day. Notice what actually did the work: not speed, and not the absence of documents. The design decision to keep the policy outside the code was possible only because the team had shipped early enough to discover that it mattered. That is the flattened curve, and that is the whole argument.