The Agile Manifesto asks teams to welcome changing requirements even late in development — what makes that affordable?
answer
- Ask what the change costs, not who agreed
- Age of the code should not matter
- Look at batch size and test speed
- Capacity is fixed; order is not
basics
~20 sThin vertical slices, a fast automated regression suite, frequent integration and loose coupling behind stable interfaces are what make a late change cheap. Welcoming change is a technical capability before it is an attitude, and the plan is re-ordered rather than enlarged.
solid answer
~50 sThe principle asks teams to welcome changing requirements even late, and to harness change for the customer's advantage. That is only affordable when the cost of a change does not depend on how late it arrives, so the practices behind it are technical. Work in **thin vertical slices**, so little is half-built when the change lands. Keep an **automated regression suite** fast enough to run on every change, so nobody fears touching old code. **Integrate frequently**, so the gap between what was agreed and what exists stays small. Keep rules **loosely coupled behind stable interfaces**, so a change is local rather than an archaeology exercise. Defer irreversible decisions until the last responsible moment. The organisational half matters equally: welcoming change means re-planning in the open, not absorbing extra scope for free. Capacity is fixed; order is negotiable.
go deeper
Know the principle in your own words: changing requirements are welcome even late, because a product that matches the customer's real need beats a plan that stayed tidy. Be ready to say why small pieces of work make that easier.
Explain the mechanics that make it affordable — thin vertical slices, a fast automated regression suite, frequent integration, loose coupling behind stable interfaces — and be honest about which of those your last team actually had.
Show the diagnosis. Name what you would measure: suite duration and its coverage of the changed area, how many call sites one rule touches, how long finished work waits for a user. Then say which you would fix first and what it buys.
Own the economics. Be ready to argue for spending capacity on flattening the cost of change against feature pressure, to state that tradeoff in terms the business can weigh, and to refuse to quote contested multipliers as if they were measurements.
## What the principle actually says The second of the twelve principles asks teams to welcome changing requirements, even late in development, and says that agile processes harness change for the customer's competitive advantage. The word doing the work is *welcome*. Tolerating change, absorbing it grudgingly, or accepting it after a three-stage approval is not what the principle describes. The interview question behind it is never 'do you welcome change?' — everybody says yes. It is 'what makes that answer affordable?', because a team can only genuinely welcome a change whose cost does not depend on how late it arrived. ## Welcoming change is a technical capability first Enthusiasm is free; the invitation is not. A late change is expensive when work already done must be unpicked, when nobody dares touch old code, and when the result has to be re-verified by hand. Each of those is addressable: 1. **Thin vertical slices.** Build in pieces that are individually useful end to end. When a change lands, little is half-built, so little is wasted. Wide horizontal batches maximise the amount of work sitting in an unfinishable state. 2. **A fast automated regression suite.** Fear is the real cost of a late change. A suite that covers the area being changed and runs in minutes turns 'we do not know what this breaks' into 'we know within minutes'. 3. **Frequent integration.** The longer work sits unintegrated, the wider the gap between what the team agreed and what actually exists, and the more of that gap a change invalidates. 4. **Loose coupling behind stable interfaces.** If one business rule lives in one module, changing it is local. If the same assumption is spelled out at twenty-three call sites, the change becomes archaeology. 5. **Deferring irreversible decisions.** Keeping a decision open until the last responsible moment is how a team buys the right to be surprised. ## The cost-of-change argument, stated honestly The usual justification is a curve: the cost of a change rises steeply, sometimes said to be exponentially, with how late it arrives. **Treat that claim as contested.** The figures that circulate — a defect costing ten or a hundred times more to fix late — rest on a small and much-criticised evidence base, and quoting a multiplier as measured fact is a fast way to lose a senior interviewer. The defensible version is local and measurable: in *this* codebase, with *this* suite duration and *this* coupling, changing that rule costs about this much, and here is what would reduce it. The practices above exist to flatten whatever curve is really there, which is a claim you can demonstrate instead of cite. ## Welcoming change is not accepting unpriced scope The other half of the answer is organisational, and candidates who give only the technical half get pushed here. | The request | The wrong yes | What welcoming change means | | --- | --- | --- | | A new rule arrives mid-quarter | added on top of everything planned | added, and something of similar size comes out | | A stakeholder wants the date confirmed | the original date restated | the forecast revised with what is now known | | A change lands with work nearly finished | that work abandoned immediately | that work finished, because it is hours from useful | | Requests arrive weekly | each one queued for approval | the order of work revisited as a normal act | Capacity is fixed; order is negotiable. A team that silently absorbs every addition is not honouring the principle — it is hiding a schedule slip that resurfaces later as unplanned overtime or defects. Making the trade visible is the part that takes courage, and it is what the principle actually asks for. ## A worked comparison Take a warehouse forklift-routing product. In week 7 of a quarter holding 118 planned items, the customer discovers that aisles are re-striped seasonally: the permitted direction of travel per aisle now changes four times a year, and generated routes must respect it. Team A has the direction assumption baked into twenty-three call sites. Its regression suite takes 71 minutes and covers roughly a third of the routing behaviour, and finished work waits for a monthly deployment. The change is a two-week project with a frightening tail, so the team's honest answer is 'next quarter'. Team B keeps direction in one routing-rule module behind a small interface, runs 2,400 tests in about three minutes, and gets finished work into the warehouse within a day. The same request is an afternoon of work plus a conversation about what moves out of the quarter to make room. Both teams say they welcome change. Only one can afford to. That difference — not attitude, not the shape of the process — is what the principle is about, and naming it is what separates a memorised answer from a real one.
- Does welcoming change mean accepting new work without dropping anything?No. Capacity is fixed and the order of work is what changes. Welcoming a late change means re-planning in the open: the new item goes in, something of similar size comes out, and the customer chooses which. A team that silently absorbs additions is not honouring the principle — it is concealing a schedule slip that will surface as overtime or defects.
- How would you tell in twenty minutes whether a codebase can afford late change?Measure three things: how long the automated suite takes and what share of the area being changed it actually covers; how many places you must edit to change one business rule; and how long finished work waits before a user sees it. Long, many and long means change is expensive there, whatever the team's stated way of working claims.
- What if a change arrives when the current piece of work is nearly finished?Finish it first. The point of small batches is that 'nearly finished' means hours, not weeks, so the cost of completing it is trivial. The principle is about the cost of change over the life of the product, not a duty to interrupt on arrival. If a late change forces you to abandon weeks of work, the batch size is the defect.
A building whose interior walls are demountable can be re-partitioned over a weekend; one whose interior walls are load-bearing cannot. Welcoming late change is a claim about which kind of building you have built, not about how willing you are.
saying these in an interview costs you the question
- Treats welcoming change as attitude with no technical prerequisites
- Quotes a specific cost-of-change multiplier as established fact
- Says the team must accept new scope without removing anything
- Claims late change is free for a sufficiently agile team
- Confuses welcoming change with having no plan at all