Skip to main content
Methodologies & Frameworks
Agile Vs Waterfall: Which Is Better & When To Use Each One

If you’re part of the project management community, you may be aware of the great debate regarding which project management methodology to use—the agile methodology vs. the waterfall methodology. Why is this such a big deal? And how do you know which methodology is right for your project?

In this article, I’ll examine the core methodologies used in digital project management and help you choose the right one for your situation.

I’ll cover:

Agile vs. Waterfall: What’s the Difference?

The difference between agile and waterfall project management, like that of so many methodologies, is primarily a question of mindset. The project management methodology you choose to follow determines the principles, frameworks, and processes that govern your project.

In waterfall projects, you define the requirements at the beginning of an effort and then run the project from start to finish based on those requirements. For the most part, you’ll adhere to a structured delivery process and schedule of deliverables.

In agile projects, by contrast, the mindset is more about learning and iterating based on those learnings. Requirements are less well defined at project initiation. The team places less emphasis on documentation and structured deliverables and more on adding value for the customer.

Core Principles of Waterfall

In this section, we’ll review the pros and cons associated with the core principles of waterfall project management.

Pros of waterfall project management

  • Upfront requirements gathering. Developers and clients agree on what will be delivered early in the project life cycle, simplifying planning and design. It’s easier to measure progress given the full scope of work is known in advance. Comprehensive technical documentation makes it easier for new programmers to get up to speed.
  • Work completed sequentially in phases. The next phase of the project begins as the previous phase ends. Throughout the development, various members of the team can be involved or continue with other work. For example, testers can prepare test scripts from requirements documentation whilst coding is underway. The workflow is structured, and it can be easier to measure progress and track dependencies with clearly defined milestones established at the beginning of a project.
  • Testing occurs at the end of development. Testing is more straightforward to plan and execute, as it references specific scenarios defined in the functional specifications at the end of the product development phase.
  • Clients or stakeholders don’t need to be heavily involved. Except for reviews, approvals, and status meetings, a customer presence is not strictly needed after the requirements phase.

Cons of waterfall project management

Waterfall projects also present some significant drawbacks:

  • Stakeholders have limited ability to provide feedback earlier in the project life cycle. If the product does not generate customer satisfaction, there is limited time and budget to incorporate customer feedback in time for successful delivery.
  • Less flexibility to incorporate learnings and course correct. Like any self-respecting project manager, I live and die by a good project plan. But, reality does not necessarily go according to plan. The highly structured nature of waterfall projects complicates adaptability. It is difficult to respond to changes that inevitably arise during execution.

Core Principles of Agile

In 2001, a group of developers got together to compile what is now known as the agile manifesto, which describes the four values that they felt should underpin software development projects. In these 200 words, they changed the face of software development.

Within the agile framework, Scrum and Kanban represent two examples of agile approaches. Read more about Kanban vs agile here.

Pros of agile project management

Reviewing the four values of the agile manifesto gives us insight into some of the benefits of the agile software development methodology.

  • Individuals and interactions over processes and tools. Communication is key, not the processes that run your project. Agile teams should be self-organizing, meaning that they are able to make decisions collaboratively with limited oversight.
  • Working software over comprehensive documentation. There is a strong focus on getting shippable products more quickly, rather than spending a lot of time developing highly detailed requirements that are likely to change.
  • Customer collaboration over contract negotiation. Agile values emphasize client or customer collaboration that involves working closely with the client throughout the project life cycle.
  • Responding to change over following a plan. Rather than seeing change as the enemy, seeing the benefits of change and being responsive to change is core to the agile framework.

Cons of agile project management

No project management methodology is perfect, and agile is no exception, particularly given that the authors of the manifesto were a homogenous group of software developers that may not have adequately considered alternative approaches in developing their thesis.

If taken too far, potential disadvantages of agile project management include:

  • Relative lack of emphasis on project documentation could be a drawback to effective delivery, especially in remote environments that rely on asynchronous communication.
  • Collaboration can be a good way to surface diverse viewpoints, but there is a risk that it devolves into decision by committee, which may slow down the pace of work.

Sign up for our emails and be the first to see helpful how-tos, insider tips and tricks, and a collection of templates and tools.

  • Hidden
  • By submitting this form you agree to receive regular emails filled with tips, expert insights, and more to build my PM practice. For further details, review our Privacy Policy.

4 Differences between Agile and Waterfall

We’ve compiled this comparison chart to help you understand the core differences between agile and waterfall project management.

Project life cycleCyclical, moving between discover, build, test, and iterate phasesLinear, highly structured from start to finish
Customer involvementContinuous, close collaboration with ongoing feedback loopRelatively limited, provide feedback on key deliverables

Should I Use Agile or Waterfall on My Project?

What should influence your decision on which methodology to apply to a project

Existing organizational processes are typically the greatest predictor of how you end up running your projects. Given that each project has different needs, this isn’t necessarily the best way to approach this question.

Until you know more about the project and the context behind it, you’re not going to be able to decide which methodology is best suited. Consider these factors when evaluating methodologies:

  • Size of the project
  • Duration
  • Complexity
  • Ways of working at your organization
  • Clients or stakeholders, external and internal

Which projects are most suitable for waterfall?

Waterfall projects are best suited for:

  • Working with external organizations or vendors, where a high degree of collaboration may be impractical
  • Projects with a fixed scope, time, and budget
  • Smaller, well-defined, and simpler projects
  • Projects with a client that is not engaged

Which projects are most suitable for agile?

Agile projects are best suited for:

  • Efforts where your organization is responsible for the entire process
  • Instances where there is scope for changing requirements
  • Larger, undefined, complex projects
  • Projects with an involved client.

How Do I Use These Methodologies?

Knowing the theoretical difference between the agile method and the waterfall method is one thing—but how do we, as project managers, put these methodologies to work to maximize the benefits for our teams and our clients?

Learn how to use a strategic approach to these methodologies in the real world with our online course. With relevant, practical, expert-led training, you’ll become a source of insight for your teams and clients that will allow you to confidently navigate the trials of project management.

Is Agile Better than Waterfall?

I’ve been sitting on the fence so far, saying both methodologies I’ve featured have benefits in their own right. But if we’re living in an ideal world, the agile approach is better suited to digital projects

Agile principles are more in tune with a digital landscape that is characterized by evolving requirements and continuous change. Here are some of the key benefits:

Regular Iterations

Regular iterations of work, which include testing and stakeholder reviews (ex. two-week sprints), help keep a project on track. 

Consider two of the meetings that Scrum masters facilitate: the review—in which you review the build at the end of the sprint—and the retrospective, in which you review the work completed in the sprint. They are your early warning signs for anything that may not be progressing as desired.

Client Involvement

In 2013, the Chaos Manifesto reviewed IT and software projects delivered over a five-year period. The authors of this publication found that the biggest factor in project success was a committed executive sponsor or product owner. When a client is closely involved in a project, including review and prioritization of work, they are less likely to offer last-minute surprises.

In one project I worked on, the client wasn’t involved much. They preferred to receive a weekly status report in lieu of attending meetings. While we tried to get them more involved in defining the user experience, they were too busy on another project to contribute.

When we arrived at the initial presentation, the client was disappointed in the quality of the product because they hadn’t contributed their requirements, and they weren’t evolved in the evolution of the idea. This required us to backtrack and waste a few weeks incorporating the feedback.

Team Collaboration

Rather than user experience working to define a project, handing to design, then handing over to development, with everyone in their own siloed areas—you can avoid a lot of issues through teamwork. Closer collaboration earlier in the project life cycle helps avoid surprises towards the end of the project.

Evolving Requirements

Changing scope and requirements do not throw an agile project into crisis. In fact, the sprint review and the sprint planning meeting are intended to work out what changes are needed. 

Conversely, in waterfall models, plans are worked out months in advance of development, based on rough estimates at the time, and then set in stone. But, the truth is that linear project plans simply don’t work.

I can’t remember the last time on a more traditional linear project I didn’t have to amend the project plan at least twice during the project’s course. 

That’s because projects change. Clients change. User needs change. Technology changes. Digital is constantly changing. Agile models tend to have better ways of responding to change. In fact, they embrace it rather than seeing it as a big blow to the project.

According to the Chaos Manifesto, “over a 5 year period, an average of 53% of projects ran over on cost, and 76% ran over on time.” If we took an example of an agency that runs on average 50 projects in a year, that’s 25+ projects running over on costs and 37 projects (out of 50!) running over on time. Something obviously isn’t working.

The Hybrid Project Management Approach

So, if agile projects have such clear benefits, then why aren’t more organizations practicing it? Because it’s not always easy to fully or quickly implement agile approaches. Agile may not sit well with clients that want a fixed scope, budget, and project timeline upfront. 

This is where a hybrid project management approach comes in.

What is a Hybrid Project?

It’s best to define a hybrid project by contrasting waterfall and agile projects. A waterfall approach is linear—you conduct discovery, define requirements, build the product, and then test and deploy at the end.

4 different shapes, each with of the following words, in order: discover, plan, build, and review to show a linear waterfall approach
A linear, waterfall approach.

Many organizations that claim to be agile follow this type of process:

a discover shape next to a plan shape followed by three sets of build and review shapes stacked on top of each other to illustrate a hybrid approach
This is more of a hybrid approach, rather than a strictly agile approach.

If you are following this linear process of discovering, defining upfront, then sequentially building and testing—this is still a linear project. Splitting the development process into two-week sprints and doing a daily catch-up does not equate to “agile.”

In a truly agile project, the process will look more like this with each phase contained within the iterations:

3 sets of discover plan build review shapes sectioned off from each other to illustrate an agile approach
A true agile approach.

A seamless transition to agile delivery is difficult for a lot of organizations. Several factors make it tricky to implement agile, including the need for a greater degree of client involvement, a lack of understanding of the agile framework, and trying to figure out how to integrate UX.

If this feels daunting, implementing a hybrid approach can be a good way to gradually transition to agile principles. I know this can be quite controversial (and might anger agile purists), but a hybrid approach seems to be a more realistic solution, at least while the transition progresses.

Here’s what the flow would look like in a hybrid environment:

a discover shape followed by three sets of plan build and review shapes stacked on top of each other to illustrate another hybrid approach
Another hybrid approach.

How to Implement a Hybrid Project

If you work at an organization that follows a more linear way of working but that would benefit from an agile approach, how do you help your organization adopt a hybrid solution as part of the transition?

Client involvement

Ideal: An empowered, available product owner 

A core problem tends to be involving the client or stakeholder as product owner. They need to be heavily involved, and you might find this difficult when they’re involved in other projects.

They are often not used to this either. They often expect to assign you the work and then receive a weekly status report on progress.

Hybrid: Bridge the gap between stakeholders and team members

One solution could be to act as the product owner but get the client to agree to be involved in the core review and planning meetings. Make sure they are involved in setting and defining requirements at each stage.

Team collaboration

Ideal: A cross-functional, dedicated team

It can be a struggle to assemble a cross-functional team that is dedicated to your project. This can be especially true in smaller organizations that operate a lot of projects and expect team members to work across multiple projects.

Hybrid: Team members keep involved throughout

Make sure that team members are working together and collaborating. If you can’t book team members full-time across each sprint, make sure they are included in regular discussions with the development team and that they attend daily standups, planning, and reviews. A team that talks to each other can help a project succeed.

Continuous planning

Ideal: Planning requirements per sprint

Changing the client or stakeholder’s way of thinking is also crucial so that requirements aren’t set as strict, immovable functional specifications at the beginning of a project.

But, clients and stakeholders are often scared to change this. They want to know what functionality they are getting when they sign off on the budget.

Hybrid: Some upfront shaping, but leave detailed planning to the sprint

Look at whether you can do some upfront loose shaping of the project requirements, but leave the detailed planning to the sprints.

Don’t pin down the deliverables in the first instance, so that you can react to change along the way. Coach the client to get buy-in on this planning approach. Outline the positives of being responsive to change throughout the project.

Designing what is needed

Ideal: Design within each sprint

How does design fit in? The ideal would be to run this in each sprint, so designing only what is necessary for each iteration of work.

Hybrid: Design at the last responsible moment

Instead of defining a whole bunch of design requirements upfront, design what you need to as late as you can. This reduces the likelihood that you design unnecessary items that aren’t even used in the end.

Again, this goes back to collaboration and getting designers, developers, and other cross-functional team members to work together on a sprint or time-boxed phase of work.

How to Transition to Agile

If your organization is truly ready to transition to agile, perhaps after adopting a hybrid approach as a first step, consider the following steps.

Get Help

Use training, mentors, and coaching to explain the benefits of following an agile approach. This is important for you as the project manager, the team, and your client.

Get Management Buy-in

No process is going to change without management buy-in. Identify the benefits and the approach to adoption. If you can present a plan of how you’ll rally clients and stakeholders around this approach, it will greatly ease the transition.

Get Real

If things aren’t working, don’t make excuses. Agile follows an iterative approach. Your implementation of the process should be iterative too. Regular reviews of how it is going let you identify and resolve issues more quickly.

Instead of making excuses about how it’s going, “oh we’re implementing a new process it’s bound to have problems,” present plans of action about how to fix the issues and move forward. If you fail, fail fast and move on.

Common Pitfalls

When defining your own hybrid process, keep an eye out for these common faults.

Lack of process or structure

You overindex on the idea that agile projects don’t require process, so you have nothing concrete defined. The project becomes a mess without defined ways of working.

Process for the sake of process

On the other hand, don’t blindly put processes in place for the sake of process. Refrain from creating unnecessary documentation. No matter which methodology you are following, streamline your process as much as possible.

Lack of team alignment

If your team members don’t know how they should be working, they might start going off on a tangent, rather than focusing on what they should be doing. Make sure that you clearly define roles and responsibilities.

One size fits all approach

Beware the one size fits all approach: the idea that because something was successful once, it’s going to work for every project. Make sure you consider each effort as its own entity. While organizations benefit from cohesive processes, that approach should be tailored to unique project circumstances.

What Do You Think?

So what will it be? Agile or waterfall? Could a hybrid methodology be a good alternative when transitioning to agile? What are your experiences and successes (or failures) running waterfall, agile, or hybrid projects? Join the conversation and share your thoughts.

Or, read about the differences between Kanban and Scrum (two distinct agile methods).

By Sarah M. Hoban

Sarah is a project manager and strategy consultant with 15 years of experience leading cross-functional teams to execute complex multi-million dollar projects. She excels at diagnosing, prioritizing, and solving organizational challenges and cultivating strong relationships to improve how teams do business. Sarah is passionate about productivity, leadership, building community, and her home state of New Jersey.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.


  • It is a nice blog, everything in the blog is self explanatory


  • I am currently building a team with no experience in Agile nor Waterfall. In your opinion, which between the two is the easiest to learn and adapt for beginners? I love hearing your feed back. That would be a big help in building my team.


  • Good to read on.


  • In the document "From the 20 Biggest Issues of Waterfall to 1" I discuss a bit more in depth probably the 20 biggest issues of waterfall. Enjoy.


  • Great article. Thanks for sharing your thoughts!


    • Thanks Gareth :)


  • Hi Suze, great topic! Definitely, this will help a lot of project managers. We currently do waterfall but I'm slowly switching to an agile approach. I highly agree that project success usually depends on the soft and hard skills of the project manager, the rest will follow.


    • Thanks, glad it will help!


  • Great article! We typically have clients that want to know exactly what they're getting and what it's going to cost up front. Any tips for educating clients on the benefits of an agile approach? Also, do you have any examples of how you'd set up a budget and scope on an agile or hybrid project? Just estimate and scope as each phase comes up?


    • Thanks Carly! Great questions – costs is something I haven't really addressed in this article. In fact this article is based on a talk I gave at Deliver Conf in the UK last year, and I did a follow up talk on estimation this year – maybe I should write that talk up as well :) Educating clients can be a slow process, but I'd say firstly get internal buy-in in your organisation, so you have the backing for the approach. Then really look at the benefits to that specific client – how can it make their life easier, how can it be cost-effective for their business, or how will it make things more efficient for them? Try a gradual integration, so adopting parts of the approach, showing that these work first, and then only then introducing more. In terms of budget on a hybrid project, an approach could be to provide a discovery cost, and then the rest of the project can be scoped for at the end of discovery. This will give a much better estimate than doing it all upfront, before any work has been done. If you can get client buy-in on the phase by phase costing that's great! Otherwise, if they do need an upfront cost there are various ways to make estimation more realistic – this is what I need to write up from my talk! Hope this helps!