Ask a room of engineers "what's the best software development methodology" and you'll get an argument, not an answer — because the honest answer is "it depends," and most of the disagreement is really about which project each person is picturing. This guide covers the methodologies that actually get used in production, what each one is genuinely good at, where each one breaks down, and how to pick one without the debate.
Why the Methodology You Choose Actually Matters
It's tempting to treat methodology as a formality — something written in a proposal document and then quietly ignored once real work starts. That's a mistake. The methodology shapes concrete, everyday decisions: how often stakeholders see working software, how a mid-project change in requirements gets absorbed (or doesn't), how a team measures whether it's actually on track, and how much rework happens when something was misunderstood early on. Get the methodology wrong for the project's actual shape, and you pay for it in missed expectations, not just in slower delivery.
Methodology vs. Framework vs. SDLC
These three terms get used interchangeably, which causes real confusion. A methodology is a philosophy — Agile is a set of values and principles, not a specific process. A framework is a concrete implementation of that philosophy — Scrum and Kanban are both frameworks for putting Agile into practice, and they work quite differently. An SDLC (Software Development Life Cycle) model describes the stages every project moves through — requirements, design, build, test, deploy, maintain — regardless of which methodology governs how those stages are organized.
Why this distinction matters
Teams often say "we do Agile" when they mean "we do Scrum" — and then get frustrated when Scrum's fixed sprints don't fit a support-and-maintenance workload that Kanban would handle better. Naming the right layer helps you pick the right tool.
The Main Software Development Methodologies
At a glance, here's how the methodologies covered below compare on flexibility, planning style and typical fit.
Software development methodologies at a glance
| Methodology | Structure | Best For |
|---|---|---|
| Waterfall | Sequential, one phase completes before the next starts | Fixed-scope projects with well-understood, stable requirements |
| Agile (umbrella) | Iterative, requirements evolve across short cycles | Products where requirements are expected to change based on feedback |
| Scrum | Iterative, fixed-length sprints with defined roles and ceremonies | Teams that benefit from a structured cadence and clear accountability |
| Kanban | Continuous flow, visualized on a board, no fixed iterations | Support, maintenance, and work with unpredictable, ongoing demand |
| Lean | Iterative, focused on eliminating waste and validating value early | Startups and teams validating a product direction before scaling |
| DevOps | Continuous integration/delivery, dev and ops merged into one flow | Products needing frequent, reliable releases and fast feedback loops |
| Extreme Programming (XP) | Iterative, with strict engineering practices (pair programming, TDD) | High-quality, technically complex products where defects are costly |
| Spiral Model | Iterative, with a dedicated risk-analysis phase repeated each cycle | Large, high-risk projects where identifying risk early matters most |
| V-Model | Sequential, each development phase paired with a corresponding test phase | Safety-critical or heavily regulated systems needing rigorous verification |
| Rapid Application Development (RAD) | Iterative prototyping with heavy user feedback | Projects needing a working prototype fast, with a flexible scope |
| Feature-Driven Development (FDD) | Iterative, organized around building and delivering one feature at a time | Larger teams needing a disciplined, feature-level tracking model |
Waterfall
Requirements, design, build, test and deployment happen in strict sequence — each phase finishes before the next begins. It's predictable and easy to plan a budget and timeline around, which is exactly why it still shows up in regulated industries and fixed-contract government work. The tradeoff: if requirements change midway through, going back a phase is expensive and slow. Avoid it when you don't yet know exactly what you're building.
Where it genuinely still wins: projects with a fixed, externally-imposed scope (a government contract, a compliance-driven system replacement) where the cost of a late requirements change is so high that locking scope upfront is actually the safer choice, even at the price of flexibility.
Agile
Agile isn't a single process — it's a set of values (working software over documentation, responding to change over following a plan) that specific frameworks like Scrum and Kanban put into practice. Work happens in short iterations, with regular feedback shaping what gets built next. It fits almost any product where requirements will evolve, which in practice is most software products.
The values behind Agile, from the original Agile Manifesto, are worth stating plainly because they get diluted in practice: individuals and interactions over rigid processes, working software over comprehensive documentation, customer collaboration over fixed contract negotiation, and responding to change over rigidly following a plan. None of those say "no documentation" or "no planning" — they say prioritize the thing that actually matters when the two are in tension.
Scrum
The most widely adopted Agile framework. Work is organized into fixed-length sprints (commonly two weeks), with defined roles (product owner, scrum master, development team) and ceremonies (sprint planning, daily standup, review, retrospective). The structure gives teams a predictable rhythm and clear accountability — useful for teams that need that discipline, less useful for work that doesn't fit neatly into fixed iterations.
The product owner role deserves particular attention, because it's the role most often done poorly. A product owner who isn't empowered to make real prioritization decisions — who has to check every call with someone else — turns sprint planning into a bottleneck rather than the fast, decisive process it's meant to be. Scrum's structure only delivers its benefits when that role actually has authority.
Kanban
Work is visualized on a board (to do, in progress, done) with a limit on how much can be "in progress" at once, and there's no fixed iteration length — items move through continuously as capacity allows. It's a strong fit for support and maintenance work, or any team whose incoming work is unpredictable and doesn't sort neatly into two-week chunks.
The work-in-progress (WIP) limit is the part teams most often skip, and it's the part that actually makes Kanban work. Without a real cap on how many items can be "in progress" simultaneously, a Kanban board just becomes a visual to-do list with no enforced focus — the WIP limit is what forces a team to finish work before starting new work, which is the whole point of the flow-based approach.
Lean Software Development
Adapted from Lean manufacturing principles, this methodology focuses on eliminating waste — unnecessary process, unused features, delayed decisions — and validating what actually delivers value before investing further. It pairs naturally with an MVP-first approach, which is why it's common among startups testing product-market fit before committing to a full build.
Lean's seven classic waste categories, adapted to software, are worth knowing because they're a genuinely useful audit checklist: partially done work, extra process, extra features nobody asked for, task switching, waiting/delays, unnecessary motion (handoffs between people or teams), and defects. A team that periodically reviews its own workflow against this list tends to find real, concrete places to cut waste — not just abstract efficiency talk.
DevOps
DevOps merges development and operations into one continuous flow, with automated testing, integration and deployment (CI/CD) reducing the gap between writing code and shipping it safely. It's less a project-management methodology and more an engineering culture — one that pairs well with any of the above, since it's about how code ships, not how work is planned.
In practice, DevOps maturity is often measured less by tooling and more by two questions: how long does it take from a code change being merged to it running safely in production, and how quickly can the team detect and roll back a bad change if something goes wrong. A team with excellent CI/CD tooling but no real incident-response discipline hasn't actually adopted DevOps — it's adopted DevOps tooling, which is a different, smaller thing.
Extreme Programming (XP)
An Agile framework with strict engineering discipline built in — pair programming, test-driven development, continuous integration, and frequent small releases. It's demanding to run well, but for technically complex products where defects are expensive to fix after release, that discipline pays for itself.
Spiral Model
The Spiral Model combines iterative development with a dedicated risk-analysis phase repeated at every cycle — each pass through the spiral involves planning, risk analysis, engineering, and evaluation before moving to the next iteration. It suits large, high-stakes projects where identifying and addressing risk early is worth the additional process overhead, but it's genuinely heavier to run than most Agile frameworks and is overkill for a straightforward product build.
V-Model (Verification and Validation Model)
An extension of Waterfall where every development phase has a directly corresponding testing phase planned alongside it — requirements pair with acceptance testing, design pairs with system testing, and so on — forming a "V" shape when drawn out. This gives rigorous, built-in verification, which is why it shows up in safety-critical and heavily regulated systems (medical devices, aerospace, some financial infrastructure) where the cost of an undetected defect is severe. Like Waterfall, it assumes requirements are stable and known upfront.
Rapid Application Development (RAD)
RAD prioritizes building a working prototype fast and iterating based on direct user feedback, rather than locking down detailed requirements upfront. It works well when you need something tangible to react to quickly, and less well when the product has strict technical constraints that need to be solved before a prototype makes sense.
Feature-Driven Development (FDD)
FDD organizes work around building and delivering one client-valued feature at a time, with a short, repeatable design-and-build cycle per feature. It gives larger teams a disciplined way to track granular progress at the feature level rather than at the sprint or task level, which some organizations find easier to report on to non-technical stakeholders than a Scrum burndown chart. It works best when the product can genuinely be decomposed into discrete, independently valuable features.
Agile vs. Waterfall: The Real Comparison
This is the comparison most teams actually need, because it's really a question about how well-defined your requirements are today.
Agile vs. Waterfall
| Agile | Waterfall | |
|---|---|---|
| Requirements | Expected to evolve across the project | Defined upfront and expected to stay fixed |
| Delivery | Working software in short, regular increments | One delivery at the end of the full process |
| Change tolerance | High — built into the process | Low — changes typically mean re-planning |
| Client involvement | Continuous, throughout the project | Concentrated at the start (requirements) and end (delivery) |
| Best fit | Products evolving based on user feedback | Fixed-scope, contractually defined projects |
How Team Size and Distribution Change the Calculus
Methodology guides often talk about frameworks in the abstract, as if a five-person team and a fifty-person team should approach the choice the same way. They shouldn't. Scrum's daily standup and tight sprint cadence work well for a small, co-located or well-overlapping-hours team; stretch that same structure across twenty people in three time zones and the ceremonies themselves start eating a disproportionate share of the day. Larger or more distributed teams often need either a scaled framework (multiple Scrum teams coordinated through a shared backlog and regular sync points) or a shift toward Kanban's more asynchronous, flow-based model, which tolerates time-zone spread better than a framework built around daily synchronous meetings.
How to Choose the Right Methodology
- How stable are your requirements? Fixed and well-understood leans Waterfall or V-Model; expected to evolve leans Agile.
- How involved can your team or stakeholders be? Agile depends on regular feedback — if that's not realistic, a more sequential approach may fit better.
- What's the cost of a late change, or an undetected defect? High-stakes, hard-to-reverse work (compliance, safety-critical systems, hardware-tied software) tolerates Waterfall or V-Model's rigidity better than most products do.
- Is the work project-based or ongoing? Scrum suits a defined project with a start and end; Kanban suits continuous support and maintenance.
- How large and how distributed is the team? A framework built around daily synchronous ceremonies strains as team size and time-zone spread grow.
- How much engineering discipline can the team sustain? XP's practices only pay off if the team can actually maintain them consistently.
Common Mistakes Teams Make
- Running Scrum ceremonies (standups, sprints) without the underlying prioritization discipline — the meetings happen, but the backlog isn't actually managed.
- Choosing Agile because it sounds modern, for a project with genuinely fixed, contractually locked requirements where Waterfall would cause less friction.
- Treating Kanban as "no process" — a board with no WIP limits and no one reviewing flow isn't Kanban, it's just a to-do list.
- Adopting DevOps tooling (CI/CD pipelines) without the cultural shift — automation doesn't fix a team that still treats deployment as a rare, risky event.
- Scaling a small-team methodology to a large, distributed team without adjusting its ceremonies — the framework that worked at five people doesn't automatically work at twenty-five.
How Apptechies Approaches Methodology
We default to Agile for the reason most teams do — most products benefit from evolving based on real feedback rather than a fixed plan set in stone before any code is written. Agile Development is one of the seven phases in our standard delivery framework, sitting between architecture/planning and quality assurance, with iterative sprints producing a working, testable increment at the end of each cycle.
That said, we don't force every engagement into the same shape. A custom software build with evolving requirements runs differently from a dedicated development team embedded in an existing process, or an IT consulting engagement scoping a fixed-requirement system. The methodology serves the project — not the other way around.
