Agile is an approach to building software, and increasingly other kinds of projects, in which a team delivers working pieces in short cycles, typically one to four weeks, shows each piece to the people who will use it, and adjusts what comes next based on what they learn. Instead of agreeing every requirement at the start and delivering everything at the end, Agile accepts that needs will change and builds that change into the way work is planned, priced and reviewed.
At a glance
- Agile is a family of practices, not one method: Scrum and Kanban are two widely used examples.
- Work is delivered in small increments that users can see and test early.
- Priorities are revisited regularly, so scope often changes during the project.
- It suits work where requirements are uncertain or likely to evolve.
- For buyers, it changes how contracts, budgets and acceptance are written.
What problem it solves
Large software projects run as a single plan often fail in a familiar way: months of work, a big reveal, and a product that no longer matches what the business needs, because the business changed or because written requirements didn’t capture what people meant. By then, much of the budget is gone.
Agile reduces that risk by shortening the gap between deciding and seeing. Each cycle produces something users can try, so misunderstandings surface in weeks rather than at the end. Priorities can shift toward what turns out to be most valuable, and lower-value features can be dropped. For the buyer, the benefit is earlier visibility and more control over where money goes. The trade-off is less certainty, at the start, about exactly what will be delivered by a given date and price.
How it works
Backlog. Work is held in a prioritized list of features and tasks, often written as short descriptions of what a user needs. The customer or product lead decides the order.
Short cycles. The team takes the top items, builds them, tests them and aims to produce a working increment at the end of each cycle. In Scrum these cycles are called sprints; Kanban uses a continuous flow instead.
Feedback. Increments are shown to users or stakeholders, and what is learned feeds back into the backlog.
Small, cross-functional teams. Developers, testers and designers typically work together rather than handing work from one department to the next.
Supporting practices. Many Agile teams use automated testing and continuous integration and continuous delivery (CI/CD) so each increment can be released safely. Agile overlaps with DevOps, which extends similar thinking to how software is deployed and run.
Shortcuts taken to hit a cycle’s goals can build up as technical debt, so healthy teams set aside time to pay it down.
When it matters for buyers
In the statement of work. A vendor’s Agile delivery shows up directly in the statement of work (SOW). Instead of a detailed list of features with fixed acceptance tests, an Agile SOW often defines the team, the cycle length, the review rhythm, how the backlog is prioritized and who signs off each increment. Read it for what you are actually committing to: a team’s time, a set of outcomes, or both.
Fixed scope versus time and materials. Agile fits most naturally with time-and-materials pricing, where you pay for the team’s time and steer what it builds. That gives flexibility but puts the risk of overruns on you. Fixed-price, fixed-scope contracts put more risk on the vendor but fit poorly with changing priorities. Many buyers use hybrids: a fixed budget per release or per sprint, a capped total, or a fixed price for a first phase with the rest priced once scope is clearer.
In software implementations and outsourcing. Integrators implementing ERP or CRM platforms often describe their method as Agile. So do IT outsourcing providers. The label covers a wide range of real practice, so ask how it works day to day.
Questions to ask vendors
- What does Agile mean in your delivery: which framework, what cycle length and which meetings will we attend?
- Who on our side needs to be available to prioritize work and review increments, and how much of their time does it take?
- How is the contract priced, and what happens to cost and timeline when we change priorities?
- How is each increment accepted, and what counts as “done”?
- What documentation, tests and handover materials will we receive?
- How do you report progress and budget burn, and how often?
- How do you manage technical debt and quality under deadline pressure?
How it differs from Waterfall
Waterfall runs a project as a sequence of phases, such as requirements, design, build, test and deploy, with each phase largely finished and signed off before the next begins. It aims for predictability: scope, price and dates agreed up front, with changes handled through formal change requests. Agile aims for adaptability: scope is expected to move, and the plan is revised every cycle. Waterfall can suit work with stable, well-understood requirements or heavy regulatory sign-off; Agile tends to suit work where users’ needs will become clearer as they see the product. Many real projects mix the two, for example a fixed design phase followed by Agile build cycles.