Agile Manifesto and Principles

Agile is the umbrella term. Scrum, Kanban, XP, etc. are specific methodologies that fall under it. The Manifesto (2001) is short and worth memorizing — interview questions often start “what’s Agile?” and your answer is judged on whether you understand the values, not just the ceremonies.

The Manifesto (2001)

Seventeen people met in Snowbird, Utah, in February 2001. They wrote four value statements:

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The “while there is value in the items on the right” qualifier matters. Agile doesn’t reject tools, documentation, contracts, or plans — it just prioritizes their purposes (collaboration, working software, customer value, adaptability).

The 12 principles (skim, don’t memorize)

The Manifesto is backed by 12 principles. The patterns:

You don’t need to recite the 12. Know the themes: short cycles, working software, customer focus, adaptability, team autonomy, reflection.

Common misconceptions

“Agile means no plans”

Wrong. Agile teams plan constantly — sprint plans, roadmaps, release plans. The point is plans are revised as you learn, not treated as contracts.

“Agile means no documentation”

Wrong. Working software is favored over comprehensive documentation — meaning don’t write 200-page specs when a discussion + ADRs + READMEs suffice. Documentation that helps people is welcome.

“Agile means daily standups and sprints”

Those are Scrum’s specific practices. Agile is the philosophy; Scrum is one implementation.

“Agile means we ship fast and skip QA”

Wrong. “Continuous delivery” requires high quality. Skipping QA produces unreliable software, the opposite of working software.

“Agile means we can change requirements anytime without consequence”

Wrong. Changes have costs; Agile makes the cost visible (it’s negotiation-based, story-by-story) instead of pretending no change can happen.

Why Agile arose

Pre-2000, big projects often used Waterfall:

• 6–12 months of requirements gathering.
• 6–12 months of design.
• 6–12 months of coding.
• 6 months of testing.
• 1 day of “Hi, our customer’s needs have changed since the start, this whole thing is wrong.”

The famous “Standish Chaos Report” claimed 80%+ of large IT projects failed or massively overran. Whether the numbers were right, the experience was real.

Agile’s bet: shorter cycles, frequent feedback, working software early — and customers and developers will iterate to the right product instead of trying to specify it perfectly upfront.

Where Agile fits

Agile is right for:

• Software with evolving requirements (most product development).
• Unknown-unknowns — domains where you don’t know what to build until you build something and learn.
• Customers who can collaborate — Agile depends on availability of someone who can decide what to build.
• Teams empowered to make decisions — Agile breaks down without team autonomy.

Agile is wrong (or harder) for:

• Fixed-scope, fixed-budget contracts — common in government / defense. The negotiation model doesn’t fit.
• Safety-critical certification — DO-178C for avionics, IEC 62304 for medical devices. Formal documentation is required; Agile + certification is possible but expensive.
• Hardware-software co-development — long lead times on hardware iteration limit how fast you can adapt.
• Compliance-heavy regulated environments without strong support — pure Agile may clash with audit requirements.

See 04_waterfall.md, 07_comparison_and_choosing.md.

“Agile is dead” — the modern critique

The 2010s saw Agile become the universal default, leading to:

• Cargo-cult Agile: daily standups + Jira boards = “we’re Agile.”
• Agile-as-procurement: vendors selling Agile certifications, “scaled Agile” consultancy.
• Process-heavy Agile: ironically violating the Manifesto’s “individuals over processes.”

Some original Manifesto signatories (Ron Jeffries, Andy Hunt, Dave Thomas) have published essays arguing the movement lost its way. The critique isn’t “Agile is bad” but “what’s called Agile in practice often isn’t.”

The cure: re-read the Manifesto. If your process violates “individuals and interactions over processes and tools,” it’s not Agile regardless of the labels.

Agile in interviews

Common openers:

• “What’s Agile?” — describe the Manifesto and the values, distinguish from Scrum/Kanban specifically. Don’t recite ceremonies.
• “What’s the difference between Agile and Scrum?” — Agile is the philosophy/values; Scrum is one framework that implements Agile.
• “What Agile practices do you use?” — be honest. Specifics: standups, retros, code review, continuous integration. Avoid jargon that’s not real practice.
• “When wouldn’t you use Agile?” — fixed-scope contracts, regulatory-mandated upfront design, hardware with long iteration cycles. Show you can pick the right tool.
• “Tell me about a time Agile worked / didn’t.” — concrete example. If didn’t work: what specifically broke (no PO availability, no team autonomy, fixed-deadline pressure).

The strongest answers acknowledge the Manifesto’s qualifier (process matters but less than collaboration). The weakest equate Agile with sprints + standups.

Interview angle

• “What’s the Agile Manifesto?” — 4 value statements (individuals/interactions, working software, customer collaboration, responding to change), with “while there is value in the right, we value the left more.” Plus 12 principles emphasizing short cycles, frequent delivery, sustainable pace.
• “Agile vs Scrum?” — Agile is the philosophy and values (the Manifesto). Scrum is one specific implementation: roles (PO, SM, dev team), ceremonies (sprint planning, daily, review, retro), artifacts (backlog, increment).
• “What does ‘working software over comprehensive documentation’ mean?” — prioritize shipping working software over writing exhaustive specs. Documentation that helps (READMEs, ADRs, runbooks) is welcomed; speculative 200-page specifications aren’t.
• “When would you NOT use Agile?” — fixed-scope/fixed-budget contracts, safety-critical certification with mandated upfront design, hardware with long iteration cycles, teams without autonomy or PO availability.
• “What’s the most common Agile antipattern?” — cargo-cult ceremonies (daily standup + sprint board = ‘Agile’) while violating “individuals and interactions over processes and tools.” The process becomes the goal.
• “Why did Agile arise?” — reaction to Waterfall’s late discovery of misunderstood requirements. Short cycles + frequent customer feedback to iterate toward the right product.