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?
- Should I Use Agile or Waterfall on My Project?
- Is Agile Better than Waterfall?
- The Hybrid Project Management Approach
- How to Transition to Agile
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.
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.
| Agile | Waterfall | |
| Project life cycle | Cyclical, moving between discover, build, test, and iterate phases | Linear, 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 |
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.
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 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:
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:
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).
10 Comments