Agility

In 2001, while my friends and I were trying to work out the finer points of the Zergling rush against one another, another group of people were thinking about a better way of building software. They met at a ski lodge in Utah, and over a long weekend, wrote the Agile Manifesto²².

Specifically, it was about the growing chasm between how software was being built and what the people paying for it actually needed. The prevailing model – now called Waterfall, though nobody called it that at the time – worked like this: define the requirements, write them all down, create a detailed plan for how to deliver the project, then follow that plan exactly. By the time the thing was finished, months or years had elapsed, the world had moved, and what had been built was often an answer to a question nobody was asking anymore.

The seventeen people in the ski lodge were practitioners. They had all, in various ways, been trying to build software differently – iteratively, collaboratively, with feedback loops short enough to actually learn from. They each had different names for what they were doing, different emphases, different flavors. But the underlying conviction was the same: that a plan is a hypothesis, not a contract, and that clinging to it past the point of relevance is not discipline. It's denial.

They wrote sixty-eight words (it’s shockingly short). Called it the Agile Manifesto. Released their work on a world that seemed to need to hear it.

The revolution began, but within a decade, Agile had become what it was invented to replace. It wasn’t that the words themselves changed, but what they signified in practice. Certification programs appeared. Then certification bodies. Then consultants who certified other consultants. Books arrived by the thousands, each one explaining, expanding, and elaborating on a manifesto that had been written precisely because too many people were explaining and expanding and elaborating instead of building. Ceremonies emerged: the daily standup, the sprint retrospective, the sprint planning session, the sprint review, the backlog grooming session, the story point estimation, the definition of done. All of it sounded so reasonable, and in the right proportion, maybe it was.

And yet, all of it changed what Agile meant in practice, to the point that it became exactly the thing the Agile mindset was supposed to prevent.

The irony is tidy enough to hurt: a philosophy built to minimize busywork became a cult with its own dogma and prescriptions. The question “are we building the right thing?” got replaced by the question “are we doing this correctly?”

And that replacement – the drift from outcome to ritual – is where most Agile implementations go wrong. Not in a way that is catastrophically obvious, but in a way that people eventually look up from their desks and think “how the heck did we get here?”

Strip the barnacles from the hull, and the manifesto says four things. People matter more than the processes that coordinate them. The product matters more than the documentation that describes it. Customer outcomes matter more than contracts that specify deliverables. Responding to change matters more than adhering to a plan. The original document adds: “while there is value in the items on the right, we value the items on the left more.” That qualifier is doing significant work. This is not an argument for chaos. It is an argument for priority.

Build. When the world shifts, shift with it.

In 2017, a musician named Damian Kulash (of the band OK Go) gave a TED talk about how the group comes up with their music videos, entitled “How to find a wonderful idea.”²³

OK Go is not famous for its music – or rather, it’s more appropriate to say that they are considerably more famous for their wildly creative music videos. The treadmill video. The zero-gravity video. The Rube Goldberg video, which required 89 takes and a warehouse full of machines built from ordinary objects that had to work in precise mechanical sequence. The work is elaborate, technically ambitious, and resists easy categorization. The question everyone asks is: where do these ideas come from?

Kulash's answer is not what you would expect. He notes that when we think of looking for a creative idea, what we’re really looking for is a sense of wonder, and that an inherent quality of that wonder is a sense of surprise. To get there, he does not describe a creative process. He describes the absence of one – or rather, he describes why the conventional creative process is structurally incapable of producing the kind of ideas he is looking for.

The conventional process, as he tells it, goes like this. You think of an idea. You make a plan to execute it. You check each step off as you complete it. (This should sound very familiar to waterfall practitioners.)

The logic is sound, but the math is punishing: in a sufficiently complex project, even with 99% reliability at each individual task, the accumulated probability of something going wrong approaches certainty²⁴. Which means, as Kulash observes, that "if your project is pretty complex... you're basically constrained to just reshuffling ideas that have already demonstrably proven that they're 100 percent reliable." You cannot plan your way to a surprising idea, because planning selects against surprise. The only ideas safe enough to commit to in advance are the ones that have already been done.

His solution is a sandbox.

"What we do is we try to identify some place where there might just be a ton of those untried ideas. We try to find a sandbox and then we gamble a whole bunch of our resources on getting in that sandbox and playing."

Play, here, is not frivolity. It is a specific discipline – one that deliberately suspends judgment long enough to let unexpected combinations surface. The sandbox is full of seeds: partial ideas, interesting materials, unexpected juxtapositions, techniques that haven't found their purpose yet. You don't plan which seed will become something. You can't know. You put the right people in a space full of the right raw material and you let the process reveal what's possible.

And when it works – when the right combination of ideas finds its shape – the experience is distinctive. "When it does click, it doesn't feel like you thought up that puzzle piece, it feels like you found it – like it was a set of relationships that you unlocked."

Kulash never uses the word Agile (after all, he’s a musician, not a PM). He is describing a band's creative process, not a software methodology. Even so, the resemblance is not incidental.

The delivery half of game development is easy to recognize as Agile territory. Sprints. Milestones. Iterative builds. Ship a slice of the thing, see what breaks, adjust, ship again. The vocabulary maps directly. Anyone who has run a release cycle in an enterprise software environment would recognize the cadence.

The creative half is where it gets interesting – and where most organizations either don't look, or don't think to apply the same logic.

Worldbuilding is a sandbox. Narrative design is a sandbox. Class design, encounter design, economic tuning – all of these are fundamentally iterative disciplines. You do not design a compelling villain by specifying requirements and executing against them. You put ideas in conversation with each other until something surprising emerges that is also, somehow, exactly right. I wasn’t in the room, but I cannot believe that Arthas was the product of a planning session. He was a set of relationships that unlocked. The long arc – from prince to paladin to death knight to Lich King – has the feeling of inevitability in retrospect, the way found things always do. But it does not feel engineered. It feels discovered.

The organizations that do this well have internalized one thing: the process that reveals good ideas and the process that ships reliable software are not two different processes running on separate tracks. They are the same cognitive posture, expressed at different scales, in different domains. Build small. Observe what emerges. Let reality reshape the next iteration. Trust that the sandbox will show you which ideas are not only surprising, but – in Kulash's phrase – surprisingly reliable. The goal is not to predict the right answer. It is to create the conditions in which the right answer can appear.

When the delivery discipline and the creative discipline are aligned – when both halves of a game studio are genuinely iterating, genuinely responsive to feedback, genuinely willing to let the plan change when the work reveals something better – the result is a kind of organizational fluency that is difficult to describe and immediately recognizable when you encounter it. The game feels coherent in a way that designed things usually don't. The systems support each other. The world has internal logic that wasn't fully documented because it wasn't fully known until it was built.

When they fall out of alignment, it's the only thing you notice.

A creative team doing genuine sandbox work alongside a delivery pipeline locked into fixed-scope commitments is not Agile. It is two organizations with incompatible epistemologies sharing a building. The creatives will change their minds, because that is what the process requires. The delivery team, if it has drifted back toward ceremony, will experience those changes as failures of discipline rather than signals to be incorporated. The argument that follows is not a personality conflict, it is a philosophical one.

The Agile manifesto wasn’t simply about how to make better software. It was a revolutionary idea with surprisingly universal application: that good work actually happens when people quit worrying about being procedurally correct and focus on what really matters. Build. Embrace change.

That is as true in a warehouse full of Rube Goldberg machines as it is in a sprint review. As true in a writers' room as in a backlog refinement session. The domain changes. The posture doesn't.

The ceremony was never the point.