There’s no shortage of processes, frameworks, and philosophies when it comes to project management, but they ultimately fall into one of two camps: Agile vs. waterfall. Understanding what these two approaches are and how they differ is important for anyone involved in product development, organizational change, program management, or almost any other kind of structured project.
Agile and waterfall often represent an irreversible fork in the road for any initiative. Once you choose one path, it’s quite challenging to change course for that project, so it’s not a decision to take lightly. That’s not to say that Agile and waterfall can’t coexist in the same organization, but for a particular project, it’s usually a “one-or-the-other” inflection point.
Let’s begin by covering the basics of each philosophy.
What is Waterfall?
Waterfall is the “old school” way of managing projects. Throughout the life of the project, there are well-defined stages with formalized hand-offs from one to the next. Moreover, all of the requirements for each step is completed before the next begins.
Although there are dates and schedules in a waterfall environment, each stage and project lasts until completion unless the rolling out initiative was specifically designed to be in phases comprised of multiple projects that build on one another.
A healthy waterfall environment doesn’t employ a “throw it over the wall” mindset where stakeholders pass on responsibility to the owner of the next phase. It is, however, primarily a linear process beginning with requirements and terminating in a final release or completion of the project.
What is Agile?
Agile is the new kid on the block, relatively speaking, and prizes rapid iteration, autonomy, and flexibility. It was conceived specifically as a reaction to waterfall’s perceived shortcomings.
In an Agile environment, you are divvying up work into Sprints, which are time-based bursts of activity, typically one-to-four weeks in length. This cadence dictates how much work is completed during a given period.
The goal is to deliver value to the customer or user as quickly and often as possible. Thus larger projects are broken down into smaller pieces so that progress can be made during each Sprint.
Aside from receiving their priorities and use cases from the business, Agile product management teams are self-organizing. They figure out the best way to allocate their resources to meet the requirements of each initiative, consulting with the Product Owner or subject matter experts from lines of business when necessary.
Comparing the Two methodologies Side by Side:
Waterfall would look something like this:
Agile would look something like this
When Should Agile vs. Waterfall Be Used?
Strict adherents of Agile or waterfall might insist it’s appropriate for any situation, but in reality, different types of projects are better suited for one versus the other.
Waterfall is particularly useful for large, complex projects with very specific and unchanging requirements. Development teams will be less resistant to detailed product requirements documents and design specifications since that’s what’s expected.
It can also be easier to map out dependencies and structure the overall project plan in a waterfall setting. Individual teams don’t have the option to “go rogue” on their particular piece of the puzzle. That independence and creativity is prized in Agile, but may not be a great fit for larger or more complex initiatives.
Organizationally, stakeholders must be mentally and emotionally prepared for Agile, which is likely a relatively new concept in many industries. While they may prefer the “sound” of rapid iteration and constant activity, they may not be comfortable with the lack of visibility and oversight required for Agile to thrive truly.
Agile works well for projects that prize learning and are seeking or refining their product-market fit. The speed and flexibility of Sprints dovetail nicely with a continuous feedback loop and ongoing experimentation and tweaking.
Another environment where Agile can thrive is one with a clearly articulated and well-supported product strategy. When everyone is aligned around objectives, goals, and KPIs, there’s more comfort in giving individual teams the freedom and independence to work toward achieving them rapidly.
What are the Key Differences?
Agile and waterfall differ in many ways, but the most significant deltas pertain to oversight, processes, documentation, and timing.
Benefits for different teams
While neither approach is detrimental to any part of the organization, different groups and stakeholders may prefer Agile or waterfall.
As software engineers developed it, Agile is usually favored by the technology organization. They get much more autonomy, have a greater say in what they build and build it, and are less beholden to outside parties.
Other parts of the organization may also prefer Agile for a variety of reasons. Product management gets to see value delivered to users more frequently and faster. UX teams have far more learning cycles and opportunities to improve the customer experience. Customer support may see bugs and other issues resolved faster. Sales and marketing will always have something new to talk about.
However, those same groups may also be fond of waterfall’s benefits, such as seeing large, complete visions delivered all at once, less frequent need for training and education, carefully crafted user documentation, having major milestones to anchor sales and marketing activities, or seeing their meticulously specified mockups brought to life.
At the executive level, it is again a matter of taste. Many may prefer the command-and-control gatekeeper role they can play in waterfall, while others may favor the rapid pace of updates and enhancements Agile facilitates.
What are the Pros and Cons of Agile vs. Waterfall?
Like anything else, waterfall and Agile have their plusses and minuses. Here’s a quick breakdown of the good and the bad of each:
Agile
Pros
- Flexibility to respond to the market and new intelligence
- The implementation team has room for creative problem solving
- Self-organizing teams and resource allocation
- Frequent updates and increased customer value
- Rigid cadence, deadline flexibility
Cons
- Loose planning can lead to unpredictable finished product and date slippage
- Susceptible to a lack of focus and knee-jerk reactions from Sprint to Sprint
- Relentless pace
- Loose testing requirements may let bugs through
- No opportunities to make changes during a Sprint
Waterfall
Pros
- Minimal scope creep
- A predictable and well-specified final product
- Well-defined roles and responsibilities
- Infrequent releases that can be carefully rolled out and messaged to users and the market
- Precise project plans and firm deadlines
Cons
- Lack of flexibility after a specification
- Fewer opportunities to course correct
- Too many gaps between innovations reaching the market
- Too long until bugs are discovered since testing doesn’t occur until the large project is complete
- Beaurocratic change management process
What is the Difference in Cost for Agile vs. Waterfall?
Neither Agile nor waterfall are particularly expensive to implement. They don’t necessarily require specialized software packages or other capital investments and operating costs.
However, staffing and training are directly impacted by which method is selected, and the transition from Agile to Waterfall can be bumpy. Agile requires small, self-organizing teams to function properly. Each team typically has its own Scrum Master and Product Owner, although these roles sometimes cover multiple teams.
Many organizations may not have enough people to fill those roles, particularly if they create a number of Scrum teams. It will require hiring, paying, and possibly training that staff.
Similarly, Agile doesn’t work well unless everyone involved is well-versed in how it functions. This may require hiring trainers, sending out employees to be certified as Scrum Masters, Product Owners, etc., or hiring Agile Coaches on a permanent or consulting basis.
Waterfall doesn’t have many dedicated resources other than project management. The bigger concern is that some people may be idle or underutilized depending on which phase a project is in and whether their talents and skills are fully needed at that time.
Where Agile is definitely cheaper than waterfall is when companies aren’t exactly sure what they want, be it entering a new market, launching a new product, or making a major extension into a new area. Because Agile allows and encourages rapid learning and course correction, it prevents companies from sinking as much money and resources into a multi-month project only to see it miss the mark.
What About Product Roadmaps?
Whether an organization uses waterfall or Agile, product roadmaps still have an important role to play. But how we build those roadmaps and what they look like might be a little bit different.
Product roadmaps are a long-standing part of waterfall product development. Since the projects are large, well-defined, and scheduled far in advance, product roadmaps are reliable indicators of what’s to come and can offer quite a bit of granularity.
In Agile, there’s not the same level of detail available during the product roadmapping process. That makes those settings excellent candidates for feature-based roadmapping. Although these can also work in a waterfall environment, Agile organizations benefit from the feature-less approach.
These roadmaps capture the product vision and prioritized themes for the coming months and years, but don’t get into the specifics of what particular features and enhancements are being developed. It shifts the focus from features to outcomes and goals, which the organization cares about anyway.
Using a purpose-built product roadmapping tool like ProductPlan, feature-less product roadmaps can align the organization around the major initiatives being worked on, with additional detail and information added as development progresses. This looser, more fluid approach fits nicely with Agile’s de-centralized model.
Does an Organization Have to Choose One or the Other?
Although Agile devotees may claim it’s all or nothing when it comes to Agile adoption, there are some organizations that borrow from both methodologies for a hybrid model. Typically, they take the more specific direction and pre-determined implementation aspects of Waterfall and marry them with the iterative, short bursts of productivity parts of Agile.
In this world, there are still large projects with stage gates and overall project plans, but the work is chunked up into Sprints that have a specific scope and timeline. When possible, each Sprint’s output is released, but sometimes large initiatives may take multiple Sprints until they’re ready for prime time.
This frees up the software development team to run as if they were essentially an Agile shop while still giving the business side of the house the structure and oversight that comes with waterfall.
Another take on the hybrid model is basing the decision of which approach to adopt based on the riskiness of the project, as well-defined projects are a good fit for Waterfall, while those with unknowns are more suited for Agile. Most importantly, teams shouldn’t marry themselves to any methodology. Instead, continually evaluate what the best fit is for any initiative at a given time.
Looking to learn more about Agile? 
