Skip to main content

When to Use Waterfall vs. Agile

Image
By

 We compare the benefits and drawbacks of using two well-known software development methodologies, Waterfall and Agile, and lay out when it might be more suitable to use one over the other – or combine practices of both – for your product initiative.



When developing a new software product, your team will need to navigate which development methodology is right for your initiative. In the world of managing software development projects, the topic of Agile vs Waterfall is widely debated. Many thought leaders and Agile enthusiasts in the industry have argued Waterfall is dead, however, traditional organizational environments and processes have led to it still being widely used today. A 2017 report from the Project Management Institute shows that 51% of the organizations surveyed use Waterfall either often or always.

The reality is, each software development project poses its own unique challenges and requirements. It’s not a matter of deciding which development methodology is “the best” in general, but rather which is most suitable for your product’s development so that your team can adopt the appropriate tools, technologies and processes that will result in successful product delivery.

To help guide your product team in evaluating when to use Waterfall vs Agile software development, we’ll walk you through the advantages and disadvantages of these two popular methodologies and the circumstances where it may be more suitable to use one over the other…or even combine the two!

The Waterfall Development Methodology

Waterfall development methodology, as its name suggests, is a stepped software development approach that has a prescribed set of activities and dependencies. The key characteristic of the Waterfall development methodology is that each step in the software development process must be approved by the project stakeholders before the team is allowed to move to the next step, hence the term ‘waterfall’.

The Waterfall development process generally looks something like this:

  1. Gather and document all requirements up front
  2. Design
  3. Development
  4. Testing
  5. Deployment/Delivery

Your end result is one large final outcome/product.

Pros of a Waterfall Methodology

There are reasons why product teams continue to use the Waterfall development methodology, even with the recent rise of Agile.

  1. It’s a well-defined methodology that has been used in all business verticals. It’s a tried and true methodology that is pretty straightforward and expectations are clear.
  2. The methodology defines what you are building to a very detailed level at the beginning of the process. This makes setting deliverable dates, start/end dates, milestone planning, as well as the team’s ability to track progress much easier.
  3. Developers and testers can focus on writing code and writing test cases. They don’t have to work with stakeholders to determine what the product requirements are.
  4. What the team is going to deliver is more predictable. Because the product requirements are documented and approved prior to the beginning of development, there is a commitment to deliver a specific set of features which makes the final product more predictable.

Cons of a Waterfall Methodology

Although the Waterfall development methodology is structured and straightforward, which is suitable for many product teams, it does have its drawbacks.

    1. Defined requirements leave less room for creativity. Defining the requirements at the onset of a project also inhibits the product owner’s ability to take advantage of the opportunities they might see during the development process to adjust the requirements and deliver a better solution.
    2. A waterfall methodology can be costly. Even if the stakeholders are confident that they know exactly what they want, their needs can change or they may not have taken into account an edge case. Defining the requirements in the beginning makes adjusting to changes difficult and expensive. Making changes after everything is built often requires expensive rework.
    3. Requirements can be interpreted differently by different team members. A scenario can exist where different people interpret things in a different way. The relationship between the product owner and the development team can become adversarial when someone’s interpretation of a requirement comes into questions.
    4. Significant effort is expended building documentation and not building product. Requirements must be completely documented and approved before any development can occur.

The Agile Development Methodology

The Agile development methodology takes a collaborative approach to software development where requirements and solutions evolve through iterations. Agile software development relies on self-organizing, cross-functional teams discovering and building a solution using an iterative process to discover and build the solution, as opposed to the traditional Waterfall method that defines and plans the entire project before any development work begins.

The Agile development process generally looks something like this:

  1. Establish a few initial requirements
  2. Design
  3. Develop
  4. Test
  5. Deploy
  6. Evaluate the resulting micro outcome (ie a product feature)
  7. Collect feedback on what’s been presented thus far
  8. Establish new requirements for next sprint based on feedback & repeat the micro outcome cycles until you achieve the final desired product

waterfall vs agile: agile development methodology

Pros of an Agile Methodology

So what does Agile have to offer over more traditional software development methodologies like Waterfall? There must be a compelling reason to use the Agile methodology beyond the notion that it’s the ‘latest and greatest’.

  1. Agile offers flexibility. One of the foundational elements of agile is that the methodology offers a flexible approach to software development. Priorities and requirements can easily be adjusted throughout the project to meet the needs of the stakeholders.
  2. Agile empowers the team. The cross-functional team works as a unit to define, design and build the software product. The team is expected to be self-organized and is not directed by a manager. This allows team members to define and deliver their own work as they see fit. The team is given the responsibility to deliver the project, which empowers them.
  3. Time to market is accelerated. With Agile projects, there is more focus on what needs to be done and less of a focus on planning and documentation. The team’s energy is spent on developing the software product and delivering working software with each iteration or sprint.
  4. Learning is encouraged and embraced. Learning is part of the process – the product is defined as the team iterates. This allows the team to learn, adjust course and improve through the project. Sprint retrospectives, a process fundamental to Agile, are used to gather feedback from the team on how they can improve to deliver software more quickly and with better quality.
  5. More opportunity for creativity exists. Agile works really well when the product vision or features are not well defined. Agile allows product owners to adjust requirements and priorities along the way to take advantage of opportunities and ultimately deliver a better product to all of the project stakeholders.

Cons of an Agile Methodology

Although Agile presents some appealing benefits, it’s not the perfect development methodology for all software product initiatives.

  1. The outcome and timeline are less predictable. Agile uses an iterative approach to software development which allows the product owner the opportunity to be flexible with the project scope and timeline. This means at the project onset the end date and scope may not be known and scope creep is possible.
  2. The customer (product owner) must invest time in the project: A key element of Agile development is the participation of the product owner in the project. The product owner is a member of the agile team and must be prepared to devote the time necessary to ensure the team has the information necessary to build the product.
  3. Documentation is not a deliverable of Agile. In a regulated verticals, such as healthcare, documentation is required. Documentation is not produced during an Agile software development project.
  4. A trust relationship must exist between members of the team. It takes time to build trust amongst team members if delivering a product using an Agile methodology is a first time experience for your organization. Product managers and the rest of the team need to work closely together when working using Agile and so building that trust to deliver is crucial.
  5. Re-work is inevitable with Agile. Things change all the time when developing using an Agile methodology, so expect that code will need to be refactored.

Deciding Between Waterfall and Agile for Your Project

There are a number of factors that should be considered before a methodology is adopted – we’ve summed them up to help you decide which is more suitable for your project.

Requirements and Regulations

Many Initial Product Requirements & Strict Regulatory Requirements: ✅ Waterfall

If your project has strict regulatory requirements and there is little room to make changes, this will push you toward a Waterfall software development methodology.

Few Initial Product & Regulatory Requirements: ✅ Agile

If your project has few initial requirements and doesn’t need to meet strict regulations, an Agile development methodology will result in project creativity and decreased time to market.

Existing Organizational Processes

Strict Processes in Place: ✅ Waterfall

If you’re in an organization that has strict processes that they have to adhere to, trying to introduce Agile processes cross-functionally could be challenging, and so the Waterfall methodology will be more suitable.

Lenient Processes in Place: ✅ Agile

If your organization doesn’t have strict processes to follow and you have the luxury of being able to work flexibly, then Agile offers enough benefits to introduce the methodology.

Product Owner Involvement

Low Product Owner Involvement: ✅ Waterfall

If the product owner doesn’t want to be very hands-on, a Waterfall approach allows for involvement only during milestone project check-ins, especially since requirements and project expectations are defined in detail from the get-go.

High Product Owner Involvement: ✅ Agile

If the product owner wants to be more hands-on, an Agile development methodology allows for the product owner to be deeply involved. The product owner is a member of the team and is the owner of the product requirements. The product owner ultimately makes all decisions on the scope and the functionality of the product.

Nature of the Project

Enhancement to an Existing Product: ✅ Waterfall

If your team is delivering an enhancement to an existing legacy product where the features are well defined and must interface with known or existing products, then Waterfall may be more appropriate.

Greenfield Product: ✅ Agile

If your team is trying to build something innovative that does not exist in any form today, these types of projects are served well by an Agile software development methodology. It allows the product owner to discover the project’s features and requirements in an iterative way.

Timeline

Fixed & Firm Timeline: ✅ Waterfall

If the project timeline is fixed and can not be moved, Waterfall will offer a more predictable outcome.

Short, Flexible Timeline: ✅ Agile

If you need to get the project delivered in a short amount of time, Agile is the appropriate choice here where action and getting things built is more important than documentation and process.

Budget

Fixed, Inflexible Budget: ✅ Waterfall

If the project budget is fixed and can not be increased, Waterfall will offer a more predictable outcome.

Budget With Wiggle Room: ✅ Agile

If you do have some budget flexibility, Agile prioritizes features and speed to market over strictly sticking to a budget. Sometimes a new, valuable feature will be discovered during Agile development, but will require a little extra time and money to execute. If this works for your team, then Agile is best suited for you.

When to Use the Waterfall Methodology

The Waterfall methodology prevails when the project is constrained by cost and/or time, and the requirements and scope are well understood. In these cases, the Waterfall methodology provides a set of processes that are built on the principle of approval of the previous phase.

The bottom line is that the Waterfall methodology does a better job at providing a well-defined feature set within a constrained budget or timeline.

When to Use an Agile Methodology

Agile wins the day when the product team is unsure at the onset what needs to be built or they wish to discover what should be built based on adjustments they make along the way. Agile will produce more features in a shorter period of time and also gives the team more flexibility throughout the process so that they can take advantage of opportunities as the project unfolds.

Using a Hybrid Development Methodology

At this point, you might be thinking,“Is there a way I can combine both Waterfall and Agile when developing my product to leverage the benefits of each?”. It’s actually quite common for product teams to use some combination of both Waterfall and Agile development methodologies in order to deliver a solution in a way that optimizes the team’s time and resources and maximizes end user satisfaction. The PMI report mentioned earlier states that about 20% of the surveyed organizations’ projects completed within the last 12 months have used a hybrid approach to managing development. KPMG recently researched the adoption of agile project delivery across 62 organizations in both the Dutch and Belgian markets and found that 85% of respondents strongly believed that in the coming years, most organizations will operate in a hybrid environment. This research found that most organizations are currently working to implement Agile and are taking different routes to do so based on the processes that work for each individual organization. For example, some organizations deploy a hybrid model where the overall project phases follow a Waterfall approach to get to an approved design. Then, Agile methodologies are used during the development phase and product development concludes with a period for testing and integration.

Here’s an example of what a hybrid software development methodology could look like:

  1. Gather and document all requirements up front
  2. Design
  3. Development
  4. Test
  5. Get feedback on what’s been produced thus far (identify changes that need to be made or valuable additions that fall within the outlined requirements)
  6. Implement that feedback, develop, test, and prompt for further input. Continue this loop until stakeholders are satisfied with the product.
  7. Deploy

waterfall vs agile: hybrid development methodology

Using Agile in Regulated Environments

It’s important to note that the benefits of an Agile development methodology can still be reaped even if your team is taking on a project that succumbs to strict regulation. Agile can still be used as a software development methodology for highly regulated projects – there are just some modifications that will need to be made and documentation artifacts will need to be retrofitted as changes are made to the product. The documentation, and documentation review and approval process, will need to keep pace with the software development, but don’t let this shy you away from using Agile.

As a company that specializes in healthcare software development, our teams constantly take on projects that must meet an array of healthcare regulatory requirements and security standards. Yet, we often deploy an Agile development methodology that is adjusted to meet these specific requirements. At the end of the day, you need to evaluate the workflow, processes and structure of your collaborating teams, the budget that you have, and timelines to determine if either Waterfall, Agile, or a “wagile” hybrid works best for you.

Comments

Post a Comment

All Post

Flutter form validation: Full guide for you to make Flutter form

By
  Flutter form validation Getting started with form validation in Flutter The Flutter SDK provides us with an out-of-the-box widget and functionalities to make our lives easier when using form validation. In this article, we’ll cover two approaches to form validation: the form widget and the Provider package. You can find more information on these two approaches in the official Flutter docs. Creating a form in Flutter First, we are going to create a simple login page that has the following fields: Email Name Phone number Password For the validation, we want the users of our app to fill in the correct details in each of these fields. The logic will be defined as such: First, for the name field, we want the user to enter a valid first name and last name, which can be accompanied by initials. For the email field, we want a valid email that contains some characters before the “@” sign, as well as the email domain at the end of the email. For phone number validation, the user is expected to
Post a Comment
Read more

How to change the language on Android at runtime and don’t go mad

By
  How to change the language on Android at runtime and don’t go mad TL;DR There is a library called Lingver that implements the presented approach with just a few lined of code.  Check it out! Introduction The topic is old as the hills, but still is being actively discussed among developers due to frequent API and behavior changes. The goal of this post is to gather all tips and address all pitfalls while implementing this functionality. Disclaimer Changing the language on Android at runtime was never officially encouraged or documented. The resource framework automatically selects the resources that best match the device. Such behavior is enough for common applications, so just make sure you have strict reasons to change it before proceeding further. There are a ton of articles and answers on Stack Overflow but they usually lack enough of explanation. As a result, when this functionality gets broken, developers can’t easily fix it due to the messy API and lots of deprecated things. We
Post a Comment
Read more

7 Key Android Concepts

By
  Although the Android platform is open and customizable, Android users have become accustomed to constructs developed by Google for Android devices. Although the Android platform is open and customizable, Android users have become accustomed to constructs developed by Google for Android devices. Moreover, the use of these Android concepts is vital in developing an application quickly – custom Android designs can take up to 10 times longer! Android UI Controls Android provides a number of standard UI controls that  enable a rich user experience . Designers and developers should thoroughly understand all of these controls for the following reasons: They are faster to implement. It can take up to ten times longer to develop a custom control than to implement a user interface with standard Android controls. They ensure good performance. Custom controls rarely function as expected in their first implementation. By implementing standard controls, you can eliminate the need to test, revise a
Post a Comment
Read more

How to them the background of the Android options menu items

By
  “What we’ve got here is… failure to theme. Some views you just can’t reach. So you get what we had here last project, which is the way Android wants it… well, it gets it. I don’t like it any more than you men.” – Captain, Road Prison 36 Some of you might recognize the previous paragraph as the introduction of Guns ‘N Roses’ Civil War or from the movie Cold Hand Luke starring Paul Newman. This is the feeling I get when I try to create a custom theme for an application on Android. The Android SDK does permit some level of theming, which is not really well documented to start with. Other things are hard-coded, “so you get what we had here last project”. Now, one of the things your application will most likely use is the Options menu, which is the menu you see when you press the hard menu key. It is kind of… orange. In our last project, we had to completely remove the orange in favor of our customer’s color scheme, which is on the blue side. I couldn’t find a way to change the menu item
Post a Comment
Read more

Clean Code and the Art of Exception Handling

By
  Clean Code and the Art of Exception Handling Exceptions are as old as programming itself. An unhandled exception may cause unexpected behavior, and results can be spectacular. Over time, these errors have contributed to the impression that exceptions are bad. But exceptions are a fundamental element of modern programming. Rather than fearing exceptions, we should embrace them and learn how to benefit from them. In this article, we will discuss how to manage exceptions elegantly, and use them to write clean code that is more maintainable. Exceptions are as old as programming itself. Back in the days when programming was done in hardware, or via low-level programming languages, exceptions were used to alter the flow of the program, and to avoid hardware failures. Today, Wikipedia  defines exceptions as: anomalous or exceptional conditions requiring special processing – often changing the normal flow of program execution specialized programming language constructs or computer hardware m
Post a Comment
Read more

Android Jetpack Compose

By
  Jetpack Compose Tutorial for Android: Getting Started Jetpack Compose is Android’s modern toolkit for building native UI. It simplifies and accelerates UI development on Android. Quickly bring your app to life with less code, powerful tools, and intuitive Kotlin APIs. At Google I/O 2019, Google first announced  Jetpack Compose . Jetpack Compose is Google’s response to the declarative UI framework trend, which the Android team is developing to fundamentally change the way developers create UI, making it easier and faster to write, and more performant to run. It is a part of the Jetpack suite of libraries and as such should provide compatibility throughout platform versions, removing the need to avoid certain features, because you’re targeting lower-end devices or older versions of Android. Although it’s still in an alpha , Compose is already making big waves in the Android community. If you want to stay up-to-date on the latest and greatest technology, read on! In this tutorial, you’
Post a Comment
Read more

Loops in Dart 💪💪💪😎😎😎

By
       Loops in Dart   💪💪💪😎😎😎 Dart Loops In Programming, loops are used to repeat a block of code until certain conditions are not completed. For, e.g., if you want to print your name 100 times, then rather than typing print(“your name”); 100 times, you can use a loop. There are different types of loop in Dart. They are: For Loop For Each Loop While Loop Do While Loop Info Note : The primary purpose of all loops is to repeat a block of code. Print Your Name 10 Times Without Using Loop Let’s first print the name 10 times without using a loop. void main() { print( "John Doe" ); print( "John Doe" ); print( "John Doe" ); print( "John Doe" ); print( "John Doe" ); print( "John Doe" ); print( "John Doe" ); print( "John Doe" ); print( "John Doe" ); print( "John Doe" ); } Show Output
Post a Comment
Read more

MVVM architecture, ViewModel and LiveData (Part 1)

By
  MVVM architecture, ViewModel and LiveData (Part 1) During Google I/O, Google introduced  architecture components  which includes  LiveData  and  ViewModel  which facilitates developing Android app using MVVM pattern. This article discusses how can these components serve an android app that follows MVVM. Quick Definition of MVVM If you are familiar with MVVM, you can skip this section completely. MVVM is one of the architectural patterns which enhances separation of concerns, it allows separating the user interface logic from the business (or the back-end) logic. Its target (with other MVC patterns goal) is to achieve the following principle  “Keeping UI code simple and free of app logic in order to make it easier to manage” . MVVM has mainly the following layers: Model Model represents the data and business logic of the app. One of the recommended implementation strategies of this layer, is to expose its data through observables to be decoupled completely from ViewModel or any other
Post a Comment
Read more