Agile Manifesto and Core Principles
The Agile Manifesto (2001) defines four values and twelve principles that prioritise working software, customer collaboration, and responding to change over rigid process.
What is the Agile Manifesto and what are its core principles?
The Agile Manifesto was created in 2001 by 17 software practitioners who identified common patterns in successful software development that differed from heavyweight process-driven methods (Waterfall, RUP).
The Four Values
| We value... | Over... |
|---|---|
| Individuals and interactions | Processes and tools |
| Working software | Comprehensive documentation |
| Customer collaboration | Contract negotiation |
| Responding to change | Following a plan |
Critical nuance: "while there is value in the items on the right, we value the items on the left more" - Agile doesn't discard processes, docs, contracts, or plans; it re-prioritises them.
The Twelve Principles
- Highest priority: satisfy the customer through early and continuous delivery of valuable software
- Welcome changing requirements, even late in development
- Deliver working software frequently (weeks, not months)
- Business people and developers must work together daily
- Build projects around motivated individuals; give them the environment, trust, and support they need
- Face-to-face conversation is the most efficient communication
- Working software is the primary measure of progress
- Sustainable pace - the team should be able to maintain the pace indefinitely
- Continuous attention to technical excellence and good design enhances agility
- Simplicity - maximising the work not done - is essential
- Self-organising teams produce the best architectures, requirements, and designs
- Regularly reflect on how to become more effective and adjust behaviour
Why Agile Over Waterfall?
Waterfall problems:
- Requirements gathered upfront are often wrong - users don't know what they want until they see it
- Long feedback cycles - problems discovered at the end cost 10-100× more to fix
- Documentation-heavy, slow to start
- Change is expensive (contracts, formal change requests)
Agile advantages:
- Short cycles expose wrong assumptions quickly
- Working software in front of users generates real feedback
- Teams self-correct before problems compound
- Change is expected and accommodated
Common Misconceptions
- "Agile means no documentation": no - it means documentation should serve the work, not be the work
- "Agile means no planning": no - it means plans must be adaptable; plan at the right level of detail
- "Agile is only for software": no - applied to hardware, marketing, operations
- "We're Agile because we have standups": rituals ≠ agility. Agile is a mindset, not a checklist
Technical Excellence (Principle 9)
Agile doesn't work long-term without engineering practices:
- Without automated tests -> changes break things -> teams slow down -> velocity drops
- Without refactoring -> technical debt accumulates -> change becomes expensive
- Without CI/CD -> integration is painful -> releases are infrequent and risky
Principle 9 is frequently underemphasised. Agile at speed requires investment in technical practices (XP: TDD, pair programming, CI, refactoring).
Interview Angle
In architecture interviews, Agile comes up when discussing team organisation, delivery cadence, and technical practices. Key points: Agile is about fast feedback loops and adapting to change - not just ceremonies. Connect to technical practices: CI/CD, automated testing, and trunk-based development are the engineering foundation that makes Agile sustainable. "Agile without engineering discipline is just chaos with standup meetings."