where agile came from

Agile emerged as a reaction to heavyweight, documentation-first processes that struggled whenever requirements changed mid-project — a common reality in software, where nobody fully understands what they need until they see a working version. In 2001, a group of software practitioners formalized the ideas behind lighter, more adaptive ways of working into the Agile Manifesto.

the four values

The manifesto states four value pairs, each phrased as "X over Y":
  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
The manifesto itself is explicit that this is a matter of emphasis, not exclusion: "while there is value in the items on the right, we value the items on the left more." Documentation, process, contracts, and plans all still matter — they just aren't allowed to take priority over people, working results, collaboration, and adaptability when the two conflict.

a mindset, not a single method

"Agile" itself isn't a process you can install — it's a set of values, backed by twelve supporting principles (frequent delivery, welcoming changing requirements even late, sustainable pace, self-organizing teams, among others). Scrum, Kanban, and Extreme Programming (XP) are concrete frameworks that each implement those values differently; adopting one of them is how Agile actually gets practiced day to day, but the values are the thing being adopted, not the ceremonies.

when it fits, and when it doesn't

Agile tends to work well when requirements are genuinely likely to evolve, fast feedback on partial results is valuable, and the team is small enough (or well-connected enough) to coordinate tightly and adjust quickly.
It tends to fit poorly when the deliverable is defined by a fixed-price contract with rigid scope agreed up front, when heavy regulatory documentation and traceability requirements dominate the work, or when physical dependencies make late change extremely expensive (concrete already poured, structural steel already ordered). None of that makes Waterfall obsolete — it makes it the better tool for those specific situations.

a short example

A company runs two projects at the same time. A mobile app team is adding a new feature where requirements will likely shift once real users try an early version — a strong fit for Agile's iterate-and-adjust approach. Meanwhile, the same company's facilities team is relocating to a new office — permits, lease terms, and physical construction sequencing are fixed well in advance, and there's little value in "iterating" on a building's foundation. The facilities project stays on a traditional, predictive plan; forcing it into sprints wouldn't make it any more adaptable, because the actual constraints aren't the kind Agile helps with.

practical notes

Running daily standups and calling work "sprints" without actually embracing the underlying values — welcoming change, prioritizing working results, collaborating closely with the customer — is a common failure mode sometimes called "cargo-culting" Agile. The ceremonies without the values rarely deliver the benefit.
Agile isn't "no planning." It's short planning cycles with fast feedback between them, not the absence of a plan.

related topics

reference