Waterfall vs Agile: why do we use them?

The Standish Group Chaos Study shows that Agile projects are 3X more likely to succeed than Waterfall projects, and Waterfall projects are 2X more likely to fail:

“We find some really interesting data when we break “agile versus non-agile” by size.
Large agile projects succeed at twice the rate of non-agile projects and fail half as often.
Medium-agile projects don’t fare much better, 31% versus only 19% for non-agile ones”

At the same time, Standish Group Chaos Study says that the prosperity of Agile will end shortly. So should we stick to Agile or use time-tested Waterfall?

The thing is, there is no winner in the Agile vs. Waterfall fight. There are too many nuances, especially regarding budgets, timelines, and the features you need to release. They are what matters when you’re to pick the most suitable methodology. 

Here comes a spoiler: both methods have tons of benefits, drawbacks, fans, and haters.

Haters gonna hate, and we gonna analyze these two right now.

What is Waterfall Software Development or Development Step by step, bit by bit

Waterfall methodology is linear, follows a pre-agreed sequence of stages, and has a set of deliverables.

For example, there is Carl, and he wants a big, cool website.

Carl agrees with the development company on what should be created on the dev stage, design stage, and what the final product looks like. That’s it; he goes about his business while a team of hard-working programmers, designers, testers, and a whole bunch of other important people does his project.

As a result, when the deadline approaches, he gets his big, cool site — just what Carl ordered. 

In Waterfall, it is very important to understand at the very beginning how the product should look like and plan each step of its development. Thanks to this feature, Carl from the example above looks at his new perfectly-matching-his-desires website.

And if Carl wanted to add a new feature to the project… Well, he would have to wait until the end of the project. After all, every step is already planned.

Following the Waterfall model, the team moves from one stage to another, and there is no turning back. There is only one path, it is a one-way street.

Waterfall works perfectly for websites and small projects, with detailed specifications
and strictly planned workflow. 

Zgraya devs use Waterfall for projects in which our client is 100% sure about the features they want to see. If they have already checked the effectiveness of their decisions, imagined the result, and fell in love with it… Then we apply Waterfall and stick to the plan.

Waterfall or not Waterfall: that is the question

Somewhere on the web user zwitter-ion compared Waterfall and Agile methodologies with the process of creating a music player. We will alter the idea a little bit and show the processes of creating a wow-website for Carl, a more familiar scenario for us.

Let`s see how the advantages of Waterfall apply to it. 

• Transparency. The rule is simple: there are several stages of work (discovery, design, coding, testing, and so on), all of them are designed and documented, all of them follow each other.

So Carl knows what happens at each stage of a project; he agreed on terms and features at the very beginning.

There is a fixed plan for his website: the team works on design, passes it to coding guys, the ready page with design is tested… Everything goes according to plan. There is no need for him to have constant catch-ups or updates with the team.

• Strict instructions and rules. Plans, steps, and processes aren’t empty promises. They are approved in advance, fixed in documents, and do not raise questions. Waterfall approach stands for an unyielding system and stable workflow: what’s done is done, what should be done — will be done. Rigid, strict, predictable — it’s all Waterfall.

Hypothetically, Carl may ask to change the project’s scope if he decides to create a mobile app instead of a website. Hypothetically, we will agree and create another scope, adding additional expenses. But it is only hypothetically.

• Certainty in terms and budget. The cost and duration of the project are calculated and approved in advance. They are not to be changed during the work.

Carl may sleep calmly; Waterfall is all about not getting unexpected checks for “unforeseen expenses.”

But don’t forget about the disadvantages of Waterfall, there are some pain points to consider. 

• Lack of flexibility. Well, even in an ideal world, it is impossible to foresee all the problems in advance. With programming, it is similar. A Waterfall project cannot adapt on the go to new realities and demands. 

So Carl gets exactly the thing he approved on the initial stage. If he initially took into account all his wishes, told the team about them, and agreed on a perfect result, in the end, he would get what he dreamed of. And if Carl, as the project progresses, wants to change the design from Scandinavian minimalism to alien baroque (by no means throwing an idea at you)…

Well, nobody will be happy.

• Limited customer involvement. A customer can only see the result at the end of the project and no intermediate updates — but not with us, we like to communicate with the client and always show the halfway option.

Carl may like that the team does not pursue him or arrange calls to agree on the smallest features. But such limited involvement deprives Carl of understanding what the project looks like before the deadline. 

• No instant user testing. We cannot check how users will react to features. It means that users will see only the final result, with all the features planned initially. Waterfall does not allow users to test the product and adapt it to new demands along the way.

For example, if Carl could try certain features of his site and receive feedback from users, he would see that gen Z users are asking to add authorization through TikTok. This is the generation of the 21st century, what else did Carl expect.

What is Agile Software Development or The Flexible Development

Almost three out of four all-size companies worldwide use Agile software development model.  IBM, Microsoft, AT&T, Lego, and PlayStation all play by Agile rules and succeed.

Agile is the best choice when we face complex business tasks or when the client does not know their specific needs and their project’s infrastructure in detail. 

For example, Carl has an idea for an app. A concept and nothing more. Carl does not yet know if he needs integration with Salesforce or Google Maps. He does not know what programming language this application needs. He does not have a complete list of features, and he doesn’t have the money for a complete Facebook app killer.

Yet.

In such cases, we create a custom solution that will still be developed and modified during our work. 

When using Agile, we split the development process into sprints, 1-4-weeks-long iterations with particular goals to be delivered by the end of each. In fact, when the sprint ends, we have a cool working feature. One of the dozens needed. 

If Carl tested the ready feature on the user and saw that they are fine with authorization through TikTok, he gets the desired result.

With Agile, we take a huge project, break it into small parts, get a result, and present this result to the client during the demo. The client sees progress, we get feedback and go on with another sprint.

Easy breezy!

Agile or not Agile: what to expect

Speaking of the advantages of Agile, it is easy to see why IBM, Microsoft, AT&T, Lego, and Play Station stick to this methodology.

• Instant work on bugs. The latter a wrong path is discovered, the harder it is to fix it. Using Agile, teams can spot errors, find more efficient approaches, and have a feature done by the end of a sprint.

The main thing that Carl likes about Agile is that each feature is developed separately and as a result of each demo, each release, he gets a mini part of a huge project. This is the working part, which can already be tested on the user.

Speaking of bugs and Agile. Our devs divide bugs into three groups:

1. If the bug is not very critical, then it is transferred to the next iteration;
2. If the bug is critical, then it will be solved immediately;
3. If the bug is VERY critical, then it is fixed immediately with a hotfix.
   

• High customer involvement. The best part of Agile methodology is that customers can participate in the development process, alter the scope, and add new features for future releases. The final project is never a surprise full of useless features. 

Thanks to Agile, Carl will be able to communicate with developers, designers, create joint new ideas, and see them brought to life.

The reason we love Agile is because it allows you to see flaws in a complex system and immediately fix them.

• Full flexibility. We love Agile because all adjustments can be made on the fly. If your project depends on changes in the market, moon phase, or basically any factor, you can always get new features right in the next sprints. 

Although Agile looks like the best option, there are a couple of disadvantages that can put Carl or any other client off.

• Increased requirements for customers. Close collaboration and active customer participation are a must. There is no such thing as “I just paid money and got my thing ready in several months.” Most of the time, it is “Well, I had a call with the team 3 days ago, now it’s time to have another catch up”. 

If Carl is not ready to participate in the process, — any reason for that  — perhaps it’s better to move with old but gold Waterfall. 

• No fixed deadline and price. In the Agile model, only sprints have maximum accuracy: you can see exactly how much it will take to develop certain features. Dates and estimates for the entire project can only be approximate. Each new sprint can have unplanned features offered by a customer, increasing duration and cost.  

There are different frameworks used to apply Agile principles. In short, Agile is a philosophy, a family of flexible approaches to software development. Scrum, Kanban, XP are such approaches.

• Scrum is the framework used by our team, so we can define its main pros and cons based on our experience.

Scrum requires the full involvement of everyone, both the team and the customer. It is a super-powerful weapon against useless actions and features

We can build work without a specific step-by-step plan at the initial stage.

Let’s say, we made a feature. Carl saw the first user tests and decided to redo the interface because it turned out that the original interface he wanted was complicated and intimidating for users. No worries, Carl, it happens. And Scrum is an ideal option for projects which depend on user feedback. 

Unlike Waterfall, the process in Scrum:

• Easily adapts to dynamically changing requirements, 
• Allows testing individual features on the user,
• Makes it possible to adapt a work plan basing on user feedback.

When to use Waterfall vs. Agile

Surprisingly or not, both Waterfall and Agile are effective methodologies that, however, cannot be suitable for every project.

Choosing the right model to stick may affect the entire project and lead to incredible success or complete failure. For example, because Waterfall is clumsy and isn’t suitable for a startup, Agile requires high customer involvement and has no fixed deadline.

Now that’s we’ve escalated the situation enough, let’s compare Waterfall and Agile side-by-side.

How To Choose the Right Methodology for Your Project

To be honest, there is no one right and perfectly suitable methodology that will work with all projects. 

Zgraya’s Head of Product Development, Anton Fedulov, says (and we prefer to believe him) that both Agile and Waterfall are very cool strategies but not universal and definitely not suitable for every project:

“The choice of methodology depends on the project’s specifics, business ideas,
and various aspects such as risk, time, and involvement of stakeholders.
We, as experienced guys, help choose the correct methodology, depending on
the criteria and the wishes of the client.” 

At Zgraya, we always pay a lot of attention to the choice of methodology. For start-ups, progressive projects that will 100% change and evolve during the dev process, we choose Agile.

We use Waterfall for large projects that already have a clear plan and idea, and the client is set to get a certain result at a certain time for a certain amount of money.

Feel free to read our article on the product dev process at Zgraya.

If you have a project on your mind and those methodologies frighten you, feel free to ask us any questions — we are always here for you, explaining hard stuff in the simplest terms.