The top software development methodologies in use in 2026 are Waterfall, Scrum, Kanban and Extreme Programming, with DSDM and PRINCE2 common in the UK and a group of scaling frameworks for large organisations. They differ mainly in two things: how much is decided before work starts, and how often you see working software. For most business systems the method matters less than whether you and the supplier agree what is being built, how changes are handled and how you will check the result.
This is not a ranking. The methods below are the ones a UK business is most likely to be offered by a supplier or to find its own IT team using, described in the order they are easiest to explain.
The methodologies at a glance
| Method | How the work is organised | Suits |
|---|---|---|
| Waterfall | Phases in sequence: requirements, design, build, test, release | Work that is well understood and unlikely to change |
| Scrum | Fixed-length Sprints of a month or less, each producing usable software | New products and systems where requirements will change as people see them |
| Kanban | A continuous flow of items, with a limit on how many are in progress | Support, maintenance and steady streams of small changes |
| Extreme Programming | Short cycles plus strict engineering practices | Teams that need high quality under frequent change |
| DSDM | Time and cost fixed, features prioritised within them | Projects with a fixed deadline and budget |
| Scaling frameworks | Many teams coordinated on one product | Large organisations with several teams |
Waterfall
Waterfall takes a project through its phases once, in order. Each phase is finished and signed off before the next begins. It is usually traced to a 1970 paper by Winston Royce, which did not use the name and warned that a single pass with no feedback was risky.
Its strength is predictability on paper: there is a full specification, a plan and a price before building starts. Its weakness is that you see working software late, so a misunderstanding in the requirements may not surface until testing, when it is expensive to correct. It remains a reasonable choice where the requirements are fixed by something outside the project, such as a regulation or the interface of another system.
Our comparison of Agile and Waterfall looks at that choice in more detail.
Agile, and why it is not a methodology
Agile is a set of values published in 2001 as the Manifesto for Agile Software Development. Among them are “working software over comprehensive documentation” and “responding to change over following a plan”. It does not tell a team what to do on a Monday morning. Scrum, Kanban, Extreme Programming and DSDM are the methods that do, and when a supplier says “we work in an agile way” it is worth asking which of them they mean.
Scrum
Scrum is the best known of the agile methods. Its definition is the Scrum Guide, last revised in 2020, which calls it a “lightweight framework”. Work is done in Sprints of one month or less. The Scrum Team has three accountabilities: a Product Owner who decides what is most valuable, Developers who build it, and a Scrum Master who is accountable for the team’s effectiveness. Towards the end of each Sprint there is a Sprint Review, where the team and its stakeholders inspect what was built and decide what to do next.
For a customer, the benefit is a regular look at real software. The cost is your time: Scrum depends on a Product Owner who is available and has authority to decide.
Kanban
Kanban manages work as a flow, without fixed-length cycles. Tasks are shown on a board as they move through stages, and the team limits how many can be in progress at once, so that items are finished before new ones are started. It fits work that arrives unpredictably, which is why it is common for support and maintenance. We cover it in reasons to use Kanban.
Extreme Programming
Extreme Programming, or XP, concentrates on how the code is written. Its practices include writing automated tests before the code, working in pairs, and merging and testing everyone’s changes many times a day. Few teams describe themselves as XP teams now, but several of its practices, continuous integration in particular, have become standard and are part of what is now called DevOps.
DSDM
DSDM, the Dynamic Systems Development Method, was created in the UK in 1994 and is now maintained by the Agile Business Consortium. Its distinctive idea is that time and cost are fixed and the feature list is the thing that flexes. Requirements are sorted into Must have, Should have, Could have and Won’t have this time, a technique known as MoSCoW. If time runs short, the lower priorities are dropped and the deadline holds. It is the basis of the AgilePM qualification.
PRINCE2 and the scaling frameworks
PRINCE2 is a project management method, not a way of building software, and it is widely used in the UK, particularly in the public sector. It deals with the business case, roles, stages and reporting. The current version, launched in 2023 and owned by PeopleCert, says explicitly that the delivery work inside a project can be iterative. A project can be governed with PRINCE2 and delivered with Scrum.
Scaling frameworks exist to coordinate many teams working on one product. The best known is the Scaled Agile Framework (SAFe), published by Scaled Agile, Inc. and currently at version 6.0. Disciplined Agile, now owned by the Project Management Institute, is a toolkit for choosing practices to suit the situation.
The “Spotify model” is often listed with these. It comes from a 2012 paper by Henrik Kniberg and Anders Ivarsson describing how Spotify organised its engineers into squads, tribes, chapters and guilds. The paper itself says it is only a snapshot of a way of working that was still changing, so it is better read as a case study than adopted as a method.
A business commissioning one system from one team does not need a scaling framework.
How to choose
Four questions do most of the work.
How well do you know what you want? If you can describe the outcome and how you would check it, a fixed scope is realistic. If you expect to learn as you go, you need a method that shows you working software often.
How likely is change? A method that plans everything first makes change expensive. A method built around short cycles makes it routine.
How much of your time can you give? Scrum and DSDM need a decision-maker from the business throughout. If nobody can be spared, more must be settled at the start.
Is the work a project or a stream? A build with an end date suits Sprints or phases. Ongoing changes to a live system suit Kanban.
In practice most commercial projects are a hybrid. The scope, price and acceptance criteria are agreed first, which is the Waterfall instinct, and the build is then delivered in short cycles with regular demonstrations, which is the agile one. That is how a fixed-price project and iterative delivery fit together.
Questions to ask a supplier about their method
The name of the method tells you little. These answers tell you more:
- How often will we see working software, and can we use it ourselves?
- Who on our side decides priorities, and how much of their time will you need?
- What is agreed in writing before work starts?
- What happens when we ask for a change?
- How do we both know a piece of work is finished?
- What will we own at the end, and could another team pick it up?
Our list of questions to ask a software supplier covers the rest of the conversation.