The Waterfall vs Agile Methodology: Choosing the Right Approach to Software Development

When it comes to a development strategy for your project, choosing a solid approach is almost as important as finding a capable and reliable team. Most newcomers are perplexed with a question of what to choose: Waterfall or Agile methodology? Let’s dwell on the pros and cons of both.

That Is Waterfall

The Waterfall model was inherited from the old-school manufacturing and non-IT development methodologies, back in the early 1980s. It presumes a strictly formalized and documented approach. With each step, iteration and features are fully described and planned in advance — actually, before beginning working on a project, or at its initial stage. Comprehensive documentation is supposed to instill a safe feeling of confidence in the customer, with everything being thoroughly thought of in advance, designs approved, user flows fully described, timelines and budgets set, etc.

In reality, though, this is hardly feasible. In particular, if your project is a start-up and you are flexible and open to adding new features, functionalities, tweaks, and improvements right when a brilliant idea comes to your mind, without waiting until everything will be fully developed as per the old, outdated plan. And this is where Agile comes to help you.

Agile Methodology

And what is Agile? Agile development methodology is often underestimated and frowned upon by newcomers as it seems rather chaotic and uncertain for people who never worked in it. Paradoxically, it is the best option for building start-ups, especially if a customer has little or no experience in outsourcing software development.

Even though everything may seem comprehensively described, during the development process, many questions will arise that will require changes to the initial design or plans, like:

• adding new pages to a website;
• changing the size or arrangement of elements on a screen;
• introducing new user roles;
• implementing support for additional payment systems;
• supporting new versions of operating systems or browsers (can you predict when a new Android or iOS version will be released, and what features will become deprecated and unsupported?);
• switching plugins, as they become outdated or do not fit your needs; etc.

Any of these may become quite a problem in Waterfall, while easily tackled in Agile. With their cornerstone of incremental and iterative development, Agile methodology focus on short-term sprints rather than long-term deadlines. Sprints — usually a week or two weeks long — allow for new changes or ideas be put in a backlog and brought to development pretty quickly, as compared with fix scope Waterfall procedures. One doesn’t want to wait until the entire scope is fully developed, tested and delivered if they have changed their mind and want changes to be done right now. And with Agile methodology, one doesn’t have to wait.

Let’s take a close look at a real life example to illustrate the difference in approaches and the actual result. For instance, we have a project for software where users can buy products. And, in the middle of the project development, here comes an idea.

Waterfall Methodology Flow:

• We have only registration by email flow. Perhaps we should add login via Facebook option as well?
• Sounds good, but Facebook’s API does not allow fetching users’ street addresses, and we need those for delivery companies.
• Then, let’s redesign the purchase flow to ask each user’s street address to complete an order.
• Should we then save this entered address to a user’s profile for further purchases, or ask users every time?
• Let’s design a pop-up that will ask if a user wants to save this address as default.
• For those logged in via Facebook, there should be an option to invite their Facebook friends to our store, and an enticement would be a 5% discount for each.
• Let’s design an option to invite Facebook friends, to check if an invited friend has made a purchase, implement a discounting system and carry out the necessary changes to the accounting reports with the discounted prices included.

Agile Methodology Flow:

• We only have the registration by email flow. Perhaps we should add login via Facebook option too?
• Sounds good. Let’s put that in a backlog for the next sprint.

A week passes.

It turns out that Facebook’s API does not allow fetching addresses. However, that’s not important, as after having this feature implemented, we can see that only 3% of users are logged in via Facebook, while the other 97% still prefer email-based registration. So, let’s disable the Facebook login and instead focus on some other interesting ideas to implement.

In Waterfall, it would take many work-hours (and hence much money) to plan and describe all the details, estimate, sign contracts with fix scope, design, develop, accept — and only then to see that this feature is not popular among users and hence useless.

While in Agile methodology, you don’t need to invest that much money, effort and time, and you get the result literally in a week or two.

That being said, I don’t want to sound derogatory about Waterfall, as it is still a good methodology widely used in IT. However, in my opinion, it better fits automotive manufacturers rather than software development, where each project is unique, and each customer has their own way.

The primary reason why many customers still opt for Waterfall when signing a software development contract is the lack of trust in a supplier, and hence the desire to be protected from risks. That is especially true if you are working with a supplier for the first time, and have no idea of their capabilities or expertise. But if you would do a start-up with good friends whom you trust, you would definitely go Agile, as it is flexible in making decisions and allows the job to be done in exactly as much time as it requires — not more, not less.

According to my experience, many Agile projects were actually launched as MVPs earlier than they would be with a Waterfall approach, especially given the saved time for writing and agreeing on comprehensive specifications, which sometimes take about ⅓ of all the project development.

So, in a nutshell, Agile helps get a project to live quicker with more improvements and less costs. After all, it’s all about your launch, isn’t it?