OnPath Testing Blog

Waterfall vs. Agile – Which Approach is Best for Your Company

Written by Brian Borg | Jan 18 2020

Let’s say that one of the business units within your company decides it needs an application for its operations.  You meet with the leader of your developing team and discuss the project.  Once the scope of the project is agreed upon, the developers get to work diligently writing code every day.  Six months later the developer hands over the finished project and it works as first envisioned.  Everyone is happy.

If only it were that easy.

Writing code isn’t like writing a book.  You don’t just create a story outline and start writing from start to finish.  The lifecycle of custom software development is a complex process that is broken down into multiple palatable stages.  It also requires a great amount of teamwork, collaboration and management.  There are also a multitude of determinants that govern the process such as user requirements, involved platforms and target dates.  Despite the involved complexity, it is essential to get the process right.  The premature release of a “buggy” application can result in lasting consequences down the road.  For one, it’s always more expensive and time consuming to fix it the second time.  In addition, the image of both the development team and the company behind the release can be greatly tarnished.  Hence the phrase, you only have one shot to make a first impression.

Two Development Methodologies: Waterfall vs. Agile

This is why it is important to have a methodology that defines how the project will be implemented.  organizes the workflow of the project.  There are two basic methodologies utilized today.

  1. Waterfall - otherwise known as the traditional linear approach to software development that follows a defined sequence of events.
  2. Agile – an iterative team based approach that emphasizes rapid application delivery that utilizes a framework called Scrum that breaks the overall development phrase into sprints.

A good analogy that demonstrates the distinctions between these two can be observed in the way in which Microsoft releases its operating systems today.  It used to be that Microsoft released its operating systems with defined life cycles of three to six years.  Although Microsoft would release a service pack at some point during the product lifecycle to fix bugs and add a feature or two, very little changed until the next OS release.  Compare this to the Windows-as-a-Service approach of Windows 10.  The latest OS is constantly evolving on a continuum basis, introducing new features every few months, rather than years.  This allows for a more up-to-date operating system that users can easily adjust to as changes are incremental and not huge leaps.

The Waterfall Approach

There is no denying that Waterfall is an awkward name, but a good analogy might be that like a waterfall, water can’t go back up after it flows downward.  Such is the nature of this traditional methodology.  Using this traditional approach, the development project is separated into distinct stages.  Each one must be completed and signed off on before the work is passed on to the subsequent stage.  These stages are usually comprised of something like the following:

  • Planning
  • Analysis
  • Design
  • Development
  • Testing
  • Maintenance

Each successive stage has its own personnel team and relies on information that was forwarded from the previous stage.  Think of how a car is manufactured on an assembly line.  Each component is added on in a highly distinct order that does not change.  

There is no doubt that waterfall is not as popular as it once was, but that doesn’t mean it is dead.  In fact, there are a number of circumstances in which the waterfall approach still makes a lot of sense.

  • There is a resolute defined vision by the owner at the very beginning of the project
  • There is a firm timeline for the project that cannot be a altered
  • The budget for the project is allocated and cannot be adjusted
  • The owner will not be involved at all during the development cycle
  • Enhancements are being added to an existing legacy product 

Agile

The very word, agile denotes agility and flexibility, which is what this approach is all about.  Agile has been widely embraced due to the elastic nature of software today and is the dominant approach used by development teams.  Unlike waterfall, there is no defined vision or stages.  Instead, the project is broken up into a series of sprints that encompass a short period of time (3 weeks for instance) in which new product features are planned, developed, reviewed and released.  Agile isn’t about a single release, but perpetual releases that are constantly introducing innovative features that enhance the product.  The primary aim is to get something of value in the hands of the customer as soon as possible.

For instance, the sprint at hand may be to create a button that the stakeholders of the application have decided is now needed.  Once completed, the team takes on the next facet to be released.  Although the agile approach may sound chaotic, it is actually a very orderly process that allows for constant customization and refinement.  Each day begins with a daily standup, a fifteen-minute meeting in which contributors and managers discuss what was completed the previous day and agree on what needs to be done on that day.  While the end product may be far different than its vision, the customer and other stakeholders are continuously involved throughout the agile process.  

Both Require Testing

No matter which methodology you utilize, one thing is common to each.  You must ensure you have quality code before it goes into production.  For waterfall, this means testing everything near the completion point of the project.  In the case of Agile, testing is a continuous process, often commencing in parallel with code development.  

At OnPath Testing, our automation engineers are adept at creating the best testing solution for your application needs to ensure that your application is stable and predictable, regardless of platform.  We can also go beyond the role of automated QA and dive down into the functionality of your code to ensure it does what it was intended to do.  In the end, it doesn’t matter to us which development methodology you use to guide your project.  What matters to us is that we inject the value of assurance into your development through our testing expertise and efforts.