Other meanings of Agile software development
SOFTWARE ENGINEERING
Agile software development is an iterative software development approach emphasizing collaboration, continuous delivery, and responsiveness to change. It prioritizes working software, frequent feedback, close communication with users and stakeholders, and the ability to revise plans as understanding improves.
Agile software development organizes work into short, repeated cycles that produce usable increments and invite feedback before the next cycle begins. The approach emerged from dissatisfaction with heavyweight, sequential development processes that often delayed testing and exposed misunderstandings only near release. In February 2001, 17 software practitioners published the Manifesto for Agile Software Development, identifying four preferences: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; and responding to change over following a plan.1
The manifesto does not reject the item on the right of each preference; it gives greater emphasis to the item on the left. Its accompanying principles call for early and continuous delivery, welcoming changing requirements, frequent delivery, sustainable development, technical excellence, simplicity, self-organizing teams, and regular reflection. Agile is therefore a family of compatible practices and values rather than a single prescribed method.
Agile teams turn broad goals into a prioritized stream of small, testable slices of functionality. A cycle may be called an iteration, sprint, or flow-based work period, depending on the method used. Teams clarify a goal, select or pull work, build and test it, demonstrate the result, and use feedback to adjust both the product and the process. The Scrum Guide describes Scrum as a lightweight framework built around a Product Goal, a Product Backlog, a Sprint Backlog, an Increment, and defined accountabilities for Product Owner, Scrum Master, and Developers.2
Scrum is only one implementation. Kanban emphasizes visualizing work, limiting work in progress, and improving flow; Extreme Programming gives unusual weight to technical practices such as test-first development, pair programming, continuous integration, and frequent releases. Many organizations combine practices from several methods, although adopting isolated ceremonies without the underlying feedback and quality discipline can produce “cargo-cult Agile.”
Agile planning is progressive rather than absent: teams plan at several horizons, from product strategy and releases to the next iteration or work item. Estimates are treated as forecasts that can change when evidence changes, while prioritization weighs user value, risk, dependencies, cost, and learning. Product roles help decide what problem to address; developers and designers help determine how to solve it; users, customers, operations staff, and other stakeholders supply domain knowledge and feedback.
Continuous delivery extends the iterative idea into the release process. Automated builds, tests, security checks, and deployment pipelines can keep software in a releasable state, allowing small changes to reach users more safely and making defects easier to isolate. Delivery frequency is not itself proof of agility: a team may release often while ignoring usability, reliability, accessibility, or product outcomes. The relevant question is whether the system enables rapid, responsible learning and adaptation.
Agile methods are most useful where requirements, technology, or user understanding are uncertain. Short feedback loops can reduce the cost of discovering wrong assumptions, expose integration problems earlier, and give stakeholders visible evidence of progress. They do not remove the need for architecture, documentation, governance, budgeting, or compliance; instead, those activities are expected to evolve with the product and remain proportionate to risk.
Measurement works best when it combines delivery, quality, and outcome signals. The DORA research program commonly examines deployment frequency, lead time for changes, change failure rate, and time to restore service as indicators of software delivery performance.3 Teams should avoid using velocity, lines of code, story counts, or individual utilization as simplistic targets, because optimization of those measures can encourage larger estimates, fragmented work, local competition, or reduced quality. Retrospectives are intended to turn measurement into concrete experiments rather than surveillance.
Agile has roots in earlier incremental and evolutionary approaches, including iterative development, lean production ideas, rapid application development, and lightweight methods used by small software teams. The 2001 manifesto was signed at a meeting in Snowbird, Utah, but its authors represented several distinct methods rather than a unified framework.1
Agile practices also have important edge cases. Fixed-length iterations can be a poor fit for urgent operational work, making flow-based limits more appropriate. Safety-critical, regulated, or contract-heavy projects may require extensive traceability and formal evidence; these requirements can coexist with iterative development when documentation and verification are produced continuously. Distributed and large-scale teams often need explicit coordination mechanisms, shared architectural decisions, and dependency management, because informal communication becomes less reliable as organizational boundaries grow. Agile therefore describes a way of learning and governing development, not a guarantee of speed or a license to dispense with engineering discipline.
Agile is a broad family of values, principles, frameworks, and engineering practices; no single certification, ceremony, or tool defines it.
Help improve the encyclopedia. Reports go straight to the site manager.