Lesson 02
4 values, 12 principles, and why agile transformed software development forever.
In February 2001, seventeen software developers gathered at The Lodge at Snowbird ski resort in Utah. They came from different backgrounds — Extreme Programming, Scrum, DSDM, Crystal, Feature-Driven Development — but shared a common frustration: heavyweight, documentation-driven processes were killing software projects.
Over two days they debated, argued, and ultimately agreed on a short document that would reshape the entire industry. They called it the Manifesto for Agile Software Development.
Before the manifesto, the dominant approach was the Waterfall model: months of requirements gathering, months of design, months of coding, then testing at the very end. Projects routinely shipped years late, over budget, and with features nobody wanted. The manifesto was a direct response to this failure mode.
The manifesto establishes four value statements. Each follows the pattern: "We value X over Y." Critically, this does not mean Y is worthless — it means when forced to choose, X takes priority.
The best processes in the world are useless if the people using them can't communicate, collaborate, and make decisions. A talented team with a whiteboard will outperform a mediocre team with the most expensive project management software.
A running system that users can interact with provides more valuable feedback than a 200-page specification document. Documentation matters, but it should describe what was built and why — not be a substitute for building.
Software requirements cannot be perfectly specified upfront. Instead of hiding behind a contract, work with the customer continuously. Show them working software regularly. Let them steer the product based on what they see, not what they imagined six months ago.
Plans are essential — but clinging to an outdated plan when the world has changed is not discipline, it's denial. Agile teams plan continuously at multiple horizons and adjust based on new information, feedback, and changing priorities.
Behind the four values stand twelve principles that provide actionable guidance. Here they are, mapped to the practices they inform in our workflow system.
| # | Principle | Practice in Our Workflow |
|---|---|---|
| 1 | Satisfy the customer through early and continuous delivery | Sprint increments every 1-2 weeks |
| 2 | Welcome changing requirements, even late | Backlog re-prioritization every sprint |
| 3 | Deliver working software frequently | CI/CD pipeline with automated deployments |
| 4 | Business and developers work together daily | Product Owner role in sprint planning and review |
| 5 | Build projects around motivated individuals | Agent autonomy with clear boundaries |
| 6 | Face-to-face conversation is most efficient | Synchronous ceremonies (standup, planning) |
| 7 | Working software is the primary measure of progress | /agile-code-ci after every phase, /agile-story-dod before done |
| 8 | Sustainable pace — maintain indefinitely | Velocity tracking and capacity-based planning |
| 9 | Continuous attention to technical excellence | TDD, code review, SOLID principles |
| 10 | Simplicity — maximize the amount of work not done | YAGNI principle, express workflow for small tasks |
| 11 | Best architectures emerge from self-organizing teams | Agent dispatch based on need, not hierarchy |
| 12 | Reflect and adjust at regular intervals | Sprint retrospective (/agile-sprint-retro) + /agile-memory-learn |
Understanding what Agile replaces helps clarify why each value and principle exists.
| Dimension | Waterfall | Agile |
|---|---|---|
| Planning | Big upfront plan, fixed scope | Continuous planning, adaptive scope |
| Delivery | Single release after all phases complete | Incremental delivery every 1-2 weeks |
| Feedback | At the end (too late to change) | Every sprint (cheap to change) |
| Testing | Separate phase at the end | Continuous, integrated into every sprint |
| Risk | Discovered late, expensive to fix | Discovered early, cheap to fix |
| Requirements | Frozen at project start | Evolve based on feedback and learning |
| Team structure | Siloed (analysts, devs, testers) | Cross-functional, collaborative |
| Success metric | Conformance to plan | Value delivered to users |
Wrong. Agile teams plan more than waterfall teams — they just plan at shorter horizons. Sprint planning happens every 1-2 weeks. Backlog refinement is ongoing. The difference is that plans are expected to change, not carved in stone.
Wrong. The manifesto says working software over comprehensive documentation — not instead of. Agile teams write documentation, but they favor living docs (tests, code comments, architecture decision records) over heavyweight spec documents that go stale.
Wrong. Scrum ceremonies are one implementation of agile principles. Agile is a mindset rooted in values and principles. You can do standups and sprints and still be completely un-agile if you don't embrace feedback, collaboration, and adaptability.
Ask yourself: "When we learned something new last week, did we change our plan?" If yes, you're being agile. If no — regardless of what ceremonies you run — you're still waterfall in disguise.
Which of the following is one of the four Agile Manifesto values?