Software development methodologies compared by what each one needs to work

Which software development methodologies will actually work on your project?#

A software development methodology works only when the conditions its own text assumes are true of your project, and only 83 of 556 HELENA survey participants ran every discipline one way. That survey ran in 2017. So the useful question is not which method is best. Instead, it is which method's conditions your project already holds.

Each method writes those conditions down. For example, the Scrum Guide, last revised in November 2020, asks for one Product Owner and Sprints of one month or less. Then the Kanban Guide, revised in May 2025, asks for a defined workflow and a limit on work started but not finished. Also, Royce's 1970 paper, as Saravanos of New York University read it in December 2025, asks for a first design pass that rehearses the final product.

Most lists of software development methodologies skip this step. Instead, they give each method a definition, a list of pros and cons and a "best for" line. However, a pros list cannot tell you why the same method works for one team and fails for the next. The preconditions can, because they describe your project rather than the method.

What does each methodology assume before it can work?#

Each method states its own preconditions: Waterfall assumes requirements you can fix early, Scrum assumes one empowered Product Owner, and Kanban assumes a visible workflow with controlled work in progress. In short, the four differ less in their meetings than in what they assume is already true.

Source: the Agile Manifesto principles, the Scrum Guide (November 2020), the Kanban Guide (May 2025) and Saravanos, "A History of the Waterfall Model" (arXiv, December 2025).

The texts are blunt about it. The Agile Manifesto principles say "Welcome changing requirements, even late in development". They also say "Business people and developers must work together daily throughout the project." The Scrum Guide says "The Product Owner is one person, not a committee." Meanwhile, the Kanban Guide opens with "Kanban is a strategy for optimizing the flow of value through a process."

Finally, the international standard sits above the choice rather than making it. ISO/IEC/IEEE 12207, published by ISO in 2017, provides processes for "defining, controlling, and improving software life cycle processes" in a project. Because it names processes and not a method, a team can run it under any of the four.

What did Royce's 1970 paper actually ask of Waterfall?#

Royce's 1970 paper, as its historians read it, asked teams to do the design twice, with a first pass that provides an early simulation of the final product. However, that is not the one-pass Waterfall most lists describe.

Saravanos, writing in a history of the Waterfall model posted in December 2025, makes three points. First, Royce recommended running the cycle at least twice. Second, the first pass "provides an early simulation of the final product". Third, the word "waterfall" never appears in the 1970 paper; Bell and Thayer popularised it in 1976.

So Waterfall's real precondition has two parts. The requirements must be fixable early, and the project must afford a rehearsal before the real build. As a result, a team that skips the rehearsal is running the version Royce warned against.

Saravanos also notes that the model was codified in project standards "particularly in regulated industries such as defense, aerospace, and healthcare." That explains why it persists, because when a regulator fixes the requirements and audits each phase, the first condition holds by law. For example, an interface whose fields are set by a filing rule has requirements that will not move next month.

In practice, the useful reading is narrow. Waterfall fits the part of a project whose requirements are fixed from outside, and it fits that part best with Royce's rehearsal pass kept in.

What does Scrum need that many projects cannot supply?#

Scrum needs one person with the authority to order the Product Backlog and Sprints of one month or less, and a sponsor available one afternoon a week cannot be that person. Then the rest of Scrum depends on that one role.

The Scrum Guide is specific. It says "The Product Owner is one person, not a committee." It also makes that person accountable for ordering Product Backlog items, the list of work the team pulls from. It calls Sprints "fixed length events of one month or less to create consistency." In short, every Sprint starts with a decision about what matters most, and one person makes it.

Here is how it fails quietly. When priorities sit with a steering group, each Sprint plans against an order no single person owns. The team still holds every meeting. But the work drifts, because the person who could say "this one first" is never in the room.

The Agile Manifesto principles set the same bar from the business side: "Business people and developers must work together daily throughout the project." In particular, daily is the word that matters. A sponsor who joins once a week can approve work, but cannot order it as fast as the team needs.

Therefore, the Scrum test is one question. Is there a single person, available most days, who can reorder the backlog without asking anyone? If the answer is no, Scrum's ceremonies will run while its core condition is missing.

1. One person, not a committee.

   The Scrum Guide says "The Product Owner is one person, not a committee."

2. Available most days.

   A sponsor who joins once a week can approve work, but cannot order it as fast as the team needs.

3. Can reorder the backlog without asking anyone.

   If the answer is no, Scrum's ceremonies will run while its core condition is missing.

When does Kanban fit better than Scrum?#

Kanban fits better when work arrives as a steady stream of unrelated items, because it asks only for a defined workflow and a limit on work started but not finished. However, it does not ask for a shared goal per timebox.

The Kanban Guide, revised in May 2025, calls the shared map of the work a Definition of Workflow. It says "DoW is a fundamental concept of Kanban." It defines WIP as "The number of work items started but not finished." Then it tracks three more measures: throughput, the age of each open item, and cycle time from start to finish.

That makes the comparison with Scrum concrete. First, Scrum suits work that can be grouped into a goal for the next few weeks. Second, Kanban suits work that arrives in small, unrelated pieces, such as support fixes or change requests, where a two-week goal would be invented.

The cost sits in the limit. Kanban's condition is a WIP limit the team will actually honour, which means saying "not yet" to new work while old work is open. Instead of a Sprint boundary, the limit is what forces items to finish. Without one, a board is a to-do list, and it inherits none of the guide's promises.

So the question is about arrival. If your work comes as a stream and your team will keep a WIP limit, Kanban's conditions hold. But if it comes as features that only make sense together, Scrum's timebox fits better.

Where do teams get stuck with each methodology?#

Practitioners asked 2,981 tagged questions about Scrum and 191 about waterfall across Stack Overflow and two Stack Exchange sites, and the Scrum questions cluster on team roles and story estimation. Those counts come from Khan et al., whose study was posted to arXiv in May 2023 using data to 6 July 2022.

The volume follows use, so the topics in the 2023 study matter more than the totals. Of the 13,903 posts Khan et al. analysed, 17.71% dealt with team roles and responsibilities in Scrum. Another 21.32% dealt with story estimation in Scrum Sprints. For instance, one post the study quotes is about the Product Owner role itself.

In other words, people rarely ask how to run a Daily Scrum. They ask who decides, and how much fits in a Sprint. Both are precondition questions. First, one is about a Product Owner who is missing or shared. Second, the other is about requirements that are not yet stable enough to size.

A tag count is not a failure rate, and the study does not claim one. Even so, it shows where practitioners go looking for help, and that is where a method's assumptions meet a real team.

Do teams really run one methodology, or a mix?#

Most teams run a mix: in the HELENA survey, 473 of 556 participants used different degrees of agility across project disciplines, and only 83 ran every discipline the same way. A declared hybrid is the normal result, not a failure to choose, at least in the 2017 data.

Kuhrmann et al., in a 2021 paper for IEEE Transactions on Software Engineering, asked each participant how agile they were in each discipline, such as requirements, design and testing. Only those 83 gave every discipline the same answer. The authors conclude that the "pure doctrine" accounts for a small share only. They also report that approximately 75% of participants use hybrid methods, a separate measure from the per-discipline count.

As a result, this changes how to read your own choice. A team that runs requirements in a plan-driven way and coding in Sprints is not confused. Instead, it has tested two disciplines and found different conditions in each. Therefore, the mistake is only in leaving the mix unspoken, so that the team cannot tell which rules apply to which work.

Because of that, a declared hybrid should say which method governs which discipline, and why. A single sentence is enough, such as "fixed interface specs, Kanban for change requests".

Which methodology combinations do teams actually use?#

Scrum was the most selected method in HELENA, chosen by 674 participants, and 380 participants paired it with Waterfall in the pattern called Water-Scrum-Fall. In that 2019 analysis, the common mixes pair a plan-driven frame with Scrum or Kanban inside it.

The counts come from Tell et al., published at ICSSP 2019, from survey data gathered between May and November 2017. Of the 845 data points that answered the method question, 792 had multiple selections. Then Iterative Development followed Scrum with 620, and Kanban came third with 523. Also, 309 participants use Scrum, Kanban and DevOps in combination.

Water-Scrum-Fall is the pattern worth naming. A plan-driven phase fixes scope, budget and the release gate. Then Sprints deliver the work inside that frame. It is common because it matches two different sets of conditions. For example, the contract or the regulator wants fixed commitments, while the build team needs room to learn.

The survey is from 2017, so treat the exact counts as a snapshot. Still, the shape matters more than the year: a single pure method was the exception even then.

How does the precondition test work on a real project?#

Take an example: a six-person team rebuilding an insurer's claims portal, with a go-live date set by a regulator and a sponsor free one afternoon a week. This is a modelled example, chosen because each of its conditions is common.

Run the project through the table, one row at a time.

1. Waterfall. The interface the regulator inspects has fields set by a filing rule. Because those requirements will not move, a plan-driven phase with Royce's rehearsal pass fits that interface.
2. Scrum. The sponsor can give one afternoon a week and keeps the sole right to reorder priorities. As a result, the Scrum Guide's single Product Owner is missing, so Scrum is not yet an option.
3. Kanban. Change requests arrive from the old system as a steady stream of small, unrelated items. Because the team can agree a workflow and a WIP limit, Kanban's conditions hold for that stream.

So the claims portal gets a declared hybrid. Kanban runs the change requests. Meanwhile, a rehearsal pass covers the regulated interface. Then Scrum waits until the business names a real Product Owner. After that, the test can be run again, because conditions change during a project.

This answer matches the survey shape above. It is also the answer a pros-and-cons list would never reach, because the list never asks about the sponsor's calendar.

When is a precondition test the wrong tool?#

A precondition test is the wrong tool when nobody can yet answer its questions, because then the first job is discovery, not a methodology. Three cases are common.

First, a new product with no settled scope cannot say whether requirements are fixable. Here the better tool is a short discovery phase, or a small first release built to learn, such as an MVP. Second, a contract or regulator may mandate a method outright. In that case the test cannot override it, and its job shrinks to choosing how work runs inside the mandate. Saravanos notes that plan-driven standards persist in regulated industries for exactly this reason.

Third, the evidence above has limits. HELENA was an online questionnaire, so its counts are what participants reported about their own projects. Also, its participants came through a convenience sample gathered between May and November 2017. Meanwhile, the Stack Exchange counts show where people asked questions, not where projects failed. In practice, treat both as a shape, and treat your own team's answers as the stronger evidence.

Where should you go from here?#

Once you know which preconditions your project holds, the next questions are how to structure daily delivery and how long the build will realistically take. In short, the test points to process, timeline and, when answers are missing, discovery.

For the daily side, how structured project processes hold roles in place covers execution once a method is chosen. The delivery challenges that follow a poor fit describes what goes wrong when scope and communication slip. For the calendar, managing project timelines turns a chosen cadence into dates, and a custom software development timeline shows how decision speed shapes a build.

When the questions in the table had no clear answers, product discovery is the step that produces them. If they did, custom software development describes building under whichever mix the answers support. Finally, the primary texts behind these software development methodologies are short, and reading the Scrum Guide and the Kanban Guide with your own project in mind is enough to run this test.