The Software Wiki

Agile software development

Properties2
tagsprocess, methodology, fundamentals
aliasesAgile, Agile methodology, Agile development, Agile mindset

4 min read

Agile software development

By Allen Jay Bercero

Agile software development is a family of approaches to building software that deliver in short, repeated cycles, welcome changing requirements, and steer by frequent feedback rather than a fixed up-front plan. It’s defined not by a rulebook but by the values in the Agile Manifesto.

The core bet of agile is the opposite of Waterfall’s: instead of trying to decide everything correctly up front, you accept that you can’t, so you build a small slice, put it in front of users, learn, and adjust, over and over. Each cycle runs through all the SDLC stages in miniature.

Also known as

Agile · “agile development” · (loosely and imprecisely) “agile methodology”

Careful with capitalization in your own writing: Agile (the proper noun / movement) vs agile (the adjective, being flexible). “We’re doing Agile” and “we’re being agile” are different claims.

Don't confuse with

  • Agile (the mindset) vs Scrum / Kanban / XP (the frameworks). Agile is level 2 on the process ladder, a philosophy. You implement it through a framework. “We use Agile” almost always means “we use Scrum or Kanban.”
  • Agile vs Sprints. A sprint is a Scrum practice, not agile itself; Kanban is agile and has no sprints.

Where it came from

Through the 1990s, several practitioners independently built “lightweight” alternatives to heavy plan-driven processes: Scrum, Extreme Programming, Crystal, DSDM, Feature-Driven Development. In February 2001, seventeen of them met in Snowbird, Utah, agreed on the shared name agile, and wrote the Agile Manifesto. Everything called “agile” traces back to that document.

What actually makes an approach agile

Not the tools or the meetings. These underlying habits:

  • Iterative and incremental delivery. Work is sliced into small increments, each built in a short, repeated cycle (an iteration; called a Sprint in Scrum). Each increment is potentially shippable.
  • Embracing change. Requirements are expected to evolve; late change is a competitive advantage, not a failure.
  • Fast feedback loops. Frequent working software → real user/stakeholder feedback → adjust direction.
  • Self-organizing, cross-functional teams. The people doing the work decide how to do it; the team has all the skills needed to deliver.
  • Continuous improvement. The team regularly inspects and adapts its own process (the retrospective habit).

In plain English

Don’t plan the whole trip in advance and hope. Take one short leg, check the map, and correct course, again and again.

The frameworks under agile

Agile is the umbrella; you actually work in one of these (see Software development process for the full family tree):

FrameworkOne-line identity
ScrumFixed sprints, three accountabilities, five events. The most common.
KanbanContinuous flow, visualize work, limit work-in-progress. No sprints.
Extreme programming (XP)Agile focused on engineering discipline (pairing, TDD, CI).
Lean software developmentEliminate waste, optimize the whole system.
Scrumban / SAFe / LeSSHybrids and frameworks for scaling agile across many teams.

Common misconceptions

"Agile means...". No, it doesn't

  • “…no documentation.” No: it means just enough documentation. (Manifesto value 2 explicitly says documentation has value.)
  • “…no planning.” No: agile plans continuously and in detail for the near term, rather than exhaustively once for the whole project.
  • “…no deadlines or discipline.” Often the reverse: fixed-length cycles and definition-of-done impose more rhythm and discipline than loose plan-driven projects.
  • “…just doing standups and sprints.” Doing the ceremonies without the values is cargo-cult agile, sometimes called “dark agile” or “agile in name only” (AINO).

See also

References

Graph View

Backlinks