If you’re part of the project management community, you may be aware of the great debate regarding which project management methodology to use—agile vs waterfall. Why is this such a big deal? And how do you know which methodology is right for your project?
I examine the core methodologies used in digital project management, agile project management and waterfall project management, and help you choose the right one for your situation.
What’s the Difference Between Agile & Waterfall?
The key difference between agile and waterfall is that agile focuses on adapting to change and delivering work in iterations and increments, while in waterfall, all planning and requirements gathering is done at the beginning of the project, with little room to change or adapt later.
In waterfall, projects run from start to finish based on the requirements defined at the beginning and adhere to a structured process and schedule of deliverables. In agile project management, by contrast, requirements are less defined at project initiation. The team places less emphasis on documentation and structure and more on adding value for the customer.
| Aspect of Project | Agile | Waterfall |
|---|---|---|
| Project life cycle | Cyclical, moving between discover, build, test, and iterate phases | Linear, sequential, highly structured from start to finish |
| Documentation | Limited | Comprehensive |
| Customer involvement | Continuous, close collaboration with ongoing feedback loop | Relatively limited, provide feedback on key deliverables |
| Processes | Light | Process-driven |
Many project management software tools support both agile and waterfall methodologies, as well as hybrid combinations (more on that later!)
Pros & Cons Of Both Methodologies
No project management methodology is perfect, and while waterfall is often maligned, agile methodologies (such as Kanban, Scrum, Lean, and eXtreme programming) have their fair share of disadvantages as well.
Waterfall Project Management: Pros & Cons
| Pros | Cons |
| 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 when the full scope of work is known in advance. Comprehensive technical documentation makes it easier for new programmers to get up to speed. | 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. |
| Work completed sequentially in phases. The next phase of the project begins as the previous phase ends. Various members of the team can be involved or continue with other work. 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. | 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. |
| 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. |
Agile Project Management: Pros & Cons
Agile is a mindset based on the four values outlined in the agile manifesto, and there are many agile frameworks and methods based on those values (Scrum Kanban, and lean are three popular examples).
| Pros | Cons |
| 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. | Relative lack of emphasis on project documentation could be a drawback to effective delivery, especially in remote environments that rely on asynchronous communication. |
| 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. | 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. |
| 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. |
When To Use Agile vs Waterfall?
Often, the decision of when to use agile vs waterfall isn't up to the project manager. 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?
The waterfall methodology is 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 is 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 sprint retrospective, in which you review the work completed in the sprint. They provide 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 factors in project success were a committed executive sponsor or product owner. When a client is closely involved in a project, including in 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 involved in the evolution of the idea. This required us to backtrack and waste a few weeks incorporating the feedback.
Team Collaboration
Rather than having the user experience team working to define a project, handing it to design, then 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 I didn’t have to amend the project plan at least twice during the project’s course on a more traditional linear project.
That’s because projects change. Clients change. User needs and customer 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.
Combining Both Agile & Waterfall
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.
Many organizations that claim to be agile follow this type of process:
If you are following this linear process of discovering, defining upfront, then sequentially building and testing—this is still a linear project. Splitting the software 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:
Several factors make it tricky to implement agile, including the need for a greater degree of client involvement and a lack of understanding of the agile framework.
If this feels daunting, implementing a hybrid approach can be a good way to gradually transition to agile principles. 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:
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? Here's how to do it in a few key areas of the project.
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.
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 and get buy-in on this agile 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 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.
Common Pitfalls of Hybrid Approaches
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.
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, present plans of action about how to fix the issues and move forward. If you fail, fail fast and move on.
What Do You Think?
Want to chime in on the agile debate? Join the conversation in Slack with 100's of other digital project managers with DPM Membership! You'll also get access to 100+ templates, examples, and samples for project documents, meetings agendas, and more.