TL;DR
Agile software development uses short learning cycles, frequent delivery, close collaboration, and adaptation. Agile is an umbrella for values and principles rather than one prescribed process. A team still plans, designs, develops, tests, releases, and operates software, but it performs much of that work repeatedly as the product evolves.
Software projects contain uncertainty. Users may understand their needs differently after seeing a working feature. A technical assumption may fail during implementation. A competitor, regulation, or business priority may change while the product is being developed.
Agile software development organizes work so that the team can learn from these events and respond without treating the original plan as permanent.
What does Agile mean?
In software development, Agile describes approaches aligned with the values and principles published in the 2001 Manifesto for Agile Software Development.
Agile is not a single methodology with one set of roles, meetings, or documents. It is a foundation that has influenced frameworks and methods such as Scrum and Extreme Programming (XP), an Agile method that emphasizes disciplined engineering practices. A team can also use Kanban to improve workflow while working in an Agile way.
The word agility means the ability to respond effectively when new information appears. This requires more than speed. A team needs:
- a clear product direction
- frequent evidence about progress and user needs
- technical practices that make change safe
- access to people who can make decisions
- enough authority to adjust its plan
Rapid activity without learning produces more output, but it may not produce a useful product.
Why Agile emerged
Many software teams once relied on development processes with large batches of analysis, design, coding, and testing. Months could pass before users saw working software. If an early assumption was wrong, the team might discover it after making expensive commitments.
The Agile Manifesto brought together lessons from several lightweight software-development methods. Its authors emphasized:
- delivering useful software early and frequently
- keeping business representatives and developers in regular contact
- accepting that requirements can change
- maintaining technical quality
- reflecting on the team’s effectiveness
Agile therefore changes the feedback pattern of the SDLC. Decisions are made using smaller pieces of working software and more recent information.
The four Agile values
The Manifesto presents four preferences. Each compares two useful things and gives greater weight to the item that helps learning and delivery.
| Agile gives greater emphasis to | While still valuing |
|---|---|
| people collaborating effectively | defined processes and tools |
| usable software | detailed documentation |
| ongoing customer participation | contracts and commercial agreements |
| adapting to new information | following an agreed plan |
These values are easy to misread.
- People over processes does not remove process. It asks whether the process helps people solve the problem.
- Software over documentation does not make documentation waste. Teams should create the documentation needed to use, operate, govern, and maintain the product.
- Collaboration over contracts does not remove commercial responsibilities. A contract cannot replace regular decisions with the people who understand the need.
- Responding to change over following a plan does not remove planning. Plans are updated when evidence changes.
The values guide trade-offs. They are not a checklist for declaring that a team is Agile.
The principles in practical groups
The twelve principles behind the Agile Manifesto can be understood through four themes.
Deliver value and learn early
Agile teams aim to deliver valuable software frequently. A smaller delivery exposes assumptions sooner and limits how much work depends on them.
Value means a useful outcome for a customer, user, or organization. Finishing a feature is output. Reducing the time required to book an appointment is an outcome. The distinction matters because a team can complete planned work without improving the user’s situation.
Frequent delivery also supports feedback. Feedback is information about a result that can influence the next decision. It can come from users, business results, tests, production data, or the team’s own experience.
Collaborate around the product
Business representatives and technical specialists need regular contact. This reduces the delay between discovering a question and making a decision.
Agile approaches place work with motivated, supported people and allow them to organize the details. A self-managing team decides how to perform its work within its goals and constraints. Self-management does not remove accountability, leadership, or organizational boundaries.
The original principles refer to face-to-face conversation as the most effective communication method. Modern distributed teams can preserve the underlying intent through direct, timely communication supported by written decisions and shared tools.
Maintain technical quality and a sustainable pace
Frequent delivery is difficult when the software is fragile. Automated unit tests, clear design, code review, and controlled deployment keep change affordable. Continuous integration also helps by merging small changes frequently and verifying them through an automated build and tests.
A sustainable pace is a rate of work that the team and its stakeholders can maintain without depending on repeated overtime or exhaustion. Short bursts may occasionally be necessary, but chronic urgency weakens quality and learning.
Agile also values simplicity, meaning the team avoids unnecessary work and complexity. Simplicity does not mean careless design. It means solving the current problem clearly while preserving realistic paths for change.
Inspect and adapt
Teams periodically examine the product, their results, and the way they work. Inspection makes the current condition visible. Adaptation changes the product or process based on what was learned.
Reflection must lead to a practical adjustment. A meeting that identifies the same problem every month without changing anything has not completed the learning cycle.
Iterative and incremental development
Agile approaches are usually both iterative and incremental:
- Iterative development revisits and improves a solution through repeated cycles.
- Incremental development adds usable capability in smaller parts rather than delivering the entire product at once.
These ideas are different. A team can repeatedly improve a design without releasing another capability, which is iterative but not incremental. It can also add planned modules one after another without changing its understanding, which is incremental but weakly iterative.
Agile teams combine them so each increment creates evidence for the next iteration.
flowchart LR D["Choose a valuable problem"] --> P["Plan a small increment"] P --> B["Design, build, and test"] B --> R["Release or demonstrate"] R --> O["Observe results and gather feedback"] O --> A["Adapt the product and plan"] A --> P
An iteration is one learning cycle. Some methods give iterations a fixed duration. Scrum calls its fixed-length cycle a Sprint. Agile itself does not require Sprints or a particular schedule.
How Agile changes SDLC work
The SDLC activities remain necessary. Agile changes their timing, size, and relationship.
| SDLC activity | How it commonly works in an Agile approach |
|---|---|
| Discovery and planning | Product direction is established, while detailed planning continues as evidence emerges. |
| Requirements | Near-term needs receive more detail; later possibilities can remain broader until they approach implementation. |
| Design | Important architecture is considered early, then refined as the product and risks become clearer. |
| Development | Small changes are integrated frequently and kept close to a usable state. |
| Testing | Testing occurs alongside development, with automation providing rapid feedback where appropriate. |
| Release | Usable increments can be released when they provide value and satisfy release controls. |
| Operations | Production behaviour and user outcomes inform product decisions. |
| Maintenance | Defects, security work, improvements, and maintenance created by earlier technical shortcuts compete transparently with feature work. |
This does not mean every activity must start and finish inside every iteration. Product discovery may look several increments ahead. A major architecture change may span several cycles. Production operations continue every day.
The goal is to avoid long periods in which analysis, code, or design grows without meaningful verification.
Planning and requirements in Agile
Agile planning works at several levels:
- Product direction describes the outcome and users the product exists to serve.
- A roadmap communicates likely product outcomes or areas of investment over time.
- Near-term planning selects a small result that moves the product forward.
- Daily planning coordinates the work needed to produce that result.
Plans become more detailed as work approaches and uncertainty falls. This is sometimes called progressive elaboration, meaning details are developed gradually rather than guessed far in advance.
Requirements may be held in a backlog, an ordered collection of potential product work. Backlog items can be user stories, defects, experiments, technical improvements, research, or any other work needed for the product.
A user story is one optional way to express a need from a user’s perspective. Agile does not require user stories, a particular estimation method, or a particular backlog tool.
Teams still need clear acceptance criteria, security requirements, regulatory evidence, and architectural constraints. Agile changes when and how those details are developed; it does not make them unnecessary.
Working software and quality
Working software is strong evidence of progress because people can use or inspect real behaviour. “Working” should mean more than code running on a developer’s computer.
A usable increment may need:
- code review and automated tests
- integration with other components
- security and privacy checks
- accessibility verification
- operational monitoring
- documentation and support preparation
- deployment through a controlled process
The exact quality standard depends on the product. A medical system and an internal experiment carry different risks. Both need an explicit understanding of what acceptable quality means.
Quality cannot be postponed indefinitely while the team produces features. Hidden unfinished work accumulates and makes later delivery slower and less predictable.
Agile and Lean
Agile and Lean share ideas, but neither is a prerequisite for understanding the other.
Lean thinking and practice focuses on creating needed value with fewer resources and less waste, improving the flow of work, learning through experimentation, and respecting the people doing and receiving the work. The Lean Enterprise Institute describes Lean as both a way of thinking and a practical discipline.
Agile software development has its own history and source documents. Its overlap with Lean includes:
- starting from customer value
- reducing large batches and long feedback delays
- making work and problems visible
- improving continuously
- giving capable people responsibility for the work
Calling Agile “Lean applied to software” hides useful differences between their histories and practices. Lean can inform an Agile team, while Agile values can be applied without adopting a complete Lean management system.
Agile, Scrum, and Kanban
These terms describe different layers:
| Term | What it provides |
|---|---|
| Agile | values and principles that guide software-development decisions |
| Scrum | a framework with defined accountabilities, events, artifacts, and rules |
| Kanban | a strategy for defining, managing, and improving the flow of work |
Scrum is one way to organize iterative and incremental work. Kanban can support an Agile approach and can also be used in other settings. A team may combine Scrum with Kanban practices, provided it still follows Scrum’s core definition when it claims to use Scrum.
When an Agile approach helps
Agile approaches are useful when:
- requirements are likely to change as people learn
- users or business representatives can provide regular feedback
- the product can be divided into meaningful increments
- technical practices allow frequent integration and testing
- the team can adjust its plan within business constraints
Agile requires tailoring when work has long hardware lead times, tightly coupled dependencies, safety-critical approvals, or contracts that assume a fixed scope. These conditions do not automatically rule it out. They change the length of feedback loops and the evidence required before release.
Some uncertainty cannot be removed by working faster. A team may need research, architectural experiments, regulatory review, or supplier coordination before a usable increment is possible.
Example: online appointment booking
A clinic wants patients to book appointments without calling reception. The initial idea includes account creation, appointment search, booking, cancellation, reminders, payments, and reporting.
Building everything before asking patients to use it creates several untested assumptions. An Agile approach could begin with a smaller result:
- Interview patients and reception staff to identify the largest scheduling problem.
- Build appointment search and a basic booking path for one clinic.
- Test security, accessibility, concurrent booking, and operational support.
- Release to a limited group of patients.
- Measure completed bookings, failed attempts, cancellations, and support requests.
- Use the evidence to decide whether cancellation, reminders, or another improvement should come next.
The team still performs requirements, design, development, testing, and deployment. It makes a smaller commitment, observes the result, and then decides what deserves further investment.
Common misunderstandings
- Agile means no planning: Agile teams plan frequently at different levels and update those plans as they learn.
- Agile means no documentation: Useful documentation remains part of the product and its governance.
- Agile means every request is accepted: New work is evaluated and ordered. Constant interruption prevents existing work from finishing.
- Agile means faster delivery: Short feedback loops can reduce wasted effort. Speed still depends on skills, system design, dependencies, and decision-making.
- Agile means Scrum: Scrum is one framework that can support Agile development.
- Every iteration must release to production: Each iteration should create useful evidence and, in many approaches, a usable increment. Business, safety, or market conditions may determine release timing.
- Architecture will emerge without deliberate work: Architecture can evolve, but important risks and constraints still need active design.
- Agile guarantees success: It exposes evidence sooner. People must still make sound product and engineering decisions.
Summary
- Agile is an umbrella for software-development values and principles, not one prescribed process.
- Agile teams reduce the size of commitments and use frequent feedback to guide later work.
- Iteration improves a solution; incremental delivery adds usable capability.
- Planning, documentation, architecture, testing, and governance remain necessary.
- Lean and Agile overlap around value, flow, learning, and improvement, but they are distinct bodies of practice.
- Scrum and Kanban can help organize Agile work, but neither defines Agile by itself.
Related topics
- Software Development Life Cycle
- SDLC Development Approaches
- The Scrum Framework
- SDLC Development Practices