So, what’s the difference between Agile and Waterfall, and which of the two approaches is better for your project?

Let’s find out!

Note: this is the second article in our series on software engineering methodologies. Check out part one if you want to learn more about other models.

Waterfall model

At the most basic level, there are 2 types of software development methodologies: linear and cyclical.

Waterfall is one of the oldest approaches to development. It comes from the construction industry where it’s typical to build houses one step at a time, from laying foundations to raising the roof. The whole building is commissioned in one go and workers rarely have to go back to rework the foundation once they build the walls.

Waterfall follows the same principle. It divides the development process into 6 distinct phases:

1. Discovery – the team gathers a complete list of requirements for the whole project.
2. Design – software architects decide how to build the application and how it’s going to work. Waterfall projects require large upfront planning up to a very low level and extensive documentation.
3. Coding – developers implement the design according to the requirements.
4. Testing – QA engineers check the whole codebase for bugs or inconsistencies.
5. Deployment – developers integrate various pieces of the final product and organize a demo for stakeholders.
6. Maintenance – the team provides support and fixes bugs discovered by users.

As there’s no going back, each phase must be 100% complete before the team can proceed to the next stage. Each phase has a clear list of deliverables and review criteria which simplifies project management.

The whole product is designed, built, and tested in one go. All business value is delivered at the end of the project.

Heavy upfront planning and fixed scope of work makes Waterfall well suited for fixed-price contracts.

In fact, most of our first-time clients prefer to start a new project with a fixed budget to minimize the risks that come from outsourcing.

Take, for example, Innmeldt, one of the top pension and insurance consultancies in Norway.

About four years ago, they decided to move their business online.

Together with MindK, they’ve designed a custom SaaS platform that would, among other things, automate pension and insurance calculations used in the consultancy process.

The company had a fixed budget and could wait a few months for a complete product as they had a successful offline business.

What’s more, the extremely complex formulas used for insurance and pension calculations are provided by the Norwegian government, so they were unlikely to change in the near future.

As a result, we signed a fixed-cost contract, planned half a year’s worth of development, and gathered future-proof requirements for the whole project.

An ideal mix for the Waterfall model.

In about six months, our client received a fully-functioning product. It was finished on time and within the established budget. The Waterfall model was fantastic in this specific case. Yet, it has some apparent downsides that earned it a bad reputation.

Traditionally, the client sees the new system the first time only at the very end of development. It’s impossible to predict all the technical difficulties that will arise during the development and how the project might mutate over the time.

That’s why Waterfall requires careful management of expectations and transparency towards the client.

What’s more, the approach is quite bad at handling high uncertainty that is inherent to long-term plans.

A year ago nobody expected a pandemic, yet here we are, working from home and hoping for a vaccine to save us all.

In theory, Waterfall works really well for distributed teams and the world that’s forced to work from home. As everything is planned ahead, everybody on the team can understand their tasks and work without being distracted by online meetings.

In reality, things change all the time.

Customers adjust their requirements, markets undergo rapid shifts, competitors release new products, and plans become outdated as soon as you put them on paper.

We have to constantly adapt to the changing reality and be quick about it.
If something goes wrong in a Waterfall project, it can be very hard to coordinate everyone online. The project manager has to discuss the possible changes with a ton of stakeholders and review a heap of documentation to understand how they will affect the whole system.

This is why Waterfall projects require careful management of expectations and extensive risk mitigations.

We found out that regular demos can help us manage client expectations. By showing off small parts of the product, we can start testing much earlier and discover bugs while they’re easier to fix. And daily team meetings can help us keep everyone in the loop and discover any unexpected issues.

Although not perfect, this iterative Waterfall model is highly useful in certain situations (see the table below).

Waterfall pros:

+ Easy to understand and manage, even for beginners.

+ Each phase has a clear set of deliverables simplifying the project management

+ Ideal for projects with clear-cut requirements and fixed budgets.

+ Isn’t as sensitive to changes in team composition as Agile software methods.

+ Fixed scope of work allows for a more precise budgeting.

+ Doesn’t require much involvement from the client and intended users (apart from the discovery phase).

Waterfall cons:

– Ill suited for lengthy projects as the product can mutate over time deviating from the client’s expectations.

– Very inflexible and bad at handling changing requirements.

– Slow time to market.

– Higher risk of project failure (21% vs 8% for Agile).

– Needs complete requirements to start the project. The discovery phase can take a lot of time.

Agile development

For a long time, Waterfall was the default approach to development. You can compare it to baking a beautiful wedding cake, one layer at a time.

Such a cake takes a lot of time to complete and is basically worthless until you make all the layers and decorate it with a bride-and-groom figurine.

Similarly, all software consists of several layers that are mostly invisible to customers. Just like with our cake analogy, only complete features are of any value to end-users.

The Waterfall approach makes sense when the client can wait to receive the complete product. In most cases, however, you’d want to release your product as quickly as possible to give users the taste of what’s to come and benefit from their feedback.

Instead of baking the whole cake in one go, Agile methodology divides the system into several vertical slices, each a complete feature that has some value to end-users.

It then selects the most tasty or high-risk slices and starts the development.

The team works in short iterations, each lasting 1-4 weeks. During this time, they design, build, and test complete features that can be released to the public and improved based on feedback..

This allows you to quickly validate your assumptions about the market in real conditions.

The cycle of improvements can continue until the product satisfies all requirements and further iterations add no significant value.

As high-risk features can be delivered first, this approach decreases the risk of project failure and cuts the time to market. This made agile the go-to approach for many startups and companies outside the industry like Elon Musk’s SpaceX.

Its biggest strength lies in the ability to quickly adapt to the changing requirements.

In one of our projects, we had to build a social networking app for a German startup. By the time our development team had to start working on the project, the founders were still unsure about the direction of their app. What’s more, they wanted to use some of the newborn tech in social networking and visualization increasing the uncertainty about the project.

As time to market was another critical consideration, we chose Agile as our development methodology.

For the first two iterations, the team used an incredibly flexible Kanban framework that allowed the founders to gather more requirements without pausing the development process. After a month of development, we switched to a more structured Scrum framework that provides more control over the development process.

As a result, we released a working Minimum Viable Product in under 3 months allowing the founders to launch a new funding round.

Read more: what’s the difference between Scrum and Kanban?

Agile pros:

+ Faster time-to-market and return on investments.

+ Early feedback helps to improve the product.

+ Reduced risks due to continuous feedback

+ Increased transparency due to a deep involvement of the client

+ Incremental testing helps in finding bugs earlier and fixing them at a lower cost

+ Allows to react quickly to any changes in requirements and make adjustments at a lower cost

+ Allows the team to be more creative in their approach to solving technical problems.

Agile cons:

– Minimized documentation can cause problems later on (e.g. when onboarding new team members)

– Requires careful change management to avoid scope creep.

– The total cost of the project is hard to predict.

– Highly reliant on the client’s involvement.

– Harder to manage and practice well compared to the Waterfall model.

– Doesn’t suit fixed-price projects.

Conclusions

I hope this once and for all settles the debate of Waterfall vs Agile.
Both approaches have their benefits and drawbacks. Both shine in different situations.

Waterfall provides predictability that’s attractive to many enterprises and first-time outsourcing clients.

Agile better suits dynamic startups and unpredictable markets.

If you still have doubts about which of the two software methodologies better suit your project, check out the cheat sheet below.

When to use: Agile vs Waterfall