Agile is a set of principles and values that open up planning, software design and development, architecture, program management, and process improvement to the entire team with the aim of streamlining the delivery of value while remaining responsive to change.
There are many agile methodologies, but they share the following foundational principles.
All work is listed on a product backlog.
Product backlog items are implemented according to priority.
Implementation teams are cross-functional and empowered.
Work in progress (WIP) is limited to the team's capacity. (That is to say, the team does not start on work that it cannot finish without creating a bottleneck.)
Teams strive to continuously improve.
Every agile methodology has its own methods, process, and tools to address these principles and goals. See the links at the bottom of this page for a listing of agile methodologies.
Agile is most often described in contrast to the long-dominant software industry methodology: waterfall. In the waterfall approach, chaos is mitigated by attempting to plan everything up front, enforcing formal change request procedures, and synchronizing work at predefined milestones. Waterfall's weakness is that planning everything in advance gives only an illusion of predictability. Software development inherently has a lot of variability. Unplanned work or changes in priorities always occur, precipitating such constant re-planning in waterfall that contributors and stakeholders lose confidence that any of the constraints (scope, schedule, resources, quality) can be honored.
Rather than fight the reality of variability in software development and the need for shifts in priorities, agile attempts to embrace these by designing them into the process. Where waterfall attempts to predict what scope will be delivered and when, agile promises that when the resources (time, money) run out, the highest priority items will have been delivered.
Plan-driven.
Assumes that the team will get things correct up front. This often means that detailed requirements and design commitments are required before any implementation begins.
Assumes that most pieces will come together at the end.
Suited for well-defined, repetitive work.
Priority-driven.
Assumes that the team will learn about the solution and adapt their approach as they go. Critical (and potentially expensive or irreversible) decisions are delayed until they are better understood.
Avoids a "big bang" delivery by generating early and frequent product increments and feedback.
Suited for inherent uncertainty and/or variability in the work.
For details on particular agile frameworks, see the following pages:
Other agile frameworks include
Video [free] - "What is Agile?" by Mark Shead on YouTube