Waterfall vs. Agile – Which Development Method is Best?

You need a software application that does (blank), you meet with the developers, and a few months later you have your new software. Easy, right? If only it were that simple.

Most people agree, creating customized software is generally a complex process. It requires a great deal of planning, collaboration, teamwork and management. And the stakes are high. A poorly implemented software release paints a negative image of the development team as well as the organization that hired them. That’s why the software development lifecycle requires some type of methodology to oversee the development operation.

There are two primary methodologies you should be aware of – Waterfall and Agile. A quick web search will garner numerous links in which these two approaches duke it out as to which one is better. However, to say one is better than the other is like saying that owning a truck is better than owning a compact car. If you need to haul a lot of stuff, a truck is better. If you live in a very dense, urban area where parking is at a minimum, a compact car is better. The approach you choose depends on the situation at hand. Not sure which approach is best for your project? Read through the descriptions of each below to understand each one. Still have questions – feel free to reach out to us and we’ll help you decide.

Waterfall

First off, waterfall may seem like a strange name for a project management process – but it’s a common term in IT; and many refer to it as “traditional.” One possible way to explain the name is that just like a waterfall, water can’t go back up after it cascades downward. A waterfall project is comprised of various stages and each one must be completed and signed off on before being passed on to the subsequent stage. Each successive stage has its own personnel team and relies on information forwarded from the previous stage. Waterfall is ideally suited for instances in which there is a defined vision by the customer of what they want. To use an antiquated example, think of Henry Ford and the Model T. The car moves along the assembly line as teams of employees complete their assigned tasks. What starts out as a simple frame in the beginning, drives out of the factory a completed car, ready to hand off to the dealer. Using a waterfall approach, the car moves along from start to finish in order.

In terms of a software development project, the successive phases are usually broken down into these basic stages:

A waterfall-oriented development team usually consists of four roles that include a project manager, business analyst, developer and tester. Compared to agile, waterfall puts more emphasis on planning on the front-end. Progress is easy to measure and end results are more predictable thanks to detailed planning and design in the early stages. You could say that waterfall sticks to the script as the plan is conceived at the beginning and everyone follows the plan in proper order.

Agile

As its name implies, this methodology is about agility and flexibility. It’s highly suited for software development due to software’s elastic nature. Unlike, waterfall, there is a more loosely defined visionthat guides the process. There are no defined stages. Agile is a continuous deployment practice made up of “sprints.” A sprint is a short span (2-3 weeks per sprint is very standard) in which products are planned, developed, reviewed and released. But the definition of “product” can vary from project to project. Agile isn’t designed around a single release, but multiple releases, that may in fact induce further releases.

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, this sprint may then be followed by another sprint that centers around the release of a new application feature. This perpetual cycle can go on for years as the software evolves. Each sprint is loosely defined by a storyteller who creates a story of what the product at hand should accomplish based upon the input of the stakeholders. Because there is no highly defined plan at the beginning, 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.

Although the agile approach may sound chaotic, it is actually a very orderly process that allows for constant customization and refinement. While the end product may be far different than its vision, the customer and other stakeholders are continuously involved throughout the agile process. One of the goals of Agile is to get something of value in the hands of the customer as soon as possible. In the case of a new application, the aim of the agile team is to get a basic working application delivered as soon as possible. Continuous sprints then take place to add new features, many of which may have never been conceived at the outset. Unlike waterfall where testing is done at the finale, testing is continuous, sometimes operating in parallel to the code development.

Summary

As you can see, each approach is very different. While Agile is definitely the newer methodology of the two, it is readily gaining acceptance in the software community. Both approaches have their advantages and disadvantages. As stated, there is no overall better way, only a way that is better suited to the needs of your project and organization. Before you begin a project, be sure to find out which approach your development team utilizes.