Which Methodology for Which Project? — Notes from an 18-Year Developer

I once watched two project managers argue in the same meeting. One was insisting “we need to switch to Agile, this Waterfall is killing us.” The other was pushing back: “Agile will ruin us — our client wants a fixed price.”

They were both right. They weren’t speaking the same language because they were both asking the wrong question.

80% of software methodology debates are attempts to answer that wrong question: “Which one is better?” The right question is never that. The right question is: “Which one works for this project, this team, and this client?”

In this post, let’s frame the right question, answer it, and step out of methodology religion — the habit of treating the approach you advocate as part of your identity.

Asking the Right Question

A methodology lives at the intersection of three variables:

Project type — how clear are the requirements? What’s the cost of an early wrong decision?
Team size — 3 people, 30 people, or 300?
Client/stakeholder type — someone who can give continuous feedback, or someone who says “here’s what I want, deliver it in three months”?

Choosing a methodology without thinking about all three is like tailoring a suit without taking measurements. Then you say “this methodology doesn’t work” — but the methodology isn’t broken; it’s being misused.

Of these three variables, the third is the most commonly skipped and often the most decisive. You’ll see why in the next section.

The True Intent of Each Methodology

Everyone knows the definitions — I’ll skip those. Let’s look at the true intent behind each, because that’s where mistakes happen.

Waterfall Began with Royce’s Critique

Here’s something most people don’t know: Winston W. Royce’s original 1970 paper was written not to defend Waterfall, but to criticize it. When Royce described the model, he was essentially saying “if you do it this way, you will fail — it needs to be iterative.” In the years that followed, only the first diagram was lifted from the paper, the critique was forgotten, and “Royce’s Waterfall” was misrepresented for half a century.

This matters because nobody actually defends pure Waterfall. What gets defended is “planning discipline” — which is not anti-Agile.

True intent: When requirement uncertainty is close to zero, the return on planning is at its maximum. Defense, aerospace, financial regulation, a NASA satellite — in these projects nobody says “let’s revisit requirements at the end of the sprint.” What’s needed is known upfront; the cost of deviation is fatal.

Agile Was Designed for Small Teams

The Agile Manifesto was written in 2001 by 17 people, all advocates of small teams and close collaboration. The spirit of the Manifesto: “Let’s not assume we know more than we do right now — let’s learn in short cycles.”

Then Agile got sold to the enterprise. Enterprise scaling frameworks emerged — SAFe, LeSS, DAD — nearly the opposite of Agile’s original intent: layered, documentation-heavy, top-management-oriented structures. “Scaled Agile” is an oxymoron, like “scaled small-team discipline.”

True intent: When requirement uncertainty is high and the team is small, the return on iterative learning is at its maximum. Startup MVPs, SaaS products searching for product-market fit, projects where the client doesn’t fully know what they want.

Hybrid — The Name for the Real World

Pure Waterfall almost never happens, and pure Agile is rare too. In the real world, most projects run what’s called WaterScrumFall: Waterfall on top (contract, requirements document, fixed price), Scrum underneath (sprints, daily stand-ups, retros). The client sees Waterfall; the team lives Agile.

This is not bad — it just needs to be named honestly. Saying “we’re Agile” when you’re actually doing WaterScrumFall is self-deception.

True intent: When uncertainty and contractual requirements are mixed, hybrid is the only realistic option. There’s one condition: being honest about it.

Decision Matrix

Scenario	Recommended Approach	Why
A government tender, 50-page annual specification	Waterfall	Requirements are frozen, deviation is penalized
MVP for a new product, 3-person team, founder’s “let me test this” mindset	Agile (lean Scrum/Kanban)	Requirements will keep changing, small team
An agency, fixed-price client project, 6-month delivery	Hybrid (contract on top + sprints underneath)	The reality of both worlds
A 100+ person enterprise product team	Trunk-based + feature flag (technical) + Lightweight Agile (process)	Scaling problem
Mobile app, App Store release schedule	Release-train (Agile + Waterfall release planning)	Release schedule is fixed, but sprint content is flexible
A library / SDK, versioned distribution	Semantic versioning + Waterfall-style release	API stability is critical
A hackathon, 48 hours	None — no need, just build	Methodology overhead produces no value

Anti-pattern: Mixing all of them. A team that says “we have a develop branch, we do sprints, every feature ships through a release branch, and we have feature flags” is applying half of every discipline and getting the benefit of none. I go into more concrete detail on this in my Git workflow selection post.

Three Cases I Lived Through

Case 1: Agile Forced on a Fixed-Price Project

I was at an agency. The client’s contract said “these 28 features, by this date, at this price.” The project manager had just earned a SAFe certification and declared, “we’re going Agile.”

The first two sprints went fine. At the third sprint review, the client said “I’d like to see this too.” Our manager said “sure, let’s add it to the backlog.” A few sprints later the backlog had grown to 40 features. The contract still said 28, the budget was fixed, the timeline was fixed.

The outcome: either scope crept past the budget (the client refused to pay more), quality collapsed (racing to deliver everything created a bug pile), or the team burned out (evenings and weekends). All three happened.

Lesson: For Agile to work, scope needs to be negotiable. Fixed price + fixed scope + fixed timeline = violating Agile’s core premise. The right approach on this project was Hybrid — draw a Waterfall boundary with the contract, work with sprints internally. But the claim of “we’re doing Agile” prevented anyone from honestly accepting the hybrid reality.

Case 2: Attempting Waterfall at a Startup

An early-stage startup. The founder said “let’s put together a clear 6-month plan and then start.” First came requirements analysis (3 weeks), then design (2 weeks), then development began. In month 5, approaching launch, the founder said “actually I talked to some customers — what they really want isn’t X, it’s Y.” Five months of work had been done for a product that existed in the founder’s head, not for what real customers wanted.

Lesson: If requirement uncertainty lies on the customer’s side, Waterfall is impossible. Because Waterfall requires the assumption that “the right requirements are known upfront.” At a startup, that assumption is structurally wrong. No matter how well a founder knows their product, they don’t know what the user wants — they can only discover that through iterative learning.

Case 3: A Project Where Hybrid Actually Worked

A tender project: the client was a government agency that needed a contract, but we knew that half of the technical requirements were unclear.

Our proposal: the first 6 weeks would be discovery sprints — clarifying requirements, showing prototypes, refining together with the client. At the end of that period we defined the full scope and price, signed the contract, then moved into construction with Scrum.

We actually signed two contracts: the first was a T&M (time & materials) contract for “discovery,” the second was a fixed-scope contract for “build.” The client felt safe on both because they knew what they were paying for at each step.

Lesson: Hybrid isn’t indecision. Hybrid is the decision to manage a project’s known and unknown parts with separate disciplines. When set up correctly, you get the best of both worlds — but the prerequisite is not deciding by saying “we’re Agile/Waterfall” and leaving it at that; it’s honestly mapping out where the uncertainty lives.

No Methodology Is Applied in Pure Form

Let’s accept a reality: in 2026, 90% of companies that say “we run pure Scrum” are actually doing daily stand-ups + sprint planning, with scope changes driven by PO/PM decisions on the side.

“Pure Waterfall” doesn’t exist either. Even in the most heavily regulated financial institutions, there are small iterations happening throughout the development process.

Methodologies are collections of principles. Your job is to take each principle individually and apply the ones that fit your project. Saying “we don’t do pure Scrum because we have weekly syncs instead of daily stand-ups” is not a failure — it’s adaptation. Acknowledging and naming adaptation is not failure; claiming you haven’t adapted when you have is failure.

A senior developer’s job is not to apply a methodology — it’s to solve a problem. A methodology is a toolbox. You don’t become a carpenter based on what tools you happen to have in your box; you become a carpenter and then reach for what you need.

Closing: Methodology Is a Tool, Not an Identity

I see it often in junior developers: they say “I’m an Agile person,” declare “Waterfall is garbage,” and defend their methodology in arguments as if it were a team jersey. :)

I’m confident that 15 years from now, that same developer will be saying “Waterfall is a better fit for this project” or “Scrum won’t work with this team — let’s try Kanban.” Because by then, their focus will have shifted from defending a tool to solving a problem.

The question isn’t “which one is better.” The question is: for the project, team, and client in front of me, which of these three methodologies’ principles will be most useful? If you can answer that, it doesn’t matter what label you use. If you can’t, even your favorite methodology will lead you into a dead end.

Methodology is a method. You are the one who chooses the method. Anyone who claims otherwise is trying to sell you something.