Things Have History
The spy at Snowbird

software-architecture

The spy at Snowbird

Listen · 4:13

On the morning of February 11, 2001, Stephen Mellor walked into a ski lodge in Utah’s Wasatch mountains and introduced himself as a spy. He was not entirely wrong. Mellor came from the world of formal notation and heavyweight specification, while most of the sixteen others in the room had spent the 1990s building the lightweight alternatives that had earned them this invitation. His opener defused the room. By the end of the weekend, Alistair Cockburn noted, Mellor had moved “from the other side of the table to our side.”

The meeting had been organized by Jim Highsmith and Bob Martin, who suspected that practitioners of Extreme Programming, Scrum, Crystal, DSDM, and Feature-Driven Development had more in common than their methodological skirmishes suggested. In February 2001, seventeen of them gathered at The Lodge at Snowbird to test that hypothesis. The common enemy was legible from the room: the process industry — the three-inch binders, the Rational Unified Process phase gates, the months-long requirements reviews that arrived after engineers had mentally started coding but couldn’t officially touch anything yet.

The group had an existing label for what they were: “lightweight” methods. Almost everyone present disliked it. Cockburn objected to being “a lightweight attending a lightweight methodologists meeting.” So on the second day they went looking for a better word. Martin Fowler noted, with characteristic deadpan, that most Americans didn’t know how to pronounce “agile.” They chose it anyway, because it captured what all seventeen actually cared about: adaptiveness and rapid response to change, not minimalism.

What they produced was brief enough to fit on a notecard. The Manifesto for Agile Software Development stated four values — “individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; responding to change over following a plan” — with twelve supporting principles. The drafting was meticulous: a thumbs-up system governed each sentence, a full thumb meaning agreement, a tilted thumb prompting “ok, what’s bothering you?” Cockburn later described the result as wordsmithing “to 100% unanimity.” Jon Kern’s account was shorter: “We left our egos at the door.”

One of the twelve principles proved architecturally decisive: “The best architectures, requirements, and designs emerge from self-organizing teams.” That sentence challenged thirty years of practice. The prevailing model — formalized through CMM levels, IEEE standards, and the Rational Unified Process — treated architecture as a phase: senior designers worked upfront, then handed specifications to implementers. The manifesto didn’t abolish architecture; it relocated it. Design happened continuously, in feedback with working code, not in a phase that concluded before serious development began.

The word “agile” spread further and faster than anyone at Snowbird intended. Scrum certifications multiplied. Consultants annexed the term and retrofitted it onto the heavyweight processes the manifesto had criticized. But the architecture principle held: short iterations, emergent design, and the frank assumption that requirements will change — not might — quietly rewired how engineers built systems at scale. The architectures that followed — services that deploy independently, teams that own their own stack, systems designed to absorb change rather than resist it — are simply what “adaptable” looks like when you point it at a codebase.

Sources

Spot a mistake?

Wrong date, broken citation, a fact that doesn't hold? Tell us. It lands in an inbox a human reads and the post can be pulled or corrected.