A company signs with a software house whose proposal promises "Agile delivery". Six months later it has seen plenty of meetings, a backlog in the thousands and no working software.
The methodology on the slide matters less than the practices behind it. This guide says honestly which software development methodologies are used in 2026, which are history, and what AI changed.
What is a software development methodology?
A software development methodology is the way a team organizes its work: how it plans, how often it delivers, how it handles changing requirements and how the client stays involved. Like a building plan for a construction crew, it gives everyone the same picture of what happens next.
It is not the same as the technology. Two teams can use the same Java stack and get very different results because one ships working software every week and the other disappears for three months.
Why choosing the right methodology matters
Could a team not just focus on the goal and organize itself as it goes? It could, and that is how most projects end up late, over budget and arguing about what was agreed.
The methodology decides how quickly you see progress, how expensive a change of mind is and how early problems come to light. For the company paying for the software, those three things matter more than any framework's vocabulary.
How to choose a software development methodology
Start with three questions:
- How well do you know what you need? If the requirements will change as users see the product, you need short cycles. If the scope is fixed by a contract or a regulator, more planning up front is justified.
- How involved can you be? Iterative methods need someone on your side who can answer questions and review working software every week or two.
- What does the system have to survive? A system that moves money or must stay up around the clock needs strong testing and release practices, whatever the planning style.
In practice, the answer is rarely a pure methodology. In Digital.ai's 2025 State of Agile survey, 74% of organizations used hybrid, blended or homegrown models (Digital.ai).
Software development methodologies in 2026: an honest overview
Below are the methodologies you will find in proposals and textbooks, starting with the ones teams actually use. Each starts with an honest note on whether anybody still works that way.
Agile
Status in 2026: the default for custom software, though mostly in hybrid form rather than by the book.
Agile is a set of values and principles, written down in the Agile Manifesto in 2001, rather than one process. The idea is to deliver software in short iterations, show it to users and the client, and let their feedback steer the next iteration.
It won because it works for software whose requirements change, which is most software. It also became a label every vendor uses, so check what a team actually does: how often you see working software, and who decides what gets built next.
Pros
- Changes in priorities cost little, because plans are short.
- Working software early and often, so problems show up early.
- The client sees progress and can steer it.
Cons
- Needs a client who is available and makes decisions.
- Easy to fake: ceremonies without working software are not Agile.
- Budget and end date are harder to fix in advance.
Scrum
Status in 2026: the most common Agile framework, usually adapted to the team.
Scrum turns Agile into a concrete routine, described in the Scrum Guide: fixed-length sprints of up to a month, a product owner who orders the backlog, a scrum master who removes obstacles, and four events: sprint planning, the daily scrum, the sprint review and the retrospective.
Most teams use a lighter version, keeping the sprints, the reviews and the backlog while trimming the ceremonies. That is fine, as long as each sprint still ends with working software.
Pros
- A predictable rhythm that clients and teams both understand.
- Regular reviews give the client a fixed moment to steer.
- Retrospectives make the team improve its own process.
Cons
- The ceremonies can grow into overhead for a small team.
- Sprint boundaries fit poorly with support and urgent fixes.
- Depends heavily on a capable product owner.
Lean and Kanban
Status in 2026: widely used, often alongside Scrum, especially for maintenance and support work.
Lean comes from Toyota's manufacturing system and focuses on cutting waste: work that waits, features nobody uses, handovers that lose information. Kanban, its most visible tool, replaces sprints with a continuous flow of tasks across a board, with a limit on how much work can be in progress at once.
It suits teams whose work arrives continuously, such as a support team or a platform team, better than fixed sprints do. Our guide to minimum viable products covers the Lean Startup idea that grew out of the same thinking.
Pros
- Less ceremony than Scrum, and a natural fit for continuous work.
- Work-in-progress limits expose bottlenecks quickly.
- Focuses the team on finishing rather than starting.
Cons
- Long-term planning and deadlines need extra discipline.
- Without the sprint rhythm, reviews with the client can slip.
- Easy to turn into a to-do list with no improvement loop.
DevOps
Status in 2026: standard practice; less a methodology than the way modern software is built, shipped and run.
DevOps joins development and operations: the people who build a system are also responsible for how it runs. In practice that means automated builds and tests on every change, automated deployments, monitoring in production and small, frequent releases.
It sits alongside whatever planning method a team uses. A Scrum team without DevOps practices delivers working software every two weeks that then waits a month to be released.
Pros
- Small, frequent releases are safer than big, rare ones.
- Problems in production are found and fixed faster.
- Automation removes manual, error-prone steps.
Cons
- Takes investment in pipelines, tooling and skills.
- Security and compliance have to be built into the pipeline.
- Hard to retrofit onto old systems without tests.
AI-assisted engineering: an architect in control of the agents
Status in 2026: rising fast, and the approach to look for in a development partner in 2026.
AI coding tools are now everywhere: Digital.ai's survey puts AI adoption at 84% (State of Agile). What matters is how a team uses them. The approach that works is AI-assisted engineering: an experienced engineer, acting as the architect, decides what gets built and how, and AI agents do much of the typing.
In practice, the architect writes the task with its constraints and acceptance tests, agents implement it in small branches and run the build, the pipeline checks the result, and the architect reads every diff before it is merged. The tools are built for this: GitHub's Copilot coding agent, for example, submits its work as a pull request that a person has to approve.
DORA's 2025 research describes AI as "an amplifier" of an organization's existing strengths and weaknesses (DORA 2025). Good tests, small changes and real reviews get faster. Their absence gets faster too. When you evaluate a partner, ask who reads the AI-written code, which tests it has to pass and whether the engineers can explain any part of the system without asking the tool. Our article on the future of software engineering goes deeper into where this works and where it does not.
Pros
- Routine work, such as migrations, tests and boilerplate, gets much faster.
- Engineers spend more time on design, review and the hard parts.
- Large, repetitive changes become affordable, for example upgrading a library across hundreds of files.
Cons
- Only as good as the engineer directing it; review is not optional.
- Generated code needs the same security checks as human code, or stricter.
- Gains are smaller on complex legacy code, where understanding matters most.
Vibe coding
Status in 2026: fine for prototypes and demos; not a way to build systems a business depends on.
Andrej Karpathy coined the term in February 2025 for building software by describing it to an AI and accepting whatever it produces without reading the code, and Collins Dictionary made it word of the year for 2025. Karpathy himself called it "not too bad for throwaway weekend projects".
That is an honest description. Vibe coding is excellent for a clickable prototype to show investors or users, a one-off script or an internal tool for a handful of people. It is a poor way to build anything that stores customer data or moves money: in Veracode's tests of more than 150 models, only 55% of the generated code was secure, and nobody on a vibe-coded project knows what the code does with an edge case.
Pros
- A working demo in hours, by people who do not program.
- A cheap way to test an idea before paying for real engineering.
Cons
- Nobody reads the code, so nobody can vouch for it.
- Security, maintainability and scale are left to chance.
- Prototypes promoted to production become expensive rewrites.
Waterfall
Status in 2026: niche; still used where scope is fixed by contract or regulation, rarely for anything else.
Waterfall runs a project in sequence: all requirements first, then all design, then all development, then testing, then release. Each phase finishes before the next begins.
It is not dead, but it is rare in its pure form. Public tenders with fixed scope, some regulated and safety-critical systems, and hardware-bound projects still plan this way, often with iterative work hidden inside the phases. For most business software it fails for a simple reason: users see the product only at the end, when changes are most expensive.
Pros
- Clear phases, documents and sign-offs, which some contracts require.
- Budget and scope are agreed up front.
Cons
- Users see working software only at the end.
- Changing requirements mid-project is slow and costly.
- Problems surface late, when they are most expensive to fix.
Prototype model
Status in 2026: absorbed; nobody runs projects this way by name, but its core idea lives on in Agile and MVPs.
The prototype model builds a simplified version of the software first, shows it to users, refines the requirements and only then builds the real system. In its day it was a step away from Waterfall.
Today the same idea appears as clickable design prototypes, proofs of concept and minimum viable products, all inside an iterative process rather than as a methodology of their own.
Pros
- Users react to something concrete instead of a specification.
- Misunderstandings surface before the expensive build.
Cons
- Prototypes tend to get mistaken for nearly finished products.
- On its own it says nothing about how to run the rest of the project.
Feature-driven development (FDD)
Status in 2026: rarely used; you will meet it in textbooks more often than in projects.
FDD organizes work around small, client-valued features: build an overall model, list the features, plan by feature, then design and build feature by feature with clear code ownership.
It was designed for large teams in the late 1990s. Its useful ideas, such as small features and a shared domain model, are now part of how most Agile teams work, and few teams choose FDD by name.
Pros
- Clear progress tracking by feature.
- Works with larger teams that need structure.
Cons
- Heavier on up-front modeling than most teams want today.
- Few people have practiced it, so few teams can run it well.
Rapid application development (RAD)
Status in 2026: historical; its ideas live on, the methodology itself does not.
RAD emphasized quick prototypes, user feedback and fast, tool-assisted development over long planning. In the 1990s that was radical.
Today its goals are met by Agile iterations, modern frameworks and, increasingly, AI-assisted engineering. If a proposal in 2026 names RAD as its methodology, ask what it actually means by it.
Pros
- Fast feedback from users.
- Encourages reuse of components and tools.
Cons
- Weak on architecture and long-term maintainability.
- Depends on constant user availability.
- Superseded by practices that do the same job better.
Our approach
Methodology names matter less to us than four habits that make projects predictable, whatever the label:
- A scope and a number first. A short scoping phase ends with a written ballpark estimate and its assumptions, and scope changes are priced before the work starts.
- Working software every week. We plan in short iterations, Scrum-style for new development and Kanban-style for support, and show progress in the running software, not in status reports.
- DevOps from the first commit. Code lives in your repository from day one, with automated tests, builds and deployments.
- AI with an engineer in charge. Our engineers use AI agents for routine work and review every change they produce. On a recent upgrade of a wine merchant's system, more than 800 files were changed by automated refactoring and every change was reviewed (case study).
The people who scope the work are the people who build it: senior engineers who are direct employees, with low attrition, so the team that learns your system stays with it. If you are choosing a team for a Java system, our Java development services start with a scoping call and a written estimate, and our guide to custom software development covers the rest of the process.