Methodologies & SDLC Deep Dive · 2 of 10

Agile — A Mindset, Not a Process

Seventeen practitioners met at a Utah ski lodge in February 2001 and wrote the Manifesto for Agile Software Development: four value statements, twelve principles. Two decades later "Agile" is everywhere and means almost anything — but the core is unchanged: iterate in short cycles, get real feedback, adapt as you learn.

ManifestoIterationFeedbackWorking software
← Back to Methodologies & SDLC
The Manifesto

Four Values

We have come to value:

  • 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."

Principles in Practice

What Teams Actually Do

  • Deliver working software frequently — weeks, not months.
  • Welcome changing requirements, even late — it's a feature, not a failure.
  • Business and devs work together daily — no spec-and-throw-it-over-the-wall.
  • Build around motivated individuals, give them the environment, trust them.
  • Working software is the primary measure of progress — not Gantt percent-complete.
  • Sustainable pace, indefinitely. Crunch is anti-Agile.
  • Continuous attention to technical excellence enhances agility.
  • Reflect & adjust regularly — the team tunes itself.
Flavors

Agile Is an Umbrella

FrameworkWhat it adds
Scrum →Sprints, roles (PO/SM/Devs), ceremonies (planning, standup, review, retro).
Kanban →Continuous flow, WIP limits, no fixed iterations.
XP →Engineering practices: pair programming, TDD, CI, simple design.
Lean →Eliminate waste, optimize the whole, build quality in.
SAFe / LeSS →Patterns for many teams on one product.
Tradeoffs

What "Agile" Often Becomes

  • Cargo-cult Scrum. Standups with no decisions, story points instead of estimates, retros that produce nothing — process without the mindset.
  • "Agile" as anti-planning. The Manifesto says "responding to change," not "no plan." Teams still need direction.
  • Velocity-as-KPI. Treat velocity as a target and you'll get inflated estimates, not faster delivery.
  • Documentation neglect. "Working software over comprehensive documentation" doesn't mean none — long-lived systems need ADRs, runbooks, onboarding docs.
  • Doesn't fix bad requirements. Iteration only helps if you have someone willing to look at the increment and tell you it's wrong.
Continue

Other Methodologies

← Waterfall Scrum → Kanban → XP → ↑ Back to Methodologies & SDLC