Sometimes it’s OK to “Waterfall”

Waterfall modelI have led many Agile transformations in the past few years for our clients. These clients, both IT and the business, were ready to change the way they developed solutions. The change required for such a shift caused much ‘pain’ in the organization, but these clients knew that they needed to make the change.

During one of these engagements, someone on the client team told me that they had tried to convince another group at the company into making the move to Agile from their Waterfall approach. When the Waterfall group manager said he had looked at Agile and did not see the benefits for the business and systems he supported, the Agile advocate chided the manager for being “stuck in the mud” and that Agile would benefit the group greatly.

That’s not always right.

Agile has many great benefits, and I run all my projects that way … but that does not mean, “one size will fit all.” I have discussed with some groups, which were seriously considering Agile, but I dissuaded them from doing so, because they would have disrupted their business partners and throw away a lot of really good functioning processes.

The types of projects that benefit from Waterfall are:

  • Infrastructure migrations or installations
  • Application migrations
  • Enhancements for applications that have been in place for a long time

Waterfall projects work best when all or the majority of major requirements are known. Waterfall is a very rigid process, so by defining the scope and requirements upfront, the project manager/leader can define the project plan and create a clear vision and path to the end state. Additionally, having that clear vision allows the business or project funders to allocate the right amount of budget.

The key element of a Waterfall project approach is the scope. Once the project plan is defined and all things are known, then the scope of the project cannot change. Additionally, scope items can be added after the initial project is ended, or maybe in parallel by another project team.

So, if things are running well in your IT organization, meaning the business is happy, projects deliver on time and under/on budget. Then I think you have a pretty good thing going and don’t need to “unstick yourself from the mud” anytime soon.

Sogeti Labs

About

SogetiLabs gathers distinguished technology leaders from around the Sogeti world. It is an initiative explaining not how IT works, but what IT means for business.

Related Posts

Your email address will not be published. Required fields are marked *

5 + 9 =


  1. Nitin Kadam April 21, 2015 Reply

    Agree with your point of view
    I will add that rather than completely adopting a Agile way of working (and here I specifically mean using Scrum or similar methodology), we can adopt some agile principles and apply to the traditional waterfall or RUP way of working. So in RUP, we can make the iterations small, involve periodic milestones to get customer involved etc..

    • Marco Coopmans April 22, 2015 Reply

      Tried that at the Port of Rotterdam (HAMIS project), didn’t work. Don’t take it the easy way. Going agile is difficult but you should stick to it, because it will really pay of.

    • Leigh Sperberg April 22, 2015 Reply

      Agreed … a lot of organizations have to adopt “hybrid” agile principles because other departments do not/ can not change. For example, IT has to define the entire project upfront in order to get budget from finance.

      Do what works and always improve …

  2. Jos Punter April 21, 2015 Reply

    Once the project plan is defined and all things are known, then the scope of the project cannot change.
    Ok and since when this ever happened in real life ?

    Still i agree with you, some projects could benefit from the waterfall approach. You shouldn’t go Agile just blindly and see it as a “silver bullet” or the sollution to every thing. Mostly what it does is make it clearly where the “hurt”is in the organisation. If you dont want that dont use Agile

    • Leigh April 22, 2015 Reply

      Knowing all the facts upfront might have happened once in recorded history … maybe the pyramid builders? 🙂

      Agile should be implemented when it makes sense … and implemented seriously as opposed to just doing it because it is cool.

      • Julya van Berkel April 30, 2015 Reply

        I agree that Agile should be implemented when it makes sense. The choice to transform your organisation to Agile should not be taken lightly and I usually explain why Agile exists by going into the origins of agile based on sequential methodologies like waterfall. Waterfall worked for a long time because we didn’t use it religiously until it was institutionalised by organisations and governmental processes.

        Agile, Scrum, Waterfall all suffer from using it as a goal.

        That being said. It is an illusion to think you can hold on to “all or the majority of major requirements are known” situation. Therefore I would like to stipulate that Waterfall works best on short projects and not year long projects without adding on procedures and changes processes. Which is what we did in the past.

        If you look at what Dave Snowden says based on his Cynefin framework you need to make the decision on what to use not by categorising your situation but you need to figure out if your situation is Simple (standard work, simple, use best practices), Complicated (analytical, use good practice, Waterfall fits well here), Complex (there is no causality to what happens, you work by safely failing, emergent order, Scrum fits well here) or Chaotic (try to stabilize the situation) – see: http://cognitive-edge.com

        Thanks for your thought 😉

  3. Marco Coopmans April 22, 2015 Reply

    I agree with not using if for infrastructure projects. Agile is more suited for software and than hardware. I don’t agree with application migrations. In all of my working live (25 years now) I never encountered an application migration that was just a technical migration without any change on functionality. In most of the cases a migration is also used to (radically) change functionality. What is also different is the technology. And one of the assumptions of agile is that every situation is unique and that a developer doesn’t now upfront how to built it, but has to discover it. That’s why agile is certainly recommended for application migration.

    • Leigh April 23, 2015 Reply

      Agreed that most application migrations require enhancements/functionality changes, but if the app is a known quantity then a lot of the requirements could be known upfront. So, scoping a waterfall project for that kind of migration could be done.

      Agile is great for new development, so it could also be used in an app migration. But if the team must gives estimates up front, waterfall would work as well.

  4. Greger Wikstrand May 13, 2015 Reply

    Are there really times when it is OK to do waterfall?

    There are a fair number of assumptions here:
    1) Anyone actually does a strict waterfall for non-trivial problems. Not true, and even the construction industry is moving away from a waterfall process: http://www.gregerwikstrand.com/agile-waterfall-and-the-construction-industry/
    2) Change can be limited. Not true, change is ever accellerating and only short short time frames can be kept stable: http://www.gregerwikstrand.com/change-agile/
    3) There are successful companies doing non-agile. Of course you can find some examples, but statistically that is not a significant cluster, at least not in this major study from Brazil: http://www.gregerwikstrand.com/software-development-success/

    • Leigh May 16, 2015 Reply

      Hi Greger.

      Agreed that Agile is gaining ground in several industries (thankfully!).

      I don’t think change can be limited in new software development or even in enhancements, but mature organizations who have been supporting the same processes and systems for a long time can perform work just as efficiently in waterfall. Now, they will have trouble breaking out of their “tried and true” ways, but that’s where experienced Agile professionals can help them.

      Found this article recently that I think is interesting … it speaks to how Agile is becoming a bit of a brand and should get back to its roots. A company trying to become agile and adopt the principles could get steered or scared away by some of the issues listed in the article:

      http://blog.toolshed.com/2015/05/the-failure-of-agile.html