The Waterfall Model is not all bad (and some lessons for agile teams)

Monday, May 3rd, 2010 - By Vineet Sinha

The Waterfall model has become a joke and is pointed to as an way of doing software development poorly. While the approach has a number of limitations, it is helpful in some situations. Understanding these situations can be useful when trying to use an agile development methodolgy to make sure that you do not make critical mistakes.

During a conversation last week, a team lead told me that he considered Agile and Watefall as being two different approaches with the same result. As a proponent of Agile approaches, I tried to understand his situation and convince him of the benefit of an agile approach. After some discussion, I came to the conclusion that his situation was unique in that it actually benefit from a more rigid approach.

The reality is that different development methodologies are appropriate for different situations. And while we all have our favorite approaches, we need to be careful about whether our current team/project benefits or gets hurt by our choice of development methodologies. Agile approaches breakdown without strong collaboration, and a waterfall approach cannot deal with changing requirements.

While the Waterfall model (even when first described) was used as an example of a flawed development model, it does have strengths. Many organizations need better software systems, but don’t really understand their requirement. Having a well-defined process for gathering requirements can help clarify the most important parts of a complex project. Agile teams work well when faced with changing requirements but they need to make sure that the first requirements that they are working on are the most important ones.

Agile development may not be as efficient when progressing towards a known goal (as indicated by the red line), but they do have useful functionality in every iteration.

Goals change over time - a team using the waterfall model will take much longer to reach an adjusted goal than an agile one.

The benefit of knowing all the requirements of a complex project can be a big strength of the Waterfall model. While having all the requirements does mean that the team needs to know both the problem and the solution, having this information allows optimizing how modules interact and therefore reduces the high communication overhead in projects. While Agile teams thrive in situations where only the problem is known, they do this at a cost – that of not having as clear module definitions, having code duplications, and thus having a higher communication overhead among development team members. Agile teams therefore need to make sure that they are consistently paying down techincal debt and improving the code based on an updated-architecture.

Additionally, knowing all the requirements in a project allows for teams following a waterfall model to optimize development efficiency by not worrying about short-term feature milestones that are not needed in the complete system. While this can add significant integration challenges for non agile teams when deploying an entire working system, the presence of the short-milestones in agile teams can add significant overhead for agile teams. Agile teams therefore need to realize that their lack of such development efficiency do comes with a benefit – one of having shorter milestones to provide their customers useful functionality frequently and therefore needing to focus on having working code with real users in each milestone.

Image credit: flickr



  1. Dean says:

    It’s good to read a blog with some perspective about the tradeoffs between heavyweight and agile processes. Many agile proponents make it sound like all software projects before the introduction of agile were failures and all agile projects are successes.

    Here’s an article about the most heavyweight software development process I’ve ever heard of. The software is perfect because the consequences of a flaw would be deadly:

    Here’s an excerpt:

    “But how much work the software does is not what makes it remarkable. What makes it remarkable is how well the software works. This software never crashes. It never needs to be re-booted. This software is bug-free. It is perfect, as perfect as human beings have achieved. Consider these stats : the last three versions of the program — each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors.”

    I don’t think I would want to work with a process like this, but when lives are on the line you have to have a development process that is up to the task.

    • vineet says:

      Dean, Thanks for the comments.

      Yeah, that sums it up pretty well – when lives are on the line, when things need to just work, it is good to have a very thorough development process.

  2. Travis says:

    I’ve worked nearly equal times in “waterfall” and “agile” environments.

    Frankly, the “agile” environments have produced higher-quality code that is more testable, more maintainable, and more reliable than the code produced in “waterfall” approaches. There’s also far less code duplication.

    The end result depends more on the team than the approach. The difference is that “agile”, in my experience, tends to play on the strengths of the team.

    Frankly, NASA is a horrible example. If I hired 260 developers to “perfect” 400,000 lines of code in an “agile” shop, it would be just as perfect, assuming the developers I hired were as skilled as the developers NASA hires.

    I’m simply not convinced, but I’m open-minded. I’d really like to see some of the strengths of “waterfall” highlighted, I’m just not sure these are them.

    • vineet says:

      Travis, Thanks for your comments.

      Yes, Agile teams in my experience have produced better results, but that has usually been because in most real world scenarios requirements change and the waterfall model has a really hard time coping with it.

      As for ‘writing perfect code’ – I disagree. If bug-free code is important then you really need to lock down the requirements, and in such cases the rigor of the waterfall model is really hard to beat. There is alot of academic work that tries to right such bug-free code – and the only way they have been able to do it is to really get alot of details in the specification phases of the project, i..e they tend towards a much more waterfall approach.

  3. [...] The Waterfall Model is not all bad (and some lessons for agile teams) [Online]. Available from: (Accessed: 03 February [...]

Leave a Reply