Software's folk history has three chapters. First you locked the specification and organized the work. Then the customer kept changing the outcome, and Agile learned to absorb that. Now feedback arrives continuously, and the product is expected to move with it.
The middle chapter is the one worth telling carefully. Welcoming change was already mainstream practice before anyone called it Agile. The part that stayed unsolved is smaller: once the agreement moves, which sentence is the current one, and where is that written so the next person — or the next agent — cannot miss it?
A frozen spec was a way to buy the work
In 1970 Winston Royce published the picture everyone remembers. "Managing the Development of Large Software Systems" shows requirements, then analysis, then design, then code, each phase feeding the next. The paper's argument, which traveled less well than the diagram, was that a single pass is risky. He wanted feedback between the phases, because building the system is how you find out what the system has to be.
Procurement kept the diagram and dropped the warning. A fixed-price contract, a government standard, a vendor bid: these need a baseline you can point at. When the customer changes the outcome, that change is a request. It is priced, queued, and often argued. The customer's influence was never a surprise. The process treated it as an exception to the plan.
On a real account, that exception was most of the project. The review meeting rewrote the document the estimate was built on. Heavy customer influence on the outcome is the work, especially for anyone delivering to a client rather than to their own roadmap.
The practice that let the outcome move
The replacement arrived as methods, from the mid-1980s on, that assumed the outcome would move and designed the clock around that.
Barry Boehm's spiral model, circulated from 1986 and published in IEEE Computer in 1988, made each loop a trip around risk. Decide what you need to learn, build the smallest thing that teaches it, then replan. Tom Gilb's evolutionary delivery, written up the same year in Principles of Software Engineering Management, shipped thin slices to a real user and let the measurement change the plan. Hirotaka Takeuchi and Ikujiro Nonaka, writing in Harvard Business Review in 1986 about Honda, Canon, and Fuji-Xerox, described product teams that overlapped phases the way a rugby team moves the ball. That picture is what Ken Schwaber and Jeff Sutherland later turned into Scrum.
Extreme Programming, as Kent Beck published it in 1999, put the customer on the team. A story was a token. Ron Jeffries' line for it was card, conversation, confirmation: the card is the reminder, the conversation is the requirement, the confirmation is the test. DSDM, from a UK consortium in 1994, was the version a services firm could sell. Time and cost stay fixed. Scope moves. MoSCoW — must, should, could, won't this time — is how a sponsor absorbs a client who keeps influencing the result, without reopening the contract every week.
The Agile Manifesto, signed at Snowbird in February 2001, put the doctrine in one line: welcome changing requirements, even late in development. The front page has a second line that teams often skip. A plan, a contract, and documentation still have value. The authors valued responding to change more. A generation of practice heard only the first half.
What a mainstream team actually ran
After that, a competent delivery organization looked roughly the same, whether it used the word Agile or not.
A short lock. The sprint, the DSDM timebox, later a Shape Up cycle. In Scrum the sprint goal holds for the length of the sprint. Scope inside it can be clarified with the product owner. The product backlog outside it stays open.
One change authority. The product owner, or the DSDM business sponsor, may admit a request, reject it, or defer it. Everyone else can want things. One role decides what is current.
A living list. The backlog is the agreement as of today: ordered, incomplete, and rewritten between iterations. The review is where the customer sees working software and redirects the next slice.
A protected date. When the customer influences the outcome, scope gives way before the calendar does. That is MoSCoW. It is also how most fixed-date client work still survives.
David Anderson's Kanban (2010) shortened the lock toward a continuous flow. Continuous Delivery, by Jez Humble and David Farley the same year, made working software something you could put in front of a user on an ordinary day. Eric Ries's The Lean Startup (2011), and the discovery practice that followed in the writing of Marty Cagan, Teresa Torres, and others, went one step further. The original idea is a hypothesis. User feedback is allowed to retire it.
That last step is the pace people now call normal: the product adopts the user's request quickly, and the kickoff plan is a starting belief. It still depends on the older machinery. Someone admits the change. Something has to record that the old belief is no longer current.
flowchart LR
Feedback[Customer feedback]
Authority["Change authority: admit, reject, or defer"]
Record[Current agreement]
Lock["Short lock: sprint, timebox, cycle"]
Feedback --> Authority --> Record
Record --> Lock --> Feedback
The loop was a small freeze, then a new agreement. The quality of the method is the quality of that agreement.
The decision had nowhere to live
Those methods stored the work. They were much weaker at storing the decision.
| Record | What it held | What happened to the previous agreement |
|---|---|---|
| Product backlog, Jira, Linear | The next unit of work | Rewritten in place. The old sentence disappears into ticket history. |
| Sprint review | The customer's reaction | Spoken once. It lasts as long as the people in the room. |
| Change request and change-control board | Admit, reject, defer, with a cost | Durable, and slow. On fixed-price work it became a commercial argument. |
| Decision register, often the D in a RAID log | What was decided, by whom, when, and why | A project-management appendix. Builders rarely read it before acting. |
| Meeting minutes | The minute-book of the agreement | Treated as ceremony. The function went away with the theater. |
| Architecture Decision Record (Michael Nygard, 2011) and arc42 §9 | Context, decision, consequences, status | The previous decision stays, marked superseded. Scoped to architecture, written by engineers for engineers. |
The practice that grew from Nygard's essay is the one that aged well. An accepted decision stays put. March's "we will use SSO" is not edited into June's "not this phase." A new record supersedes it, and the old one remains so the reason it existed is still inspectable. A ticket does the reverse. The description is updated until the old commitment is gone. Six months later, "why did we refuse this?" has an assignee and no answer.
Jeffries was right that a card cannot hold a requirement. He was describing a team that stayed in the room. The conversation does not survive the next contractor, the founder holding a portfolio of clients, or a coding agent that was not in the planning meeting.
The ADR was the engineering patch, a decade after Snowbird, for structural choices that are expensive to reverse. "No SSO this phase," "the digest replaces the Friday status call," "this billing webhook stays frozen" — those are client decisions. They rarely became ADRs. They lived in the product owner's head, the statement of work, and a Slack thread.
What changes when the executor was not in the room
The need to welcome change was settled before language models. A sprint boundary is a social freeze among people who heard the planning conversation. An agent was not there.
It will treat the latest prompt, the open ticket, and the stale README as equally current, because nothing in its inputs marks one sentence as the one that replaced the others. The team used to have a week of standup chatter in which someone might say "we already refused that." The agent has a session. If the refusal is missing from the context it was given, the refusal did not happen.
The old artifacts fail differently under that executor than they failed in 2011.
The backlog is still the right list of work. It is a poor constitution. An agent that works the tickets will implement one that contradicts a constraint closed last quarter, and the ticket will look authorized because it sits in the current sprint.
The ADR is still the right file for an architectural choice, and a human should still accept it. It does not see the client email that moved the scope. arc42 can describe the shape of the system. It will not say which of the client's last three requests the owner admitted.
The change-control board still has the right verbs: admit, reject, defer. An agent cannot spend the budget, trust, or liability those verbs commit. It also cannot wait for a monthly board. The result of those verbs has to be readable before the next implementation starts.
Coding got cheaper. Re-explaining the accord got more expensive. On a small agency account the person who used to be the product owner is also the tech lead and the client translator — and the person who has to stop a fleet of agents from relitigating a decision the client already made.
Where Accord Book fits
Accord Book is the record those artifacts split apart.
The backlog remains the list of work. Keep Linear, Jira, or GitHub Issues for that. They answer what you are shipping. Accord Book answers a different question: what did we decide, what did that replace, and does this new request fight it?
The shape is the one Nygard used, applied to the client accord and not only to the architecture. A decision carries provenance: who it came from, and when. A later decision can supersede it and leave the earlier one in place. When a new request conflicts with a current constraint, that conflict is a risk signal for the owner, not a silent rewrite. AI proposes; a human publishes what agents are allowed to treat as true. For the architecture slice, that published truth is arc42 and ADRs in the repository, merged by a person. For the running project, it is the memory agents read over MCP before they act, and the digest a client can read without another status call.
That is the product-owner function with a minute book. Admit, reject, and defer stay human. Remembering which sentence won, and handing that sentence to the thing about to write the code, is the part that does not scale in someone's head.
The memory layer argument is this history from the other end. Teams already lost decisions between meetings. Agents make the loss operational, because they execute.
What this leaves in place
Scrum, DSDM, Kanban, and continuous discovery were the right response to a customer who changes the outcome. A frozen specification was a contracting tool. It described the purchase more faithfully than it described the work. Faster coding tools do not restore the single-pass baseline, and a faster executor does not remove the need for a short lock so that something can be finished.
ADRs stay the right convention for structural choices. Accord Book uses that convention on purpose. The gap is the rest of the accord: the product and client decisions that determine what those structural choices are for. They need the same lineage — current, superseded, attributable — and a reader that includes the agent.
The sprint solved the freeze. Supersession is how the thaw stays honest.
Further reading
- Principles behind the Agile Manifesto, and the values page line about the items on the right
- Takeuchi and Nonaka, "The New New Product Development Game", Harvard Business Review, 1986
- Boehm, "A Spiral Model of Software Development and Enhancement", IEEE Computer, 1988
- Architecture Decision Records, Martin Fowler's summary of Michael Nygard's 2011 essay
- arc42, whose section 9 is the design-decision section of a template that predates agent tooling
- Accord Book: vs Linear, AI proposes, humans publish, why a memory layer
Product: Accord Book · Pilot