Blog
Key takeaways:
Ask what is software development methodology and you will get a different answer from everybody in the room. Your development team says they work in two-week sprints. Somebody else calls it agile. A third person mentions Kanban, and the contract you are about to sign says "iterative methodology." None of these are the same thing, and at least one of them is being used incorrectly.
None of this is jargon for its own sake. The choice determines when you can change your mind, what you get to see and when, and who carries the risk if the estimate turns out wrong.
This guide defines the terms precisely, sets out what each of the main methodologies actually prescribes rather than how it markets itself, and gives you the questions worth asking a team about their process before you commit budget to it.
Put plainly, what is software development methodology comes down to this: a set of rules for how a team turns an idea into working, maintained software. It covers how requirements get discovered, how work is planned and sequenced, how feedback reaches the team, how change is handled, and how progress is measured.
The confusion in this subject comes almost entirely from three terms being used as synonyms when they sit at different levels.
The software development life cycle, or SDLC, is the set of phases a project passes through: conception, requirements, design, build, test, release, maintenance, retirement. Every project goes through them in some form, whatever process you use. There is a formal standard for it, ISO/IEC/IEEE 12207, which defines these life cycle processes independently of any particular way of working. ISO lists a 2026 edition as the current version, with the 2017 one marked withdrawn.
A methodology is a way of moving through that life cycle. It is a blueprint, not the phases themselves.
A framework is a specific, prescriptive methodology with named roles, events and artifacts. Scrum is a framework. So is XP.
Set out as levels rather than as a list, the three stop competing with each other.
The distinction matters practically, not just semantically. If someone tells you their software development life cycle methodology is waterfall, they have collapsed two levels into one, and you cannot tell whether they mean the project has phases (true of everything) or that scope is locked after sign-off (a real commitment with real consequences).
Waterfall is described everywhere as the old, discredited approach where each phase completes before the next begins. That description is accurate about how it gets practiced. It is wrong about where it came from, and the real story is more useful.
The model traces to "Managing the Development of Large Software Systems," a 1970 paper by Winston Royce presented at IEEE WESCON. Two things about Royce's original paper are consistently misreported.
First, the word "waterfall" does not appear in it. Not once. The term was applied later by other people to his diagrams.
Second, and more usefully, Royce did not recommend the pure sequential model. He drew it, and then wrote: "I believe in this concept, but the implementation described above is risky and invites failure."
The remainder of the paper sets out five additions he considered necessary to turn what he calls a risky development process into one that delivers. They include doing the design before the analysis, building it twice, involving the customer at defined checkpoints, and planning and monitoring the testing rather than leaving it to the end.
Put side by side, the paper and the practice have very little in common.
So the thing everybody rejects is a caricature of a model whose own author rejected it in the same document, having stripped out the corrections he insisted on. That is worth knowing when a vendor presents "we don't do waterfall" as a methodology.
Six approaches account for nearly everything you will encounter, from strict sequencing at one end to a lean software development methodology at the other. This table gives what each prescribes rather than how it is sold.
The honest summary is that almost nobody runs one of these purely. A typical arrangement is Scrum for planned feature work, Kanban for support, and a set of Lean or XP practices layered across both. That is not a failure to commit; it is what the tools are for.
This is the single most common error in the whole subject, including in articles that claim to explain it.
Agile is a statement of values. The Agile Manifesto, published in 2001, is 68 words long and sets out four preferences: 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. Twelve supporting principles follow it.
Read literally, it tells you almost nothing about what to do on a Tuesday. It says deliver working software frequently, "from a couple of weeks to a couple of months, with a preference to the shorter timescale." It says "welcome changing requirements, even late in development." It says "working software is the primary measure of progress." Those are commitments about direction, not instructions.
So when a team says they run an agile software development methodology, they have told you what they value and nothing about how they operate. The follow-up question is which framework, and after that, which parts of it they actually run.
An agile software development methodology in practice means Scrum, or Kanban, or XP, or a blend, and the differences between those are large enough to matter to you as a buyer.
Scrum is the most widely adopted framework, and scrum methodology software development is genuinely prescriptive in a way the others are not. The Scrum Guide, maintained by Ken Schwaber and Jeff Sutherland, defines exactly three accountabilities, five events and three artifacts. Anything else a company calls Scrum is that company's addition.
The three accountabilities are the Product Owner, who owns the ordering of the Product Backlog and is one person rather than a committee; the Scrum Master, accountable for the team's effectiveness; and the Developers, who own the Sprint Backlog and the Definition of Done.
The five events are the Sprint itself, a fixed-length container of one month or less, plus Sprint Planning (timeboxed to eight hours for a one-month sprint), the Daily Scrum (fifteen minutes, every working day), the Sprint Review (four hours), and the Sprint Retrospective (three hours).
The three artifacts are the Product Backlog, the Sprint Backlog and the Increment, which must meet the Definition of Done before it counts as complete.
Counted out, the framework is smaller than most implementations of it.
Companies bend those three accountabilities more than any other part of the framework, usually by making the Scrum Master a project manager or splitting the Product Owner across two people. A fuzzy role definition costs more than a wrong one, which holds well beyond how job roles are positioned on a development team.
Two implications are worth extracting for a buyer. The Product Owner has to be a real person with real authority, and if that is you, it is a genuine time commitment rather than a title. And scope inside a running sprint is meant to stay stable, so Scrum gives you frequent, predictable change points rather than continuous ones. Knowing which of those you actually want is most of the decision.
A kanban software development methodology comes at the same problem from the other direction. There are no iterations, no fixed roles and no ceremonies. There is a board that makes every piece of work visible, and a limit on how many items may sit in each column at once.
The work-in-progress limit is the whole mechanism. Capping the "in development" column at three forces the team to finish something before starting something else, which is how a Kanban board converts a wish into a queue discipline.
On the board it is a single number, and everything else follows from it.
Measurement changes accordingly. Instead of velocity and story points, a kanban software development methodology reports cycle time (how long one item takes from start to done) and throughput (how many items complete per week). Those numbers are harder to game and easier for a non-engineer to interpret.
The trade-off is rhythm. There is no sprint boundary, so there is no natural demo date and no built-in moment where everyone looks at the same thing. Teams doing support and maintenance rarely miss it. Teams building toward a launch usually do.
Two more names come up constantly, and neither is a full process in the way Scrum is.
Lean software development adapts manufacturing thinking. Its seven principles were set out by Mary and Tom Poppendieck in 2003: eliminate waste, amplify learning, decide as late as possible, deliver as fast as possible, empower the team, build integrity in, and optimize the whole.
In practice a lean software development methodology means deferring decisions until you have to make them and cutting anything that does not move the product forward, which is why it maps so naturally onto early-stage work.
Extreme Programming is an engineering discipline: pair programming, test-driven development where the test is written before the code, continuous integration, and small frequent releases. It layers onto Scrum or Kanban rather than replacing them. It also asks more of a team than most can sustain, and it needs a customer who is genuinely available, so it shows up more often as a set of borrowed practices than as a whole system.
Deferring a decision is not the same as avoiding it, and the distinction is where Lean gets misapplied. A team that defers everything has just relabeled indecision, which is the trap in overthinking a project into stasis.
That is the general pattern with software product development methodology choices. You pick a framework for cadence and a handful of practices for quality, and the combination is what you actually run.
The reflexive dismissal of sequential delivery is wrong often enough to be worth naming.
If the requirements genuinely are fixed and understood, and the cost of a mid-project change is enormous, sequencing is rational. Regulated medical devices, safety-critical embedded systems, and anything with a certification gate all fall here. So does most fixed-price contract work, for a structural reason nobody enjoys discussing: a fixed price requires fixed scope, and fixed scope is a waterfall commitment whatever the contract calls it.
The failure mode is applying it to a product nobody has built before, where the requirements are guesses and the guesses only improve once somebody sees working software. That is the situation the whole iterative tradition exists to address, and it is the one most digital products are actually in.
You can often settle which situation you are in before choosing anything, and cheaply. A week spent validating the idea against real buyers tells you whether your requirements are known or guessed, which is the input the whole choice turns on.
The choice comes down to two variables: how much you already know, and how much the team can absorb change without losing the plot.
Whichever row you land on, the first phase is where the methodology gets decided in practice rather than in the contract, which is why we treat discovery and prototyping as the point where scope stops being a guess.
One factor outranks all of these, and experienced engineers say so consistently. In an r/ExperiencedDevs thread on the best and worst methodologies, the top answer argued that a solid team can succeed with any approach, that Scrum's overhead is excessive for most teams, but that its structure genuinely helps a junior one.
That is one practitioner's view rather than research. It matches what most people find, though: process substitutes for experience, and a team that has experience needs less of it.
There is a gap between Scrum as written and Scrum as practiced, and pretending otherwise leaves you unprepared for it.
Asked why so many developers are hostile to Scrum, the most-upvoted reply in an r/programming discussion listed what tends to get dropped in real implementations: self-organization, because the framework is imposed from above rather than adopted; user-focused stories, because managers write them from their own perspective; and the flattening of hierarchy that the framework assumes. What is left is the ceremony without the mechanism that made the ceremony worth attending.
Treat that as a signal about what to inspect rather than as a verdict on Scrum. If a team runs the events but the Product Owner cannot actually decide priority, or the retrospective never changes anything, the label is doing no work.
The useful version of this is simple. Ask what the last retrospective changed. A team with a real process can answer immediately.
The same test applies outward. A cadence that produces a demo every two weeks is only worth its overhead if somebody outside the team responds to it, which is why a structured route for gathering user feedback belongs in the process rather than beside it.
Whether you are hiring an agency or assessing your own team, these questions surface how a process really runs. Vague answers here are the finding.
Question two matters most, because it is the one the answer to a contract cannot fake. A team that can absorb a change of direction has structured its work so that nothing is built too far ahead of being validated.
The other decision this shapes is whether you are staffing up or buying delivery, which is a genuinely different question from process, and it is worth being honest with yourself about building a technical team before you pick either.
Every methodology worth using is trying to solve one problem: the gap between deciding something and finding out whether you were right. Waterfall closes that gap once, at the end. Scrum closes it every sprint. Kanban closes it per item. Lean tries to defer the decision until the gap is smallest.
That framing is more useful than the labels, because it tells you what to watch. If your process produces a demo every two weeks that nobody outside the team looks at, the loop is not closed and the cadence is theater.
On one timeline the three cadences stop being a matter of taste.
The clearest example we have seen of this was building the Nimbus platform for iCopy, a medical records retrieval business. A clickable prototype came first and did double duty: it was the foundation the build worked from, and it was the asset the client used to sell the thing before it existed.
Feedback therefore arrived from real buyers while changing direction was still cheap. The platform went on to lift the client's volume by 300% and its revenue tenfold within two years of launch.
That sequencing is a process choice rather than a design flourish. The prototype is not a deliverable. It is the shortest available route to being told you are wrong.
So the practical takeaway is short. Sequence the work when the requirements are genuinely settled and the cost of change is high. Iterate when they are not, which is most of the time. Use Kanban for the stream of work that arrives whether you planned it or not.
So the honest answer to what is software development methodology is that it matters less than the loop it creates. Stop optimizing the framework and start checking that loop. Ask what the team learned last month, from whom, and what changed as a result. A team that can answer that is running a real process regardless of what it is called, and one that cannot is running a calendar.
Stripped of jargon, it is the agreed set of rules a team uses to turn an idea into working software. That covers how requirements get gathered, how the work is broken up and sequenced, how often you see something, and what happens when you want to change direction.
Scrum, Kanban and Waterfall are the common ones. The rules matter to you as a buyer mainly because they decide when you can change your mind and what it costs.
The software development life cycle methodology confusion is the most frequent error in this area. The SDLC is the set of phases any project moves through, from conception to maintenance, and it is formalized in ISO/IEC/IEEE 12207. A methodology is how a team moves through those phases. Every project has a life cycle; the methodology is the part you choose.
Neither is better in general, which is why the question keeps producing unsatisfying answers. Agile approaches suit work where requirements will change as you learn, and most digital products are in that position. Sequential delivery suits fixed, well-understood scope, particularly under regulation or a fixed-price contract. The failure is applying either one where the other belongs.
A scrum methodology software development team works in fixed sprints of a month or less, with three defined accountabilities, five events and three artifacts, and holds scope steady inside each sprint. Kanban runs as continuous flow with no iterations, limits how much work is in progress at once, and lets new work enter at any point. Scrum gives you predictable change points; Kanban gives you responsiveness. Teams doing both planned and reactive work commonly run both.
No, and most teams do not. The usual arrangement is one framework for planned product work, Kanban for support and maintenance, and a handful of engineering practices such as test-driven development or continuous integration layered across everything. What matters is that the team can explain which approach applies to which work and why, rather than describing a blend that turns out to mean no process at all.
If you are choosing between development teams, their process is worth more scrutiny than their tech stack, because it determines what happens on the day something changes. The seven questions above are a good start, and we are happy to help you read the answers.
Contact us if you want a second opinion on a proposal in front of you.
