Agile vs. Waterfall: Which is the Right Project Management Methodology

Before directly answering the question in the title, it’s always good to make it clear what the ultimate project goal you want to achieve

How the product shall look in a month, half a year, and a year from now. But describe it now. This will give you some perspective and set the basic expectations about the level of your predictability, flexibility, agility, speed to market, and cost fixation in time.

Yes, today, setting up the waterfall projects seems to be a ridiculous idea. Especially if it was already proven countless times that if you want to quickly react to the shifts in the markets, you have no other option than to go agile. But if your goal is to deliver a product one year from now with features that are already pretty clear and restricted right from the beginning, and you have teams of people with no previous experience with agile methodology, then sure, stay conservative and go waterfall.

Not every case is so simple to conclude. Let’s have a look at how to evaluate better which methodology is better for your project.

What Does a Waterfall Look Like?

Instead of going into some definitions that everybody is already aware of for a couple of decades now, a practical outcome of a waterfall project usually looks like this:

1. First, plan what you want to do as the end result/product and how much it can roughly cost.
2. Start the requirements-gathering process. You thoroughly discussed all the details of the end product, objected to, questioned, agreed upon, again discussed, and finally confirmed.
3. Estimate the whole thing and confirm the budget expectation.
4. Design the solution. Conduct several meetings with stakeholders. Create various documents and let stakeholders review them. Confirm and approve the final functional and technical design. 
5. Implement the solution based on the design. This is where you develop the complete end product.
6. Enter the testing phase and execute various kinds of tests. Unit tests, system tests, functional tests, integration tests, performance tests, regression tests, user acceptance tests, and potentially many more (depending on the culture of the company). Document everything and let the stakeholders review and approve it.
7. Deploy the solution to the production environment. This is where the target users start using the final and complete product.
8. Schedule some support phase during which the development team corrects potential bugs of the solution. 

This whole process might take a few months to a few years. As you can predict, users will see the results only at the end of that process. So, after long waiting comes the moment of truth (or failure). 

If something changes during that long time and the end product should look a bit different, that’s a situation you call a change request. The design must be reopened, reworked, and reapproved. It prolongs the whole time schedule by another part. Every change requires a restart of the whole process before.

On the other side, you have a rock-solid phase definition, a fixed budget for each phase, and a fixed time. Even if you have to wait a long to get the first result, if chances for changes along the way are minimal, it can still be a preferable option to go with.

What Does an Agile Look Like?

Now, this is how the project can operate under an Agile setup:

1. Define the business vision of the end product. Roughly but with clear business requirements and expectations of what the product shall fulfill for the users.
2. Create a list of functional Epics and technical Enablers that cover the vision.
3. Do the high-level estimation of the epics and enablers to establish some lean budgeting expectations and timeframe of delivery. Define what Minimum Viable Product (MVP) is and what are the rest of the features forming the final product.
4. Set up a scrum team and schedule the sprints within the timeframe period. Break down the epics into features and stories with the team. Estimate the stories and plan them for the upcoming sprints based on the priority the features and stories have.
5. Work on the stories each sprint. Include all activities in the sprints that is, design, development, test, and deployment. At the end of each sprint, present the increment outcome to the users and seek feedback.
6. If something goes off the track or has a desired outcome, change the features or stories to adapt to the updated reality. Reflect it immediately from the next sprints on.
7. Right after the scope of MVP is completed, release it to the end users to gather fast production feedback.
8. Continue developing the rest of the features by reflecting the outcomes of the user’s feedback from the already released part of the system.

This is just a quick summary, but the difference to the waterfall is already clear. Fast feedback, adaptation, reflection of current needs changing in time, first valuable product delivered in shortest possible time. Those all are properties you have no chance to get in a waterfall project.

Agile vs. Waterfall

A project can’t be successful without a suitable project management methodology in place. This means defining processes, metrics, evaluations, and general ways of working for the teams forming the project.

The teams need to know which rules to follow, what will define the milestones, when to reach them, and how to measure and evaluate the success. At the same time, stakeholders need to understand what to expect from the project and when they will be able to see the first results of the work.

With a little bit of generalization, we can say that projects operating in cloud environments are significantly more likely to incline to agile methodologies (or they should, at least). Projects working with on-premise infrastructures still very often prefer waterfall processes. This comes as a natural conclusion.

The cloud environment is built from the ground to suit the ever-changing environment. It adapts as fast as possible (with various “elastic” services) to the new reality. The on-premise environment is often predefined at the beginning. It is hard to change it over time, so the teams work with deterministic variables for the whole duration of the project.

Summary of the Agile vs. Waterfall approach.

This choice will, however, define several aspects of the project execution properties.

#1. Project Requirements and Change Management

One of the most important aspects defining the choice is how the user’s requirements will be handled. And also, what is the process if a change to the already agreed requirements is needed later on?

With a waterfall project, all requirements are defined and signed off by stakeholders at the beginning; if any change to that state arises, the project treats it as a Change Request. It has to be again validated, agreed and confirmed.

Any work already done up to that moment must be revisited and started again. Costs need to be re-adjusted (as it is additional work not covered by the original contract). In the worst-case scenario, even the whole project timeline needs to be prolonged.

With an agile setup, the changes are welcome. You treat the changes as a standard day-to-day business. You agree with stakeholders (probably as an outcome of the latest sprint demo) that changes are crucial in order to maintain the vision of the project. Then, you schedule those changes immediately for the next sprints.

The previous content will change with that, and the teams continue to work with new requirements from that day on. There is no loss in time or costs. You simply adapt to the new reality immediately and replace the original plan with the new one. There is no need for special Change Request management at all. It’s all part of sprint planning initiatives.

#2. Project Planning and Scope

As you might expect, the waterfall project sets and fixes all the scope at the beginning. You generate the project plan around this scope. Then, you divide the project duration into specific phases (typically analysis, design, development, test, deployment, support, and maintenance) and fix the teams and resources around those phases. For the majority of the project timeline, your main goal is to stick with this original plan in terms of costs and timing as much as possible.

An agile project has a vision of the final product instead of a hard plan. The end state is clear, but the path to reach that state is free to change. Also, the project timeline is still defined and agreed upon based on a preliminary estimation of the demand and the capacity load experience for the teams working on the project. The plan does not have separate phases. Instead, each sprint is a small phase itself that contains all the activities the team needs to successfully release the increment product.

In summary, the waterfall project treats the changes as a complication to solve (and an opportunity for the vendors to acquire additional money). In contrast, the agile project treats the change as a business as usual with no additional consequences (other than a better suitable end product).

#3. Project Progress Tracking

The waterfall project tracks the progress of the plan within the phases of the project. The design phase can’t start before the analysis phase is complete, testing can’t start before the whole build is complete, and so on.

If some of the phases run into a delay, it will affect the progress of the remaining phases of the project. That’s why it is important to check on the activities inside each phase and ensure they progress linearly during the time. Otherwise, you increase the risk of delaying that particular phase and, consequently, the whole project.

The agile project tracks the progress, mainly with demo sessions happening at the end of each sprint. The workable product is the primary measure of progress. Naturally, you want to ensure each sprint finishes with complete sprint content. No or only minimum stories are carried over to the next sprints.

Ultimately, it is much easier to see the overall progress of the project if you can directly try out the current product increment and get back to the team with very concrete feedback right away.

#4. Team Collaboration

This is about strictly separate activities of waterfall versus continual collaboration with all parties of an agile team.

A waterfall project usually has different people working in different phases of the project. They might overflow each other to some extent, but they are still different groups of people. Almost the silos, you could say.

The agile team definition lies in communication and value. It shall also be a cross-functional team capable of executing all product lifecycle activities. Silos of the teams is something you don’t want to exist. Constant back-and-forth communication between the team and external stakeholders is a basic definition of a successful agile project.

#5. Risk Management

Obviously, you want to have a process for tracking any risks, issues, or any kind of obstacles the project might bring during its timeline.

In the case of a waterfall project, this translates into status tracking of the current phase of the project. The standard semaphore-like status reporting will show green (everything is OK and in line with the plan), yellow (some important problems are in place, but there is still a clear understanding of how to resolve them), or red (meaning the project has serious troubles that can impact the original timelines or budget).

The agile project is also different here. You don’t really track the progress toward the goal. Rather, you solve dependencies between different teams and types of activities. The goal is to ensure no team is waiting for another team with the progress activities.

Naturally, risks might appear, but then the solution must change the plan going forward so that the risk disappears rather than figuring out the solution to the risk while still preserving the original plan.

In other words, an agile setup of the project uses every possible way to change the plan to not face the projected risks, which means risk management is proactive. In the case of a waterfall project, you respond to the risks retrospectively and try to resolve them in the shortest possible time while sticking to the original plan.

#6. Implementation Framework

Implementation tactic for waterfall projects is obviously less problematic than for agile projects. Usually, the waterfall methodology is the status quo people have already practiced for many years.

On the other hand, projects require agile transformation practices to change their habits, mindset, and ways of working. It is a difficult and often also quite long-lasting process. Companies are investing significant amounts of time and resources to teach people to adapt to agile processes.

The benefits in the form of fast adaptation to the changing needs of the customer are significant, but changing people’s mindset and overall working environment is the most difficult part.

Most of the time, it is also the only way to remain competent in the market, so the tradeoffs are rewarded with great success for those who succeed.

Final Words

Let’s state it clearly. Unless you have a very conservative customer with no big motivation to deliver results to the production fast (for whatever reasons they might have for that), your best bet is to start modeling the agile teams right from the beginning. This is literally a no-brainer in today’s world. This is true even in the case of traditional on-premise systems setup. Especially if the team is new or starting from scratch with original people, it still makes sense to transform the processes to align with agile methodologies.

Having said that, I still see projects where people just refuse to follow this kind of agile process or any other setup but strictly phase-specific organization of work. They follow the usual path of contracting the work for a specific time and budget. Then, they expect the project will follow this setup without deviations to the plan and money (with various outcomes, usually not good ones).

This is a decision they have the right to make, but ultimately, with such a decision, they also decide to stay in the past. It might work for them for some time to come, but it’s only a matter of time till it won’t work anymore.

Next, check out the detailed article on the Agile testing life cycle.