A program manager at an insurance company is replacing a claims system that has run for fifteen years. Three vendors answer the request for proposal. The first proposes Scrum on time and materials with two-week sprints. The second offers a fixed price, a detailed specification and a single go-live in eighteen months. The third suggests a three-month discovery phase, then sprints, then a formal acceptance stage run by the compliance department. Each vendor is convinced its model is the right one. The program manager has to decide which risk the company actually wants to carry.
That is the real question behind choosing a software development model. It is not “Agile or Waterfall” as a matter of taste. It is a choice about when you learn what you got wrong, who pays for it and how much evidence you need along the way. The same team can succeed with one model and fail with another on the same project.
Below we compare seven models that program managers meet in practice — Waterfall, the V-model, incremental and iterative development, Spiral, RAD and prototyping, Agile frameworks and hybrids. For each we show where it came from, what risk it manages and where it breaks. At the end you will find a decision matrix you can apply to your own project.
What is a software development model, and why does the choice matter?
A software development model — also called an SDLC model or process model — defines the order in which a team moves through the stages of the software development life cycle: requirements, design, build, test, release and maintenance. It answers three questions: are these stages done once or repeatedly, how long is each cycle, and when does working software first reach real users?
The choice matters because each model moves the moment of truth. In a sequential model, the organisation finds out whether the requirements were right at acceptance testing, often a year or more after they were written. In an iterative model it finds out every few weeks, at the price of less certainty about the final scope and cost at the start. Neither is free. You either pay for late discovery in rework or pay for early discovery in a less predictable plan.
Three project attributes drive the right choice more than anything else:
- Requirements stability — how likely it is that what you specify today will still be right when the software goes live.
- Cost of a late change — cheap in a web application deployed daily, very expensive in firmware in a car or a certified medical device.
- Evidence requirements — how much documented proof of verification a regulator, auditor or client demands.
A fourth factor, often ignored until it hurts, is the contract. A development model and a commercial model have to fit each other. We come back to that in a separate section, because this is where many well-run projects end up in dispute.
How does the waterfall model work, and when is it still the right call?
The waterfall model runs the stages in a fixed sequence: requirements, analysis, design, coding, testing and operation. Each stage finishes, is signed off and hands its output to the next. We describe the phases, advantages and drawbacks in detail in our guide to the waterfall model and when to use it; here we focus on how it compares with the alternatives.
The model is usually traced to Winston Royce’s 1970 paper “Managing the Development of Large Software Systems”. The irony is well documented: Royce drew the sequential diagram and then wrote that this implementation “is risky and invites failure”, because testing at the end is the first moment when timing, storage and interfaces are experienced rather than analysed. He recommended feedback between stages, early prototyping and doing the job twice. The industry adopted the picture and skipped the warnings.
Waterfall still earns its place in specific conditions:
- Stable, well-understood requirements, such as a regulatory report with a fixed format, a migration of a known system to a new platform or a replacement of a component with a clear interface.
- A high cost of late change, where hardware, certification or physical deployment makes frequent releases impossible.
- A fixed-price, fixed-scope contract, where both sides need a complete specification to agree a price.
- Distributed accountability, where different organisations own different stages and hand-offs must be formal.
Its weakness is equally specific. If requirements are wrong or change, the cost appears at the end, when it is highest and time is shortest. For products whose users you do not yet understand, that is a structural flaw, not a management problem.
What does the V-model add, and why do regulated industries use it?
The V-model is a sequential model folded in half. The left arm descends through requirements, system design, architecture and detailed design. The bottom is coding. The right arm climbs back through unit, integration, system and acceptance testing — and each test level is paired with the design level opposite it. Acceptance tests verify requirements, system tests verify the system design, integration tests verify the architecture, unit tests verify the detailed design.
That pairing is the whole point. Test cases are planned when each design artefact is written, not after the code exists, and every requirement is traceable to the test that proves it. For an auditor, this traceability is more valuable than any individual test.
The best-known formal version is the German V-Modell. It was developed from 1986 by IABG for the Federal Ministry of Defence, made mandatory for defence projects in 1991 and extended to civilian federal agencies in 1992. V-Modell 97 became the standard for federal IT systems, and in 2005 it was replaced by V-Modell XT, which is modular and allows incremental and agile tailoring.
Today the V-model is the reference structure in automotive software. Both ISO 26262 (functional safety of road vehicles) and Automotive SPICE — whose version 4.0 was published by the VDA in 2023 — describe development as a left-hand side of requirements and design and a right-hand side of verification from unit to system level. A supplier that cannot show that structure will struggle in an assessment.
A common misconception is that other regulated domains require the V-model. They do not. IEC 62304, the standard for medical device software, states explicitly that it “does not prescribe a specific life cycle model”; its Annex B lists waterfall, incremental and evolutionary strategies as examples. AAMI TIR45 describes how agile teams can produce the required evidence incrementally. What regulators require is planning, traceability and verification evidence — the V-model is one convenient way to deliver them, not the only one.
How do incremental and iterative models reduce risk?
Incremental and iterative development are often mentioned together, but they solve different problems.
Incremental development splits the system into pieces that are delivered one after another, each adding usable functionality. The first increment might handle claims registration, the second assessment, the third payments. Requirements for the whole system may be known up front; what is staged is delivery. The benefit is earlier value and earlier feedback on real use.
Iterative development repeats the whole cycle — analysis, design, build, test — on the same area, improving it each time. The first iteration of the assessment module might be crude, the third production-ready. The benefit is learning: each pass corrects what the previous one got wrong.
In practice most modern approaches are both iterative and incremental, and so are all Agile frameworks. Before Agile had a name, the Rational Unified Process (RUP) formalised the combination with four phases — inception, elaboration, construction and transition — each consisting of iterations.
A common first increment is a minimum viable product — the smallest release that lets real users test the core assumption. An MVP is not a prototype: it runs in production, handles real data and has to be maintained. Scoping it well is one of the most valuable decisions a program manager makes, because everything the MVP leaves out becomes an option rather than a commitment.
The risk these models reduce is integration and assumption risk. Instead of one big-bang integration at the end, the system is integrated and tested many times. Instead of one set of assumptions validated at acceptance, assumptions are tested at every increment. The price is architectural discipline: without a sound architecture and automated tests, each new increment breaks the previous ones, and the model degrades into constant rework.
What is the spiral model, and when is risk-driven development worth the overhead?
Barry Boehm described the spiral model in 1986 in ACM SIGSOFT Software Engineering Notes and brought it to a wider audience in IEEE Computer in 1988. Its defining feature is that it is risk-driven: each loop of the spiral starts by identifying the biggest remaining risks and chooses activities to reduce them.
Each loop passes through four quadrants: determine objectives and constraints, evaluate alternatives and resolve risks, develop and verify the next level of the product, and plan the next loop. If the biggest risk is an unclear user interface, the loop builds a prototype. If it is performance, the loop builds a benchmark. If requirements are well understood, the loop may look like a small waterfall. The spiral is, in effect, a model for choosing models.
The spiral model is worth its overhead when:
- The project is large, expensive and novel — a new platform, a new technology, a new market.
- Failure is costly and the organisation needs explicit go/no-go decisions after each loop.
- There is time for formal risk analysis and people who can do it well.
It is rarely a good fit for small projects. The planning and risk analysis per loop can cost more than the risks they remove. It also depends heavily on the skill of the people assessing risk: a spiral run by a team that underestimates risk is simply a slow waterfall.
The spiral model’s lasting contribution is its question, not its diagram. “What is the biggest thing that could sink this project, and what is the cheapest way to find out now?” is a question every program manager should ask at every phase gate, whichever model is in use.
When do RAD and prototyping make sense?
Rapid Application Development (RAD), popularised by James Martin in the early 1990s, replaced long specification with fast cycles of user workshops, prototyping and construction with high-productivity tools. Its modern descendants are low-code platforms and much of today’s internal-tool development. RAD works best for business applications with a clear user group, moderate technical complexity and users who are available to give feedback every week.
Prototyping is narrower: building a model of the system — clickable mock-ups, a throwaway proof of concept or an evolutionary prototype that grows into the product — to learn before committing. We describe the technique in our article on rapid prototyping.
Two rules separate successful prototyping from expensive confusion:
- Decide up front whether the prototype is throwaway or evolutionary. A throwaway prototype optimises for speed of learning and must be discarded. An evolutionary prototype must be built with production quality from day one. Treating a throwaway prototype as the first release is one of the most common sources of technical debt.
- Prototype the riskiest part, not the easiest. A beautiful prototype of the login screen tells you nothing. A rough prototype of the calculation engine or the integration with a legacy core system tells you whether the project is feasible.
RAD and prototyping struggle in large systems with complex integrations, strict non-functional requirements or users who cannot commit time. Without user involvement, fast cycles produce fast mistakes.
How do Agile, Scrum and Kanban differ as development models?
In February 2001 seventeen practitioners met at Snowbird, Utah, and wrote the Manifesto for Agile Software Development: four value statements and twelve principles. Agile is not a single model but a family of approaches that share iterative-incremental delivery, close collaboration with the business and a preference for responding to change over following a plan.
The two most widely used frameworks differ in how they organise flow:
- Scrum works in fixed timeboxes (sprints of up to a month, usually two weeks) with three accountabilities — Product Owner, Scrum Master and Developers — and defined events. The 2020 Scrum Guide, published by Ken Schwaber and Jeff Sutherland in November 2020, introduced the Product Goal and made each artefact carry a commitment: the Product Goal for the backlog, the Sprint Goal for the sprint and the Definition of Done for the increment. Scrum suits product development with a stable team and a backlog that can be prioritised every few weeks.
- Kanban has no sprints. Work flows continuously through visualised stages with limits on work in progress, and the team optimises lead time. Kanban suits maintenance, support, platform teams and any work that arrives unpredictably.
According to the 17th State of Agile report by Digital.ai, Scrum remained the most popular team-level framework, used by 63% of agile respondents. The 18th edition stopped asking about team frameworks and instead found that 48% of respondents use hybrid delivery models and 26% homegrown ones.
For scaling across many teams there are frameworks such as SAFe, LeSS and Nexus, which we cover in our glossary entry on scaling agile. They add coordination layers and should be adopted only when simple team-to-team coordination demonstrably fails — not as a starting point.
Modern Agile teams rarely stop at the framework. DevOps practices — continuous integration, automated testing and continuous delivery — shorten the path from a finished backlog item to software in production from weeks to hours. They also change the economics behind the model choice: when a release costs almost nothing, the argument for large, infrequent releases weakens, and the cost of a late change falls for every model, including sequential ones. A Waterfall project with an automated test suite and a deployment pipeline is far less fragile than one tested manually at the end. When comparing vendors, ask not only which model they propose but how much of their delivery pipeline is automated.
Agile’s main requirement is often underestimated: an available, empowered business representative. Without a product owner who can make decisions every week, sprints produce increments nobody validates, and the model loses its only real advantage over a sequential plan.
What are hybrid models such as Water-Scrum-Fall, and do they work?
In 2011 Forrester analyst Dave West described what he saw in most organisations as Water-Scrum-Fall: a waterfall-style up-front phase of planning, budgeting and requirements; Scrum-style development in sprints; and a waterfall-style release stage with formal testing, approvals and deployment. He presented it as the reality of Agile in most companies, not as a recommendation.
A decade later, hybrids are the norm rather than the exception, as the State of Agile data shows. The question is not whether to mix models, but whether the mix is deliberate. Hybrids that work share three traits:
- A time-boxed front end. A discovery phase of weeks, not months, that produces a vision, an architecture outline, a prioritised backlog and a budget range — not a complete specification. Process models, such as the BPMN diagrams we describe in a separate guide, belong here.
- Iterative build with real increments. Sprints end with integrated, tested software, not with “development done, testing later”.
- A back end that is automated rather than bureaucratic. Release approvals are based on evidence produced continuously — automated tests, traceability, security scans — not on a months-long test phase after the last sprint.
Hybrids fail when the waterfall parts dominate: a six-month specification phase followed by sprints that merely implement the specification, then a three-month test phase that discovers the problems. That is Waterfall with extra meetings — slower than either pure model.
A useful variant for regulated work is V-model at system level, Agile at software level: requirements, system architecture and final validation follow a V structure with formal gates, while software components are built iteratively inside that frame. Many automotive and medical device teams work this way.
How does the development model shape the contract and the budget?
The development model and the commercial model have to fit, or the contract will fight the process. The most common mismatch is a fixed-price contract combined with Agile delivery and an open backlog. The client expects a fixed scope for a fixed price, the vendor expects to reprioritise every sprint, and every change becomes a negotiation.
The logic is simple. A fixed price requires a fixed scope, and a fixed scope requires stable requirements — the conditions in which sequential models work well. As we explain in our article on who really pays for risk transfer in fixed-price software, a vendor prices uncertainty as risk and adds it to the price. The less stable the requirements, the higher the premium.
Typical pairings that work:
| Development model | Commercial model that fits | What is fixed | What is variable |
|---|---|---|---|
| Waterfall, V-model | Fixed price, milestone payments | Scope, price, date | Little — changes go through change requests |
| Incremental | Fixed price per increment | Scope and price of the current increment | Scope of later increments |
| Spiral | Phase-gated budget | Budget per loop | Everything after the next go/no-go decision |
| Agile (Scrum, Kanban) | Time and materials, or capped budget with a fixed team | Team, cadence, budget ceiling | Scope |
| Hybrid | Fixed-price discovery, then time and materials or capped delivery | Discovery deliverables and price | Delivery scope within a budget range |
For Agile delivery, a capped budget with a fixed team and a variable scope often gives the client the predictability it needs without pretending the scope is known. Progress is measured by working increments and the prioritised backlog shows what will not fit. Our guide to software project estimation explains how to build a budget range that such a contract can rely on.
The staffing model matters as well. A vendor-managed team delivering a fixed scope carries delivery risk itself, while specialists who join your own team through staff augmentation work inside whatever model you run — which means the model, the backlog and the acceptance of increments stay your responsibility. Neither is better in general, but the development model has to say clearly who plans, who prioritises and who accepts.
Whatever model you choose, write it into the contract explicitly: cadence, acceptance criteria per increment, how changes are handled and who has authority to reprioritise. A contract that is silent on the model leaves both sides to assume their own.
What does the evidence say about success rates of different models?
The most quoted figure comes from the Standish Group. In the widely cited summary of its CHAOS 2020 data, 42% of Agile projects were successful, compared with 13% of Waterfall projects, and 11% of Agile projects failed outright against 59% of Waterfall projects. Standish defines success narrowly — on time, on budget and with satisfactory results.
Those numbers are useful as a signal, but they need three caveats before they go into a steering committee presentation:
- The populations differ. Organisations choose Waterfall for large, complex, contract-driven projects and Agile for product work with engaged stakeholders. The model and the project type are correlated, so the comparison is not like-for-like.
- Definitions shape results. A project that delivered on time with a reduced scope counts differently from one that delivered the full scope late. Agile projects vary scope by design, which flatters them on time and budget measures.
- Methodology has been criticised. Researchers have questioned Standish’s sampling and definitions for years. Treat the figures as indicative, not as a law.
What the evidence consistently supports is less dramatic and more useful: shorter feedback loops reduce the cost of being wrong. Whether you get them from sprints, increments, prototypes or spiral loops matters less than whether you get them at all. A Waterfall project with early prototypes and staged integration is less risky than a Scrum project whose increments are never shown to users.
How do you choose a software development model for your project?
No model is best in general. The matrix below summarises when each one fits. Score your project on the rows and look for the column that matches most often. If two columns tie, the hybrid usually wins.
| Project attribute | Waterfall | V-model | Incremental / iterative | Spiral | RAD / prototyping | Agile (Scrum, Kanban) | Hybrid |
|---|---|---|---|---|---|---|---|
| Requirements stability | High | High | Medium | Low to medium | Low | Low | Medium |
| Cost of late change | High | Very high | Medium | High | Low | Low | Medium to high |
| Regulatory evidence | Moderate | Strong (ISO 26262, ASPICE) | Moderate | Strong at gates | Weak | Possible with discipline (IEC 62304, TIR45) | Strong at system level |
| Technical novelty | Low | Low to medium | Medium | High | Medium | Medium to high | Medium to high |
| Project size | Small to large | Medium to large | Medium to large | Large | Small to medium | Any, scaled with SAFe or LeSS | Medium to large |
| Business availability | Low needed | Low needed | Medium | Medium | Very high | High (product owner) | Medium to high |
| Contract fit | Fixed price | Fixed price, milestones | Fixed per increment | Phase-gated | T&M | T&M or capped budget | Fixed discovery plus T&M |
| Time to first value | Late | Late | Early | Medium | Very early | Early | Early to medium |
Five questions sharpen the choice:
- How confident are we that today’s requirements will be right at go-live? If the honest answer is “not very”, avoid a pure sequential model.
- What does it cost us to change something after release? If a release requires recertification or hardware changes, plan fewer, better-verified releases.
- Who needs evidence, and of what? Map regulatory and audit requirements to artefacts before choosing ceremonies.
- Can the business give us a decision-maker every week? If not, Agile will underperform, and a model with fewer, larger feedback points is safer.
- What contract will we sign? Choose the development model and commercial model together, never one after the other.
Apply the matrix to the insurer from the introduction. The claims rules are largely known, because they follow from policy terms and regulation — but how claims handlers will work in the new system, and the integrations with partners such as repair shops and loss adjusters, are uncertain. The cost of a late change is medium: the system is not certified like a medical device, but every rule change needs compliance sign-off. The regulator expects documented control over changes and testing. The business can assign a product owner, but only part-time. The contract needs a predictable budget, because the board approves it.
That profile does not point to a pure model. Pure Scrum on time and materials leaves the board without a budget range and compliance without a clear evidence trail. A fixed price with one go-live in eighteen months pushes all the risk about how claims handlers work to the very end. The third proposal comes closest: a short fixed-price discovery phase that delivers process models, an architecture and a budget range; then increments released one claim type at a time under a capped budget; and underneath, automated tests and requirements traceability on which compliance acceptance relies. One condition applies — discovery must take weeks, not three months, and end in a decision rather than another version of the specification.
How do you switch models mid-project without losing control?
Sometimes the model chosen at the start stops fitting. Requirements that looked stable start to move, a regulator asks for more evidence than planned, or a sequential project needs to show value before the next budget round. Switching is possible, but it has to be managed as a change in its own right.
Four steps keep control:
- Name the trigger. Record why the model no longer fits — volatility of requirements measured in change requests, a failed milestone, new regulatory demands. That record protects the decision in the steering committee and the contract.
- Re-baseline, do not relabel. Moving from Waterfall to Scrum without converting the specification into a prioritised backlog and replanning the budget simply renames the phases. Define what is fixed and what is variable from now on.
- Align the contract. A fixed-price contract rarely survives a switch to Agile unchanged. Agree an amendment — for example a capped budget for the remaining scope — before the first sprint, not after the first dispute.
- Protect the evidence trail. If the project is regulated, map how traceability and verification records will be produced under the new model. Losing that trail during a transition is one of the fastest ways to fail an audit.
The reverse move happens too. Agile projects that reach a stable core sometimes shift to a more planned, release-based rhythm for the final integration with hardware or third parties. That is not a failure of Agile. It is using the right model for the current risk.
Which model should you choose, and what are the key takeaways?
The choice of a software development model is a choice about risk: which risk you want to discover early, which you accept late and who pays for each. The key takeaways:
- Match the model to requirements stability and the cost of late change, not to fashion. Stable requirements and expensive changes favour sequential models; volatile requirements and cheap releases favour iterative ones.
- Royce warned against pure Waterfall in 1970. The sequential model works best with early prototypes and staged integration, as its author intended.
- The V-model is the reference in automotive, but medical device software under IEC 62304 can follow any documented life cycle, including Agile.
- Hybrids are the norm. Make them deliberate: a short discovery phase, real increments and automated evidence, not a long specification followed by a long test phase.
- Choose the development model and the contract together. Fixed price needs fixed scope; Agile needs a variable scope within a fixed team or budget.
At ARDURA Consulting we have been delivering software development projects for clients in Poland, Europe, the Middle East and the USA for more than ten years — under fixed-price, time-and-materials and hybrid contracts, in regulated and unregulated industries. We start each engagement by agreeing the model and the commercial terms together, because we have seen how often a mismatch between them, not the code, decides the outcome.
If you are choosing a development model for a new project or rescuing one where the model stopped fitting, talk to our team. We will help you assess the risk profile and propose a delivery and contract model that fits it.