Agile vs Waterfall Methodology: What’s the Difference?

agile vs waterfall methodology


Agile is a popular term these days, and you likely hear it a lot. But what is it and what’s the difference between agile vs waterfall methodology? If you feel left behind and want to catch up fast, this post is for you. By the end, you’ll have a high-level understanding of each and how work is done in agile vs waterfall.

In this post I’ll do the following for you:

  • Explain Agile
  • Explain Waterfall
  • Give an example of how a simple project would be handled with each
  • Cover the pros and cons of waterfall and agile

When you finish reading this post, you’ll have a better understanding of each, what each looks like when applied to a simple project, and reasons why each might be good or bad approaches for your team.

Sounds good, right?

Great! Let’s get started…


Agile vs Waterfall Methodology

Here’s an overly simplified explanation of the waterfall and agile approach:

  • Waterfall is a project management approach in which the team does the work in sequential phases – usually finishing one phase before moving on to the next.
  • Agile is a framework primarily characterized by short iterations (blocks of time).  The team repeats the same steps over and over. The team also reassess the work as they develop the solution. This influences the work going forward, and the team has the flexibility to adjust as needed.

But there’s a LOT more to it than that.

Still keeping it simple for you – but diving a bit deeper – let’s get more detailed on the differences between Agile and waterfall methodology.



In a waterfall approach all planning is done up front, and then the team executes according to the plan.  A project manager leads the effort and works closely with the team to plan and execute the project. The project manager serves as a single-point-of-contact to coordinate the effort.

The team generally completes work in one phase before moving on to the next. Here’s a simplified explanation: The team does all the planning up front. Then they do the work in the plan. Then after completing all the work and developing the product, they hand it off to the customer.

For a software project, the work in waterfall development follows a sequential order that looks like this:

  1. Requirements Gathering and Analysis 
  2. Design and Develop (Coding)
  3. Testing
  4. Deployment / Implementation
  5. Maintenance & Support

A project executed with waterfall methodology follows sequential phases as the team moves through planning and execution before delivering the final product to the customer. The project manager works with the project team and customer to determine the project scope. The group works together to identify and document all the business and technical requirements needed for the project. They document all of this and get stakeholder sign-off.

The team then determines how long it will take to complete the work to meet each of the requirements.  They figure in dependencies among the tasks.  They identify deliverable dates based on this information.

These tasks, dependencies, and deliverable dates become the project schedule.

But sometimes it doesn’t happen like this. Sometimes the customer tells the team that they need the solution quickly, by a certain date.  The team will have to work long hours to meet that date set by the customer.

Once the date and plan are settled, everyone agrees to this schedule, and the work begins.

The developers write the code. The team orders the materials and completes all other necessary work. Depending on how vast and complex the project is, this could take many months (or years).

Finally, once the team completes all the work, they deliver the solution to the customer. By then, much time may have passed, and things may have changed for the customer. They may have a different idea about what they need by this time. These changes could result in more work and delays before the customer can benefit from the product.



In agile, there’s often no formal project manager role. When following the agile scrum approach, there are three typical roles (these are not job titles)*:
*these descriptions are simplified for this article

  • Scrum Master. The “scrum master” works with the team to help organize regular events such as daily meetings and customer demos. The scrum master also works to remove any impediments to the team’s work.
  • Product owner. The product owner represents the customer or stakeholders. She’s responsible for understanding the requirements and prioritizing the work. She communicates regularly with the customer and the team.
  • Team member. The team members write the code, test, and demonstrate the working code to stakeholders. They create the product.

Agile is an iterative approach that prioritizes delivering value to the customer quickly. The team doesn’t wait until they’ve finished all the work before giving something to the end user. Instead, the team determines the smallest amount of work that the customer can get value from. Then the team develops that part and hands it over to the end users. Then the team adds to it and continues to build and improve the product.

Here are some characteristics of agile: 
Repeated Sprints

The team doesn’t plan the entire project first before developing the product. Rather, the team works in short blocks of time (iterations). These iterations are usually 2-week sprints repeated over and over. During each sprint, the team carries out continuous planning, development, and testing.

In Agile, the team tests code in the same sprint they wrote it in. During each sprint, the team finds and corrects errors, building in quality. The team tests code all throughout the course of the implementation, not only during a “testing” phase. There is no “testing” phase. Instead, testing happens repeatedly and is done during each sprint to ensure quality throughout the implementation.

Review and Adjust

As the team completes work, the team and customer review and adjust the design and go-forward plan as needed. During each sprint, the team incorporates customer feedback into the design. The team makes adjustments as they move forward.


The development team works closely with the customer throughout the implementation. The team and customer rank order (prioritize) deliverables based on the value they provide. They identify the most valuable work to be done and do it first.

Accelerated Value to the Customer

The goal is to get working software in front of the customer as soon as possible to provide value and get feedback.


Don’t think that because this approach is more flexible there’s no planning. There actually is planning in this approach

It’s important to note that even though there isn’t a rigid plan, planning does go into the work. The Carnegie Mellon paper “Parallel Worlds: Agile and Waterfall Differences and Similarities” points out that “…Agile is a disciplined planning process, including understanding requirement dependencies, potential groupings and infrastructure needs.”  The team needs to have an understanding of where they’re going and what’s needed to get there. It’s just done in a more flexible way.

Agile provides the flexibility to adapt to changing requirements along the way.

To understand Agile better, you might want to read about the philosopy behind it. I’ve written about the Agile philosophies in this post: A PM’s Guide to Agile Software Development

So now you’ve got a brief explanation of each approach. That’ great, but now you want to know what it looks like when the team executes a project using each.

I’ve got that for you, too….

What Does it Look Like? An Example Using Agile vs Waterfall Methodology

Let’s compare the difference between agile vs waterfall methodology by using an example.

Let’s go with a simple example of building a website to demonstrate the difference between the two approaches.



The project manager and team meet with the customer to get an understanding of the website that the customer wants and needs. You scope out the project and work with the team to develop a schedule with milestones. You let the customer know when the team will complete and deliver the website. You also identify high-level milestones to help in reporting progress.

Everyone agrees on the delivery date.

You and appropriate team members meet with the customer to gather solution details. You document these requirements and get agreement and sign-off from the customer.

The team starts work on building the website, with the interface and any database needs they may have.

After a few months of work, your team presents the website to the end user. The end user introduces you to their new team member who has some great new ideas for the website. The team needs to go back and do more work before they can give the final product to the customer. The customer now has to wait even longer for their website, and the target delivery date is out the window.



The product owner meets with the customer to discuss the website that the customer has asked for.  She gets a good understanding of what will be needed and meets with others who need to be involved in the discussion. Those others could be folks who work with the database, or architecture, or anything else needed. The product owner prioritizes the work in a way that will deliver value to the customer quickly.

The product owner works in close collaboration with both the customer and the team to make sure all expectations are in alignment.

The product owner and team identify what they can do to deliver a single increment of functionality to the customer. This means – what can we create that we can give to the customer that will be useful to them? (It might start with a small part of the website, such as a webpage with a logo and some static information.)

The team organizes the work in two-week increments, called sprints. The team determines how much work they can do in each of these sprints. The team identifies and commits to the work it can do within the first 2-week sprint. During that time, the team focuses on that work and communicates daily.

As soon as the team has something they can show the customer, they demonstrate it (even if it’s not yet elegant and pretty) to get feedback and adjust.

In the website example, the team could show the customer a screen in a browser with appropriate layouts, fields, controls and labels, even if it’s not yet perfect. While a wireframe drawing may be a good starting point, there’s no substitute for a functioning web page running real software on a real server.

The wireframe will give you a good idea, but there’s no substitute for seeing it work.

The demo shows the customer what they’ll be getting. The customer can then provide feedback so the team can make any adjustments, or move forward as planned.

Then as soon as the website is good enough for the customer to start using, they do. The team can continue to work on the website and build it out further, but the customer can start using the minimum viable product as soon as possible.

Thus, the customer doesn’t have to wait until the end of the project to start using a solution. The customer gets to give feedback and influence the design as they move forward throughout the course of the project.


Agile vs Waterfall Methodology: Benefits and disadvantages

No single approach is perfect for every situation. As much as I have loved the order and comfort from knowing the entire plan up front in the waterfall approach, there are downsides. And as much as I love the dynamic nature of the agile approach, it’s not perfect for every project.

There are pros and cons to both approaches, as you’ve likely guessed. I’ve listed quite a few here to give you a better understanding of what those are.


Benefits to using Waterfall

    1. The customer and team have a clear idea of the cost, scope, features, functionality, and delivery dates of the solution, since the team plans and designs up front, and everyone agrees early what the team will deliver.
    2. The team can report progress against project milestones, and report status against these milestones.
    3. Substantial customer involvement isn’t critical through the course of the project, since they provide input at the beginning, and the plan is set in place and followed.
    4. Because waterfall values detailed record-keeping, there’s more detailed information for future reference. These records provide documentation for any future needs. For example, if new team members come on board, the documentation contains information that will be valuable for support or future development.
    5. If the group needs to work on multiple projects simultaneously, the team can stagger their work. Different groups can work on multiple projects that are at various phases. For example, business analysists can write requirements while developers are coding another project that is further along in a later phase.


    Disadvantages to Waterfall

    1. If there are inaccuracies in the requirements and up front planning, there’s no flexibility for change going forward without impact to the plan.
    2. Because the team conducts testing toward the end of the project, they likely won’t find bugs and errors until then.
    3. The rigid upfront plan doesn’t allow flexibility to adjust if there are changes to the business needs, technology or marketplace. If any of this happens, the plan must change. A customer may discover they need something different than they originally stated, or a technology change might cause a change in the design.
    4. Customers can’t visualize the end product as easily from requirements and wireframe design drawings. The final product might be different than what they had hoped for. There is a risk of the final deliverable missing the mark or the customer being disappointed.


    Benefits to using Agile

    1. Agile incorporates flexibility into the process. The team and customer expected that there will be changes along the way.
    2. Transparency and frequent communication improve collaboration among the team and customer.
    3. Close ongoing collaboration between the development team and clients ensures that neither the team nor the customer is surprised by the solution the team delivers. The customer knows what they’ll be getting.
    4. The customer provides feedback along the way and is more likely to feel more ownership of the solution.
    5. The users get working software sooner rather than waiting until the end of the project. The team can deliver a basic solution, and then add more features and functionality in ongoing iterations.
    6. The customer and project team can adjust to technology and market changes if needed during project execution. If a feature needs to be added, the team can do it more easily.
    7. Continuous testing ensures that the team builds in quality all along the way.


    Disadvantages to Agile

    1. Customers may not be willing or able to participate as frequently as is required in Agile.
    2. Teams work very closely together, so being in the same physical location is an ideal state. It’s not always possible, though, and it can present challenges. (Modern communication tools make this easier to deal with.)
    3. It can be difficult if team members have to focus on multiple projects at once.
    4. Because the customer might reprioritize or add features throughout the implementation, and the delivery is time-boxed through multiple sprints, it’s possible the team won’t complete all desired work by the time they hoped. More time may be needed to get everything done.
    5. It’s possible that the final product turns out to be different than the customer’s original plan. (this isn’t necessarily a bad thing, though.)
    6. Teams must be very disciplined and focused.
    7. Management support is critical for the team to focus on the sprint features and goals, and not distracted by changing priorities.

There you have it….

So there’s your high-level overview of each approach.

Waterfall teams plan all the work up front, then the team does what they said they’ll do, and give the product to the customer by the date promised.

Agile teams get a good understanding of the product, then work to get something valuable to the customer fast, and get feedback and adjust while they keep working on it.

Now that you know the difference between the two, which approach appeals to you more? What questions do you have about either? Let me know in the comments.

And if you found this helpful, please share!



Leave a Reply