Agile vs. waterfall - what’s better for my business?

For many years, there was one method for developing software that dominated the IT market. It was the waterfall methodology to software development projects. Then, more than 15 years ago, a new approach entered the scene and quickly grew into a leader. The agile methodology of building software grew out of the Agile Manifesto published by a group of software engineers in 2001.

The Agile Manifesto contained twelve principles and a handful of values that inspired development teams to come up with different methods of software development such as Scrum or Kanban.

Today, the agile methodology is no longer exclusive to software development. business teams in departments such as sales, marketing, HR, and finance use agile techniques to manage their projects. The most widespread project management tools on the market include agile-ready options as well.

The waterfall approach grew out of fashion and is today used in projects where specific conditions apply.

Still, if you're looking to build a digital product, it's a good idea to enter the negotiations with the development team with full awareness of what the process of building software looks like.

Here's everything you need to know about waterfall and agile to make an informed decision when choosing the solution for your project.

Waterfall - what is that?

The waterfall methodology is a project management approach where the software development process is structured and sequenced. It usually consists of 8 phases – conception, initiation, analysis, design, coding, testing, implementation, and maintenance. The project team can proceed to the next phase in the sequence only after completing the preceding step.

Waterfall modeling is based on a step-by-step, continuous process. That's why once a step is completed, it's really difficult to go back to a previous step and make changes to it. And that can happen when, for example, a new market trend arises, or we learn something new about the target audience of our product.

Also, waterfall doesn't not support for applying changes, so the project plan needs to be extensive and detailed right from the start. Project managers need to make sure that the development team follows that plan carefully.

When talking about the advantages of the waterfall model, we can't fail to mention this: the process is simple. Waterfall is easy to understand for everyone, including project stakeholders who don't have any technical knowledge such as company owners or shareholders.

Additionally, the waterfall approach means that clients have an idea of what to expect in terms of the project's size, costs, and timeline. Another benefit is the meticulous record-keeping and detailed documentation that are part of this traditional methodology. They might be come in handy for teams that want to apply any improvements in the future.

Dangers of waterfall

However, the waterfall approach comes with its risks:

• The fundamental one is the danger of exceeding the time and budget allocated to the project. The process of developing software is complicated, and it's impossible to plan every single of its steps in advance. Also, unexpected problems may appear anytime, and the time might have to change their direction quickly.
• Another risk that comes with the waterfall model is that initial assumptions or requirements might turn out to be incomplete or faulty. For example, integrations with third-party software can cause developers a lot of trouble. After all, they have no control over such external services. For example, you might realize that the documentation is incomplete or contains errors that will have a substantial impact on your project. Or what if the third-party API itself doesn't provide desired functionalities? Or worse, what if that API has changed significantly since you prepared your analysis and estimation?
• Waterfall projects don't support changes - and that's a massive problem in today's economy where customer trends are evolving at an increasing pace. Developers need a formalized procedure before taking action. Every modification consumes a lot of resources, and these could otherwise be spent on delivering the agreed scope of the project.
• Teams that follow the waterfall model leave testing to the end of a project. It means that bugs are discovered really late in the process, and the cost of fixing them is much higher. At some point, the budget may be fully used, but there is still a multitude of tasks left to be delivered under the terms of the original agreement. The client may be pushing to implement all the desired functionalities. At the same time, the development team may want to finish as soon as possible, without generating more losses. This causes a risk of the lower code quality and poor team morale.

As software development becomes increasingly complicated and the demands of organizations investing in digital products shifted, it turned out that development teams needed to find a new way of building software. The waterfall methodology simply wasn't enough.

And that's when the agile methodology of software development came to rescue.

The phenomenon of Agile

Agile emerged as the solution for addressing the limitations of the traditional waterfall method. Its incremental approach changed the way of handling IT projects forever.

Agile methodologies emerged from the 2001 Agile Manifesto that outlined twelve principles for producing software that was change-ready, innovative, and bug-free.

Here are the principles included in the Agile Manifesto:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

1. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
2. Deliver working software frequently, from a couple of weeks to a couple of months, with a
3. preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The Manifesto also outlined the key agile values, as follows:

Individuals and interactions over processes and tools,

Working software over comprehensive documentation,

Customer collaboration over contract negotiation,

Responding to change over following a plan.

Benefits of agile 

The agile approach offers a greater ROI and value for money because of tasks prioritization and incremental delivery. It helps teams to focus on features that bring the most value to users first.

What's more, agile allows to test code more frequently - leading to early problem discovery that enables developers to deliver a higher quality product.

Also, the agile process offers a much better support for changes. At the end of each iteration, new the team gains new knowledge and reviews all the work completed in one iteration. Agile provides development teams with many opportunities for updating the project plan. That's much more reasonable and practical considering the reality of the market which is always changing due to new trends and evolving customer demands.

Agile methods: Kanban vs. Scrum

The Agile Manifesto offered a set of principles and values, but it didn't say how they were supposed to be implemented by agile development teams. Still, teams that wanted to change how they developed software managed to come up with formalized techniques inspired by the Agile Manifesto. Here are two most popular agile project management methods.

Scrum

The main characteristic of Scrum is that the work is organized into sprints – short iterations that usually last two weeks. Most of the time, sprints consist of planning, coding, and summarizing the done. Doesn't it sound like a tiny waterfall project? At the end of each sprint, the team tests the project and deploys it. This is possible because the idea of Scrum is that developers create a working piece of software within each sprint.

Scrum comes with a set of ceremonies:

Sprint planning - an initial meeting where the team plans the work for the following two weeks, organizing it into separate tasks that land in the backlog, as per the project requirements.

Standup meetings - the team meets every day to discuss the work being developed to streamline the process and remove roadblocks.

Sprint retrospective - as the team finishes the sprint, it participates in a meeting where the focus is on what went well and wrong during the sprint. It's an opportunity for the team to improve its practices and grow.

Kanban

Another popular project management method that grew out of agile is Kanban. Kanban is based on the creation of boards, which can be either physical or digital. Every board is made up of columns that refer to the different statuses a task may assume in the project's workflow. For example, the simplest Kanban board includes columns labeled as 'To do,' 'In progress,' and 'Done.'

The idea is that every task is represented as a single card, moved by the responsible team member from one column to another. That's how the rest of the team can know who is working on what and how far they are in the process. As a methodology, agile is here to boost the team transparency and help teams to organize their work.

Want to learn more? Read this: Agile software development: 7 best practices

The limitations of agile

However, the agile methodology comes with some key disadvantages.

Without a definite plan, the final product can turn out to be completely different from what was expected in the beginning. That's not necessarily bad, because the client's needs can change as well - based on the market, customer feedback, or the project's progress.

Agile doesn't leave a lot of time for developing documentation. Since it's less detailed, the onboarding process of new team members may be hard and take more time.

When betting on agile, it's impossible to predict the time and cost of a project with perfect accuracy. They are usually specified as a range of values. That might look risky, but an experienced development team has many strategies for coming up with realistic estimations.

Read this if you want to learn more about what agile collaborations look like: Outsourcing best practices: How to manage agile collaborations with challenging clients

Agile vs. waterfall: which approach is best for my project?

The only certain thing in software development projects is change, especially in the IT industry. The world is transforming at an increasing pace, on a scale that has never been seen before. That means software development needs to accommodate changes and become more flexible.

While both waterfall and agile methodologies solve complex issues in different ways, it's the agile approach that supports all those changes in a business-focused and functional way. You might be experiencing the agile vs. waterfall dilemma now. If your project is predictable and small, it's a good candidate for a waterfall project. Otherwise, you can trust an experienced software development agency to create the best possible solution using the agile methodology waterfall could never match.

Are you looking for a development team that knows how to use agile efficiently? Get in touch with us; we have many years of experience in delivering products through agile development.