What "Agile" actually means — the manifesto vs the buzzword

In 2001, seventeen software developers frustrated with heavyweight, documentation-first development processes (long specification phases, rigid phased plans, changes treated as failures of planning) met and wrote the Manifesto for Agile Software Development — four short value statements and twelve supporting principles. That document, not any specific framework, is what "Agile" formally refers to:

Each line has a specific shape: it's not "documentation is worthless" or "plans don't matter" — the items on the right have real value, the manifesto says so explicitly — it's that when the two are in tension, the item on the left is the one worth defending. A team that produces beautiful documentation nobody reads while shipping broken software has inverted the actual priority, whatever process it claims to follow.

This is the single most common confusion: "Agile" names a set of values and principles, not a specific set of rituals. Scrum (roles, sprints, standups, retros — covered in the next lesson), Kanban (a continuous-flow board with WIP limits — also its own lesson), and Extreme Programming (pair programming, TDD, continuous integration) are three different, concrete implementations of the same underlying values, each making different specific bets about which mechanics best deliver on those values.

This matters practically: "we do standups and two-week sprints" describes Scrum's mechanics, not whether the team is actually agile in the manifesto's sense. A team can run every Scrum ceremony precisely on schedule while still being fundamentally not agile — rigid scope commitments made months in advance, documentation valued over shipped software, customer feedback treated as a disruption to the plan rather than the point of the plan. The ceremonies are not the goal; they're one team's specific bet about how to serve the values.

Waterfall — sequential phases (requirements → design → implementation → testing → deployment), each fully completed before the next begins — isn't a strawman; it's how large software projects were commonly run before Agile, and it still shows up today, sometimes usefully.

The core problem Agile identified: software requirements are almost never fully knowable up front, and a process that treats "requirements" as a phase you finish and move past — rather than something you keep learning throughout the project — locks in early misunderstandings and only surfaces them at the end, when they're most expensive to fix. Agile's answer is iterative: build a small slice, get real feedback (ideally from working software in front of real users), adjust, repeat — so a wrong assumption costs one iteration's worth of rework, not the whole project's.

Despite the reputation, sequential, heavily-planned processes are still the right call in specific contexts: regulated environments where a change requires formal re-certification (aviation software, medical devices), or genuinely fixed, well-understood requirements (a one-time data migration with a clear, unchanging target schema) where the cost of iterating is higher than the cost of getting the plan right up front. The manifesto's own principles say responding to change is valued when there's uncertainty to respond to — a project with none doesn't need an iterative process to discover something it already knows.

The rest of this domain works through the concrete frameworks (Scrum, Kanban), the practical mechanics teams actually use day to day (writing a good story, running a standup that isn't a status-report ritual, estimating without pretending to be precise), and the anti-patterns that show up when a team adopts the mechanics without the underlying values — "agile" as a checklist rather than an actual way of working.