The Great Methodology Debate

Fellow Business Analysts,

Welcome to this series. Over the next six editions, we are going somewhere that most BA training programmes, certification courses, and online resources simply do not go: a genuinely honest, balanced, and practical examination of the two most debated delivery methodologies in our field: Waterfall and Agile.

Not as a competition. Not as a loyalty test. As a professional toolkit examination.

Why the Waterfall vs Agile Debate Matters More Than You Think

I want to start with something that rarely gets said plainly in BA circles: how you answer the Waterfall vs Agile question reveals the quality of your analytical thinking far more than which answer you give.

If your answer is a declaration of preference, 'I prefer Agile' or 'I'm more of a Waterfall person', what you are actually communicating is that you have a comfort zone and you default to it. That is human and understandable. But it is not what senior stakeholders, programme directors, or hiring managers at a senior BA level are looking for.

What they are looking for is someone who can assess the characteristics of a project, its regulatory environment, its stakeholder landscape, the stability of its requirements, its team culture, and its commercial constraints and make a reasoned recommendation on how to structure delivery. That is a different skill entirely. And it starts with genuinely understanding both methodologies, not just the one you have been living in for the past few years.

Where Both Methodologies Come From

To understand any framework well, you need to understand the problem it was designed to solve. Both Waterfall and Agile were responses to real frustrations in project delivery, but they were responses to different frustrations, in different eras and contexts.

The Origins of Waterfall

Waterfall as a formal project methodology was first described in the early 1970s, most notably in work by Winston Royce, though it is worth noting that Royce himself considered the purely sequential model flawed and advocated for feedback loops that most Waterfall implementations never incorporated.

The methodology drew heavily from manufacturing, construction, and civil engineering disciplines, where sequential phase completion was not just preferable but necessary. You cannot install the plumbing before the walls are built. You cannot pour the foundation after the building is occupied. The logic was that software, being a complex engineered artefact, should be governed by the same disciplined sequencing.

For a period, this worked reasonably well, particularly in defence, government, and large-scale enterprise systems where requirements were known, technology was stable, and projects had years rather than months to deliver. The paper trail, the formal sign-off culture, and the phase-gate governance that Waterfall demanded were not bureaucratic inconveniences. They were the product.

The Origins of Agile

By the late 1990s, a growing frustration had taken hold in the software development community. Projects managed with traditional methods were frequently late, over budget, and delivered systems that users did not actually want, discovered only after months or years of development had concluded.

In February 2001, seventeen practitioners gathered at a ski lodge in Utah and produced what became the Agile Manifesto. Four values, twelve principles, and a set of ideas that would reshape how software was built globally over the next two decades.

It is worth reading the manifesto's values carefully, because they are frequently misrepresented:

•        Individuals and interactions over processes and tools

•        Working software over comprehensive documentation

•        Customer collaboration over contract negotiation

•        Responding to change over following a plan

Note the phrasing: 'over', not 'instead of'. The manifesto explicitly acknowledged the value of what sits on the right side of each statement. This nuance is critical, and it is precisely the nuance that gets lost when practitioners use 'we're Agile' as a reason to skip documentation, avoid stakeholder alignment, or refuse to plan ahead.

The Five Myths That Keep BAs Stuck

Before we go deeper into each methodology this week, I want to address five myths that shape how most practitioners think about this debate, because if you are carrying any of these, they will limit how useful this week's content can be for you.

Myth 1: Agile is newer, therefore better

Agile was codified in 2001. Waterfall was formalised in the 1970s. Neither of these facts tells you anything about which is superior for a given project. 'Newer' is not a proxy for 'better' in methodology any more than it is in medicine, law, or engineering. Recency bias is not an analysis.

Myth 2: Waterfall means no flexibility

Well-designed Waterfall projects include formal change management processes. The issue is not that change is impossible in Waterfall; it is that change is costly and requires rigorous management. That is not a flaw; in regulated environments, it is a governance feature.

Myth 3: Agile means no documentation

This is perhaps the most damaging myth in the BA profession. Agile does not eliminate the need for documentation; it changes its form and timing. User stories, acceptance criteria, definition of done, sprint goals, and backlog items are all documentation. Lightweight, yes. Absent, no.

Myth 4: The BA role disappears in Agile

The BA role does not disappear in Agile. It transforms. The upfront, document-heavy phase of traditional BA work shifts into a continuous, sprint-embedded practice of story refinement, stakeholder liaison, and real-time requirements clarification. Many BAs find this more demanding, not less.

Myth 5: Organisations must choose one or the other

The majority of experienced delivery practitioners quietly operate in a blend of both methodologies using Waterfall-style rigour for the planning and architecture phases, and Agile practices for delivery. We will explore this in depth on Day 5. The binary choice is largely a false one.

What This Week Will Build For You

By the end of Day 6, you will have a clear, confident, and genuinely sophisticated answer to the Waterfall vs Agile question. One that holds up in interviews, in project kickoffs, and in stakeholder conversations at every level of an organisation.

You will also have a practical decision framework for your next project, a deep understanding of the hybrid model, and six model interview answers you can adapt to your own experience.

That is what this week is for. Let's get into it. Also, if you want to know more about Business Analysis, click the link here for a free 30-minute session: Click Here

Go out and be successful.

— Oluwatosin Ogunkoya

Monday: Waterfall Demystified - the phases, the deliverables, and the scenarios where choosing Waterfall is not old-fashioned. It is the right call.