Agile or Waterfall (Sequential) – which is better?

As an agile practitioner, trainer, coach, and consultant, you might expect me to say, “Agile is the only way to succeed—pay me a lot of money and I’ll show you why!”

But here’s the truth (spoiler alert): I can only answer this question with “it depends.” That might sound vague, but it’s often the most honest and valuable response.

In the end, only you can decide what’s best for your project and organisation, based on the drivers and constraints you understand better than I do. I hope this article helps you figure it out for yourself.

Let’s begin by looking at the core ideas behind each approach.

Waterfall project management follows a sequential, predictive approach. The scope is usually fixed, and the solution is often fully specified before development. Delivery may happen as a single 'big bang' or in phases, where each phase delivers a significant part of the overall solution.

A typical waterfall method involves these steps:

1. Analysis: Identify, document, agree on, and approve the requirements and any quality standards. In IT, this includes non-functional requirements.
2. Design: Create and approve a detailed design that meets the agreed requirements and quality criteria.
3. Build: Construct the solution according to the design, ensuring it meets all specified requirements and quality standards.
4. Test: Thoroughly test the solution to confirm it meets the agreed requirements, design, and other quality criteria.
5. Deploy: Put the solution into use to deliver its intended business value.

Each step must be planned and resourced, with all activities clearly identified, estimated, and assigned. In many cases activities will be broken into detailed tasks and captured in the form of a GANTT chart. For a phased project, high-level analysis and design should happen first to set the context and scope for each phase.

The waterfall approach requires a predictive style of project management in which each step produces documentation that outlines what the next step needs to do.

All the work for each step is planned based on the expectation (itself a prediction) that the outcome will match what was agreed. Properly approved documentation is the main way to communicate the project’s intent to everyone involved or affected.

Project control relies on showing that the delivered work matches the documentation from the previous step, as well as following the approved plan for the current step. Any changes should go through a formal process in which the documentation is revised and approved. Ideally, the documentation is reviewed regularly to make sure it still meets evolving business needs.

Changes can be identified from the work in the later steps in the waterfall process. For example with issues being discovered during the Test step that identify a mismatch between specified requirements and current business need. Analysis of that mismatch is required with any agreed changes cascading down the waterfall ultimately to be tested again.

Perception of success in the waterfall tends, therefore, to be related to how well the prediction matches the real need and how closely outputs align with prediction in terms of budget, timelines and quality.

The waterfall process may seem simple at first, but it often turns out to be more complex than expected. It relies heavily on documentation, uses hierarchical approvals, and follows centralized planning. Because it demands detailed, upfront documentation and planning, the process can become complicated, with many related parts needing to be connected for the process to achieve the desired result.

Advantages:

• Straightforward Structure: The step-by-step approach is easy for project managers to understand and explain to stakeholders.
• Predictable Planning: Comprehensive analysis and design at the start support clear and precise planning and budgeting.
• Simple Tracking: Progress can be monitored through documentation (showing how milestones are met) and checked against the plan (to confirm tasks are completing on time and within budget).

Disadvantages:

• Complex Change Management: Handling necessary changes can be cumbersome, sometimes leading teams to bypass the process entirely and resulting in a loss of control.
• Late Issue Detection: Development in large increments with testing largely focused at the end of the process can reveal problems too late, causing unexpected delays and cost overruns.
• Reduced focus on Business Value: The extensive upfront analysis and documentation offer no direct business value; they exist solely to guide the process.

While it still has a distinct process element to frame development, an agile approach to project management focuses more on people than process. Upfront work is intentionally light, shaping only the high-level solution and plan while leaving finer details until the last responsible moment before development. Typically, development proceeds feature by feature within fixed length “Sprints.”

Project participants – importantly, including businesspeople within the development teams – collaborate throughout the project. They build smaller increments than in traditional waterfall, using an iterative process.

Each iteration includes analysis, design, build, testing, and ideally deployment, in cycles that can last just a few hours or span several days or weeks (rather than the weeks or months often seen in waterfall). The goal is to deploy parts of the solution as soon as they can deliver value.

Development relies on the detailed collaboration of knowledgeable and skilled individuals empowered by the organisation to develop a solution that meets the business need.

Those individuals define the detail of the need before planning the development work required. They then carry out this plan, continually adjusting it to stay focused on delivering maximum value. For true agility, teams often follow values such as those found in Scrum, which is currently the most widely adopted agile delivery approach.

The iterative approach is highly tolerant to change because it postpones detailed planning until the last responsible moment, using real-time data and short planning cycles. Instead of being fully predicted early on, the solution gradually emerges to meet needs that were outlined (but not meticulously defined) at the start of the project.

By prioritizing high-level requirements upfront and handling the most important ones first, allows agile teams maintain tight control over deadlines and budgets. Development simply ends in a controlled manner once time or budget limits are reached, with only the least valuable items being excluded from the final delivery.

Because development cycles are short (usually around two weeks) and fixed, it makes sense to measure success through the incremental delivery of value at a predictable pace.

The iterative and incremental approach, with short cycle times driven by empowered self-organising teams, often appears chaotic. But staffed with competent, collaborative, disciplined people it is highly efficient and effective. That said, the risk of using an agile approach with individuals who are not competent, collaborative, and disciplined is very likely to lead to failure. This makes oversight (but not management) essential until the teams have demonstrated their collective ability to deliver.

Advantages:

• Iterative Development: Rapid development cycles with opportunity for collaboration and continual feedback reduces the risk of building a solution that doesn’t meet real needs.
• Incremental Value Delivery: Delivering tangible value in short intervals improves overall control by making progress easier to track and corrective action easier to identify.
• Adaptability: Leaving detail to the last responsible moment allows solutions to emerge to meet current rather than predicted needs.

Disadvantages:

• Can seem unstructured: Especially to those used to process-based controls. It is not well-suited to managers and leaders with high control needs.
• High competence and collaboration from all involved: Leaders require confidence to trust and competence to empower their collaborative teams.
• Potential for chaos and failure: Teams lacking demonstrated competence and professionalism can fail without proper oversight.

Note: the disadvantages described above apply to teams or organizations that are new to the agile way of working where there is genuine competence with agility it is hard to identify universal drawbacks although context-specific ones may well arise.

The key differences between an agile approach and a waterfall approach can be summarised in 5 dimensions:

1. Solution Development – Emergent vs. Specified:

• Agile: The solution emerges over time to meet changing business needs. Details evolve closer to development, keeping the solution flexible.
• Waterfall: The solution is defined upfront to meet an expected need. Careful change control is needed to maintain alignment with changing needs.

2. Project Participants – Collaborative and Cross-Functional vs. Siloed & Specialized:

• Agile: Team members work together with broad roles, doing whatever is needed to reach their shared goal. The aim is to avoid communication via documentation, and to minimise hand-offs wherever possible.
• Waterfall: While some degree of collaboration is often seen, it is often focused on specific and specialized activities (such as requirements gathering). Project participants tend to adopt the siloed Industrial Engineering approach that dominated 20th century thinking, typically with communication and control managed via documentation.

3. Management – Self-Organising vs. Managed:

• Agile: Teams organize and manage themselves, deciding how to complete tasks and adjusting processes as they learn.
• Waterfall: Teams typically receive direction from managers, who decide what must be done, by whom, and when. The level of detail in these instructions can vary based on the project or manager’s style, however.

4. Change – Embraced vs. Resisted:

• Agile: Because teams work toward broad goals without defining every detail upfront, they welcome changes as new needs or insights emerge.
• Waterfall: Management of change is bureaucratic and costly because it requires thorough analysis, documentation and approval. As a result, it often acts as a barrier to necessary change.

5. Control based on: Professional Discipline vs. Process Compliance

• Agile: Relies heavily on the team’s competence, discipline, and self-organization. Team members make commitments to each other and collectively own tasks and solutions.
• Waterfall: Uses detailed planning and clear instructions. Everyone’s role is defined upfront, and the project manager coordinates activities. Success depends on following the plan and processes as designed.

As I mentioned earlier, it depends…

In today’s complex world, running a fully agile or fully waterfall project is unlikely. More often, teams find that some agility can add value to a mainly waterfall project, while some waterfall elements make sense in an otherwise agile project. This blend is frequently called a hybrid approach, sitting in the grey area between the two extremes.

So, a project manager’s real question isn’t, “Which pure method should I choose?” but rather, “Where on the spectrum should my project sit?” Agile methods thrive in environments with high volatility, uncertainty, complexity, and ambiguity (VUCA). By contrast, waterfall approaches typically work best where things are more stable, certain, simple, and clear.

The Cynefin framework can help you pinpoint where your project might fall on this spectrum.

Cynefin, pronounced kuh-nev-in, is a Welsh word that signifies the multiple, intertwined factors in our environment and our experience that influence us (how we think, interpret and act) in ways we can never fully understand.

In an acknowledged over-simplification of the Cynefin Framework, the environment we are working in – in this case our project environment – can be placed on a spectrum characterised as clear, complicated, complex or chaotic.

In a project environment that is:

• Clear, there is an obvious path between problem and solution.
• Complicated, the path between problem and solution might not be obvious but good analysis will expose a path to an appropriate solution.
• Complex, it is not possible to identify a single path, even with analysis, because predictions can only be made based on theory rather than experience.
• Chaotic, there is no foundation for prediction because there are too many shifting or conflicting factors. The only way forward is through experimentation.

In the above, the clear domain lends itself to pure waterfall and the chaotic domain requires agility. The other two – the most common in reality – are probably best served by a hybrid approach. So, ask yourself, “which of the above best describes my project environment?” and let that guide your selection of approach.

You also need to consider other constraints driven by the rules and culture of your organisation in deciding on the most sensible approach for your project. Trying to make a waterfall approach work in a culture characterised by agility or an agile approach work in a culture characterised by command and control will cause problems.

A hybrid approach may be more likely to ‘sell’ and succeed.

The Agile Manifesto, enhanced to broaden its applicability beyond software, identifies four value statements intended to steer practitioners towards agile behaviours. Anybody aiming to work in an agile way should value:

Focusing on the items on the left while still acknowledging value in those on the right.

Although there is debate about whether the original Manifesto fully applies in today’s world – particularly in a software context – the value statements still offer helpful guidance for project governance. It makes sense to base governance for an agile project on the items on the left, and governance for a waterfall project on the items on the right.

• People and teamwork: Monitoring and enabling professional discipline and collaboration.
• Delivering business value: Focusing on value that supports business needs, rather than ticking off process requirements.
• Active business involvement: Having business representatives work closely with the team throughout the project.
• Meeting current needs on deployment: Ensuring the solution matches real business requirements at launch—even if those requirements differ from the initial plan.

• Following predefined processes: Ensuring everyone complies with established steps and approvals.
• Producing predictive documentation: Developing clear specifications and checking that the solution aligns with them.
• Approving changes properly: Validating all changes to original documentation.
• Adhering to plans: Ensuring plans stay accurate and responsive to approved changes.

In a hybrid setup, governance must find the right balance between agile and waterfall elements. This involves tailoring which parts of each approach make the most sense for the project’s specific context.

The most effective project delivery approach should be driven by context – both the nature of the work and the environment in which the project will live. Beware of anybody who promotes either pure agile or pure waterfall as a universally applicable recipe for success.

With a final reference back to the Cynefin framework – describes a state of Aporia (meaning impasse) or Confusion and is not a good place to be. You will most likely find yourself, and your project, suffering here if you are unable or unwilling to match your project approach to its context and its environment.

You need to think for yourself, analyse the context, and act accordingly. By doing so, you have the best chance of moving from the Aporia/Confusion into one of the other states where an approach, most likely a hybrid, will optimise your opportunity for project success.