Is Waterfall Methodology Really Outdated?


Although many hardware and software companies rely on some variation of Agile to build new products, the methodology has received its share of criticism over the years. This month, Andy Hunt, one of the developers who co-created the Agile Manifesto, argued that development teams’ implementation of Agile often failed to live up to the promise.

But what are the alternatives? Waterfall Methodology—which some old-school folks sometimes call the “traditional” method of development—requires its teams march through a preset series of steps, each of which must be completed before the next can commence. While those steps sometimes differ from company to company, in broad strokes they go something like this:

  • Establish Requirements
  • Design
  • Code
  • Test (and Test Again)
  • Fix Bugs and Issues
  • Integrate With Other Platforms/Technology Stack

In theory, Waterfall works because it establishes the parameters and design of the project from the very beginning, and allows for careful and methodical progress. But according to Waterfall’s critics, anyone relying on the methodology needs the following things to occur:

  • A (Reasonably) Well-Defined Set of Requirements
    Having a set of requirements from the outset is an important factor in Waterfall. However, people have ideas—and sometimes those ideas occur midway through a project, and force a radical change in the project’s goals. It happens in both the hardware and software worlds. And when those ideas occur in midstream, it can prove devastating for the project’s budget and timeline.
  • Any Changes to Requirements and Goals to Be Small
    As anyone who’s ever worked in tech can tell you, sometimes the changes to a project are radical. When Apple released the iPhone, for example, it forced Google’s Android team to chuck its existing work on smartphones and start from the very beginning.
  • Testing and Integration to Go Smoothly
    Virtually all software projects involve lots and lots of code, and not a lot of time to review said code if the team wants to make its release date. With hardware, it’s a similar conundrum: Lots of things work very well in controlled conditions, only to break once they hit the real world. And then there’s the small matter of integrating the project with the other elements of the company’s technology stack: If the amazing smartphone you produced doesn’t play well with your cloud service, you have a problem. Waterfall depends on everything related to testing and integration proceeding as smoothly as possible—and oftentimes, that just doesn’t happen.

With Waterfall, if things go very wrong, the team not only fails to deliver the project on time, but the project itself is a hash of elements that don’t play very well with other software and systems.

Still other companies have tried for a hybrid approach, one that relies on Waterfall methodology to set requirements and goals, but then reverts to Agile’s flexibility in order to get the job done. Such innovations can fail, however, without a solid manager at the helm.

All of which culminates in the ultimate point: Whether a company opts for Agile, Waterfall, or some other development methodology, the most important element is a manager or stakeholder who can keep the project on the rails. No process is a silver bullet; without the right people at the helm, any effort can implode.

7 Responses to “Is Waterfall Methodology Really Outdated?”

  1. Jim Hillhouse

    I think you’re imagining development under Waterfall as too rigid.

    I worked on a project a flight modeling and control application for a large NASA non-commercial subcontractor. We worked as an Agile team; every so often on a Monday I’d find that my previous code wasn’t working because the lead architect had decided to change the base classes over the weekend. Now that’s Agile! Weekly we fell farther behind schedule and over budget. Eventually, the team was massively reorganized and under a less “responsive” and “creative” development paradigm, the code was completed and worked great.

    I think when people think of requirements, they believe that such requirements should be detailed. Certainly, there are times in which that is appropriate. But generally, you start at the high-altitude view, use those to build a prototype, which then connects the application with the harsh realities, and forces the team to reevaluate the requirements before beginning on the final app. There is no reason why requirements should not allow a team to adapt to the changing world around it.

  2. Brian

    Unfortunately the real problem is putting handles on the processes and concepts. something we see throughout many walks of life usually resulting in bad performance and wasted money. Although Agile and other training organisation tend to do well! out of the con.

  3. Richard Lerner

    The most important thing that waterfall requires is control and scope management, which is usually the domain of a project manager. Typically, projects are that of as “all other things being equal”.

    In Banking systems (where I work) changes are made in consultation with other teams as small changes in a back end system can cripple other downstream systems.

    Agile is good when you don’t know what it is that you want to produce and the market is fluid, there’s no point in investing too much effort on something that is going to be replaced by something newer and shinier in six months.

    Waterfall is much better if you have to deal with people’s money and the cost of a bad implementation is having auditors show up at your desk

  4. Rob S

    Waterfall works great in well-defined projects like building a skyscraper. It’s less effective when there are a lot of unknowns like in the ever-changing software industry. Agile is supposed to help with that but as you said u need a good manager type prrson at the helm to keep it focused in the right direction (which is likely to change weekly )

  5. Huh Son

    No, the most important element are good programmers that do not have to deal with ignorant managers and/or impossible language barriers with offshore resources.

  6. Curt Newell

    Nick, Waterfall can work better and be more nimble by taking on requirements or changes in smaller chunks, e.g. 1-2 month’s work, and by not arbitrarily increasing project scope while underway. The basic steps you listed are accurate for most IT projects, even when working in Agile on a 2-week sprint. I’ve seen Waterfall project struggle or fail when taking on too many requirements for a 8-12 month project and then taking on extra work, or parallel sub-projects, because the customer needed a solution earlier than the Waterfall project’s increasingly distant and vague future conclusion. This is a self-inflicted wound for waterfall practitioners which has lead to Agile-like approaches.

  7. Constantine G. Ganas

    We used the Waterfall Methodology for the Software Development
    Life Cycle at Blue Cross Blue Cross of South Carolina’s TRICARE
    IT Department and it worked very well. We had a process in place
    where if someone wanted to change the direction of the project
    during the system test phase you could not do this. You would have
    to go through the process of creating a Change Control where
    these changes would be looked at after the main project’s Production implementation. This way production timelines were met 96% of the time.