Keyboard Navigation
W
A
S
D
or arrow keys · M for map · Q to exit
← Back to The Archive
2001invertedplanning

Move Fast and Break Things

Ship iteratively, skip comprehensive documentation, respond to change over following a plan, value working software over written specs

3 min read · Conference
Status

Fully Inverted — Now a Known Anti-Pattern

Why It Made Sense

Waterfall produced software that was perfectly built to a spec that was wrong by the time it shipped. Agile fixed this by shipping small, getting feedback, and iterating. The shortcut was the feature.

The Agile Manifesto (2001) was a genuine innovation. It solved a real problem — the waterfall pathology of spending eighteen months writing requirements documents for software that was obsolete before it shipped. "Working software over comprehensive documentation" was a rational correction. "Responding to change over following a plan" was a survival strategy for markets that moved faster than spec reviews.

Why it was reasonable: Waterfall was killing projects. Requirements changed between sign-off and delivery. Documentation was produced for compliance, not comprehension. Teams spent more time writing about software than writing software. Agile said: ship something real, show it to the stakeholders, and iterate. That was correct.

How it was inverted: The Manifesto says "while there is value in the items on the right, we value the items on the left more." The industry read: "the items on the right don't matter."

By 2015, "we're Agile" had become a defense against planning, documentation, architecture, and long-term thinking:

- "Working software over comprehensive documentation" became no documentation at all. Architecture lived in one person's head. When that person left, the architecture left with them.

- "Responding to change over following a plan" became no plan at all. Sprints with no roadmap. Backlogs with no strategy. Velocity measured in story points that measured nothing.

- "Individuals and interactions over processes and tools" became no process at all. Tribal knowledge in Slack. Decisions made in standups and never recorded.

- "Customer collaboration over contract negotiation" became scope creep as methodology. Every sprint review was a requirements session. The product never stabilized because feedback was continuous and unfiltered.

The Katie's Law connection: Teams didn't adopt Agile because they believed in iterative delivery. They adopted it because it meant no more 200-page requirements documents, no more 18-month delivery timelines, and "we're Agile" as an answer to any request for planning. The noble shortcut was adopted for its laziness, not its nobility.

What it produced: The Runaway Migration that worked in dev but locked prod for four hours — because the sprint didn't include a migration testing task. The God Object that grew one method per sprint — because adding to the existing class was always the fastest way to close the ticket. The security review that was "in the backlog" for three years — because the sprint was always full of user stories. Technical debt compounding across sprints with no structural mechanism to pay it down, because "we'll refactor next sprint" is always technically true and practically meaningless.

Agile was laziness applied to process. The laziness was constructive at first — skip the useless ceremony — and destructive later — skip the necessary discipline. The context changed. The shortcut didn't.

Sources Where This Was Taught
Agile Manifesto (2001)Facebook Internal Motto (2004)The Lean Startup (Eric Ries 2011)
Languages Affected
All