Agile methodology is a way of running work in short cycles: plan a small piece, deliver it, check it with the people it is for, then adjust the plan before the next cycle. It began in software development, and the same approach is now used for change and improvement work in other kinds of business.
This guide covers where agile came from, the values and principles behind it, the steps in an agile cycle, the main frameworks, how it applies in a project-based business, and the kinds of work it does not suit.
What is agile methodology?
Agile is a set of values and principles for delivering work in small, frequent pieces rather than in one large release at the end. Each piece is reviewed with the people who will use it, and what is learned shapes the next piece.
Strictly, agile is not one method. It is an umbrella for several approaches, such as Scrum and Kanban, used by teams working to the same values. The phrase “agile methodology” is used loosely for this whole family of ways of working.
Three ideas sit underneath all of them:
- Short cycles. Work is broken into pieces small enough to finish in days or weeks.
- Frequent feedback. The result of each cycle is shown to the people it is for, so problems surface early.
- Planning that keeps going. The plan is revisited at every cycle, rather than fixed at the start.
Where did agile methodology come from?
In February 2001, seventeen people met at Snowbird in Utah to look for common ground between the lightweight software methods they used, including Extreme Programming, Scrum, DSDM and Feature-Driven Development, according to the history of the Agile Manifesto. The result was the Manifesto for Agile Software Development.
The Manifesto sets out four values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The line that follows them is often missed: “while there is value in the items on the right, we value the items on the left more.” Agile does not throw away plans, documents, processes or contracts. It treats them as less important than the things on the left when the two pull in different directions.
The values are backed by 12 principles. They include delivering working results frequently, “from a couple of weeks to a couple of months”, welcoming changing requirements even late on, business people and delivery teams working together daily, and teams reflecting at regular intervals on how to become more effective. For how each of the 12 translates into running a business, see the 12 Agile principles applied to business.
How is agile different from a traditional project plan?
The traditional alternative is often called “waterfall”: each stage (requirements, design, build, test, handover) is completed before the next one starts. The GOV.UK Service Manual describes the difference plainly. In waterfall projects, detailed planning is done early, before development, and “it’s rare that you go back and make changes”. In agile, “you change your plans as you do more work and learn more about your users.”
That does not mean agile teams stop planning. The same guidance says “planning is vital to the success of agile working”. The difference is in the level of detail: work a long way off is planned at a high level, and detailed plans are made for the next cycle only.
| Traditional (waterfall) plan | Agile | |
|---|---|---|
| Planning | Detailed, up front | High level for later work, detailed for the next cycle |
| Delivery | One release at the end | Small, usable pieces throughout |
| Feedback | Mostly at handover | At the end of every cycle |
| Change | Handled as a variation to the plan | Expected, and fed into the next cycle |
| Best suited to | Work where the outcome and method are known | Work where the answer is still being found |
What are the steps in an agile process?
The names vary by framework, but an agile cycle follows the same pattern. The steps below use the terms from the 2020 Scrum Guide, with the plainer names used by the GOV.UK Service Manual where they differ.
- Keep a single, ranked list of work (the backlog). Everything the team might do sits in one list, ordered by priority. In Scrum, one person, the Product Owner, is accountable for ordering it.
- Plan the cycle (sprint planning). The team agrees a goal for the cycle, selects the items it forecasts it can finish, and agrees how it will do them. In Scrum, a sprint is a fixed length of one month or less.
- Do the work, with a short daily check-in (the stand-up). The Scrum Guide sets the Daily Scrum at 15 minutes. Its purpose is to inspect progress towards the Sprint Goal and identify anything in the way. It is an event for the people doing the work, not a status report to managers.
- Review the result (the review, or “show and tell”). At the end of the cycle, the team goes through what it has finished with the people it is for, and they agree changes to the backlog.
- Look at how the team worked (the retrospective). The team discusses what went well and what problems it hit, and agrees changes. The Scrum Guide describes its purpose as planning “ways to increase quality and effectiveness.”
- Repeat. The next cycle starts from the updated backlog.
The review and the retrospective are where the inspection and adaptation happen. Without them, short cycles become a series of small deadlines with no learning between them.
Check your business: How improvement work is run
- Does each improvement project have one ranked list of priorities, owned by one named person?
- Do improvement projects deliver something usable within weeks, rather than everything at the end?
- After each piece of work, does the team review what worked and change at least one thing next time?
What are the main agile frameworks?
The GOV.UK Service Manual’s introduction to agile methods describes Scrum, Kanban and Lean as “the 3 most popular agile methods”.
Scrum. A framework built around fixed-length sprints. The Scrum Guide defines three accountabilities (Product Owner, Scrum Master and Developers), four events inside the Sprint, which is itself an event (Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective) and three artefacts (Product Backlog, Sprint Backlog and Increment). It rests on three pillars: transparency, inspection and adaptation.
Kanban. The Kanban Guide defines Kanban as “a strategy for optimizing the flow of value through a process”. It has no fixed cycles. Instead, the workflow is made visible, often on a board, the number of items in progress is explicitly controlled, and flow is tracked with four measures: work in progress, throughput (items finished per week or other period), work item age and cycle time. The Kanban method is often applied to continuous streams of work, such as service requests or office processes.
Lean. The same GOV.UK guide explains that Lean software development, like Kanban, is adapted from lean manufacturing principles such as the Toyota Production System. It focuses on reducing waste, delivering quickly, and learning and improving. For how Lean thinking applies to everyday operations, see lean business improvement.
Other methods represented at the 2001 meeting, such as Extreme Programming and DSDM, are still in use.
How does agile methodology work in a project-based business?
The Scrum Guide notes that Scrum has spread to “many domains holding essentially complex work, beyond software product development”. The test is the type of work, not the industry. Agile fits work where the answer is not fully known at the start and where seeing early results will change what is done next.
In a project-based business, such as an HVAC, electrical contracting or renewables company, that kind of work can sit in how the business runs rather than in the contracted work itself. Examples include:
- Rolling out a new job management or CRM system. Rather than configuring everything and switching over on one date, the business can go live with one team or one workflow, learn from it and extend it cycle by cycle.
- Launching a new service line. A business adding heat pumps or battery storage to its services can test pricing, lead handling and the handover from sales to operations in short cycles, before committing to a full process.
- Fixing a business process. A slow quote-to-cash process, for example, can be improved one step at a time, with each change checked against the numbers before the next one starts.
- Running the management team’s priorities. Some leadership teams use a quarterly backlog, a short weekly check-in and a review at the end of each cycle to keep improvement work moving alongside day-to-day operations.
The same thinking can shape the wider structure of the business. An agile target operating model applies it to how teams, roles and decisions are organised, and agile HR applies it to performance and development.
When does agile methodology not fit?
Agile is built for work where learning along the way changes the outcome. Where the scope, method and standard are already fixed, there is less to learn and less to gain from changing the plan each cycle. Work delivered to a fixed, agreed specification, where the requirements are set outside the team, is an example.
Some businesses therefore run a mix: a conventional plan for contracted work, and agile cycles for improvement and change work.
Four challenges can come up when businesses first try agile:
- Reading “over” as “instead of”. The Manifesto values working results over documentation, not in place of it. Records required by law, by a contract or by a certification body still have to be kept.
- People’s time. Agile asks the people the work is for to take part in reviews and to make decisions on priorities quickly. If they are not available, cycles stall.
- Ceremony without change. Holding stand-ups and sprints while the plan is still fixed in advance adds meetings without the benefit.
- Scaling. Coordinating several agile teams working on connected pieces needs more structure than a single team does, and frameworks for doing this add their own roles and events.
Check your business: Readiness for agile working
- Is it clear which work in the business needs a fixed plan and which work can change as the team learns?
- Do the people who will use the result, such as staff or customers, see it before it is finished?
- Can priorities be decided within days when a team needs a decision, rather than waiting for a monthly meeting?
What does agile working need from leaders?
Agile also changes the leader’s job. Leaders set the goal and the order of priorities, then leave the team to decide how to reach it within the cycle. That depends on clear priorities, quick decisions and a willingness to see unfinished work at the review rather than only the polished result. Agile leadership covers this shift in more detail.
It also depends on a steady operating rhythm: the same planning, check-in and review points, at the same times, every cycle. That rhythm is what lets improvement work move forward alongside the day-to-day running of the business. For more on how agility is measured across a whole business, see business agility assessment.
Frequently asked questions
Agile methodology is a way of delivering work in short cycles, showing the result to the people it is for at the end of each cycle, and adjusting the plan based on what is learned. It was set out in the 2001 Manifesto for Agile Software Development, which drew on software methods already in use, and is now applied to many kinds of change and improvement work.
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. The Manifesto adds that the items on the right still have value, but the items on the left are valued more.
Keep one ranked list of work, plan a short cycle, do the work with a brief daily check-in, show the result to the people it is for, review how the team worked, then start the next cycle from the updated list. In Scrum’s terms, the list is the Product Backlog (an artefact), and the steps are the Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective events.
Agile is the set of values and principles. Scrum is one framework for putting them into practice, with defined accountabilities, events and artefacts, set out in the Scrum Guide. Kanban is another approach, described in the Kanban Guide as “a strategy for optimizing the flow of value through a process”. It is widely used by agile teams and has no fixed-length cycles.
In a waterfall plan, each stage is completed before the next starts and detailed planning happens up front. In agile, work is delivered in small pieces, feedback comes at the end of every cycle, and detailed planning is done one cycle at a time.
Improvement work, such as a new system rollout or a process change, is broken into short cycles with a clear goal for each. The people affected see each result early, and the next cycle is planned around what they found. This keeps the work tied to what the business needs as it learns.
Sources
- Agile Manifesto authors, Manifesto for Agile Software Development (2001)
- Agile Manifesto authors, Principles behind the Agile Manifesto
- Jim Highsmith for the Agile Alliance, History: The Agile Manifesto (2001)
- Ken Schwaber and Jeff Sutherland, The 2020 Scrum Guide (November 2020)
- Kanban Guides, The Kanban Guide (May 2025)
- GOV.UK Service Manual, Agile methods: an introduction (updated 27 July 2016)
- GOV.UK Service Manual, Planning in agile (updated 31 March 2026)
- GOV.UK Service Manual, Agile tools and techniques (updated 31 March 2026)
Sources last checked: October 2026
