Why Agile Exists

Imagine planning a wedding eighteen months out. You book the venue, fix the menu, print the invitations, choreograph the day down to fifteen-minute slots. Every decision made early, locked in, filed. Then reality gets a vote. The caterer closes. Your cousin's new partner is vegan. It rains. None of this means you planned badly. It means you planned early — and the world kept moving after you stopped.

By the end of this video, you'll be able to explain the problem agile was invented to solve, and tell the origin story accurately in about a paragraph — which, you'll find, is more than most people who use the word "agile" every day can do.

For decades, big software projects were run like that wedding. The approach is usually called waterfall, because work flows one way, downhill, through phases: first gather all the requirements. Then design the whole system. Then build it. Then test it. Then, finally, hand it over.

There's a logic to it, and for some work it's genuinely the right logic — hold that thought, because we'll come back to it honestly in a later lesson. But buried inside waterfall is one enormous assumption: that you can fully know what's needed before you build anything. Write it all down up front, and the rest is execution.

For complex, novel work, that assumption kept failing. Customers discovered what they actually wanted only when they saw something real — which, in waterfall, was at the very end, when change was most expensive. Requirements shifted mid-project. Technology moved. And the process treated every one of those changes not as information, but as a failure — someone must not have planned hard enough.

The results weren't just late projects. Teams spent years building systems that were obsolete on arrival — software that shipped, technically, and then sat unused. There's a word for that: shelfware. People burned out in death-march final phases trying to force reality to match a two-year-old document. The industry started measuring the damage, and the numbers were grim — you'll find the actual figures on the data card below this video, with sources, because we don't quote statistics from memory and neither should you.

So by the 1990s, practitioners were quietly rebelling. Different groups invented lighter ways of working — shorter cycles, earlier feedback, less paperwork — each with its own name and tribe.

In February 2001, seventeen of these practitioners met at a ski lodge in Snowbird, Utah. They came from competing methods and didn't agree on much. But they found common ground on something deeper: a small set of values about how work should actually happen. They wrote it down, kept it deliberately short, and called it the Manifesto for Agile Software Development — choosing the word "agile" over the label their methods had carried before: "lightweight," which, as one of them noted, sounded like something nobody wants to be.

Notice what the Manifesto is, and what it isn't. It's a reaction — written by working practitioners, against heavyweight, documentation-driven process. It is not a method, not a product, and not owned by anyone.

You might think agile is a system some company sells — a thing you get certified in, with an official rulebook somewhere. That's understandable: an entire industry of certifications and branded frameworks grew up around the word, so it looks owned. Actually, agile is a movement. The Manifesto belongs to no organization, and nobody can revoke your right to work this way. That matters for this course too: we're independent, we're not selling you a certification, and we can afford to tell you the whole story — including where agile goes wrong.

One more thing. The Manifesto says "software" because software is where the pain was sharpest. But the underlying problem — planning everything up front in a world that keeps changing — isn't a software problem. It's a work problem. Hospitals, marketing teams, schools, and factories have all borrowed these ideas, and through this course, so will you, whatever field you're in.

Three things to keep. One: waterfall's core assumption is that requirements can be fully known up front — and for complex work, they usually can't. Two: in February 2001, seventeen practitioners wrote a short manifesto as a reaction to heavyweight process; it's a movement, owned by no one. Three: the ideas started in software and outgrew it.

That reaction produced a declaration of just sixty-eight words — four value statements and a closing sentence most people skip, which happens to be the most important line in it. That's next.