Don’t sound the death knell for Waterfall yet

Agile, and Scrum in particular, has become the de facto standard for developing new green field projects nowadays. Organizations of every size, from very small to very large, have reported success with it.  According to a survey of attendees at a 2012 Agile conference in Dallas, 49% of attendees reported that most of their companies’ development projects are done in Agile, and they estimated that 52% of their customers are happy with Agile projects, while another 28% are neutral.

As Agile/Scrum continues to gain acceptance, some have sounded the death knell for the Waterfall method. Many blogs and articles wrote it off as old-school years ago.  And yet it persists. The same thing happened when videos and then DVDs came onto the market. Many believed that these would kill the movie theater business. But they didn’t. Instead, DVDs found their place in the market, and the movie business is as strong as ever.

A similar misconception happened with Waterfall when Agile gained acceptance. That is, people thought one meant the end of the other.But in spite of Scrum’s effectiveness, it isn’t a silver bullet. If requirement changes come very late, there will still be delivery delays whether you are using Agile or Waterfall. And if the budget and time are tight for Waterfall, it will be tight for Agile as well.

The fact is, there are still projects where Waterfall works great – projects with no or very few possible changes. These tend to be on government or industry projects that support standards or regulations, or on small to medium projects where requirements can be accurately scoped and planned upfront. Waterfall may also be the preferred method for software development in organizations with a very rich and established elicitation/confirmation/validation/approval model.

Below are a couple of graphics that illustrate a fundamental difference between Waterfall and Agile/Scrum processes, and how each is managed as a result.

• In the Waterfall process, the project scope is constant, and cost and time are variable. The project manager has to carefully control the variances of time and budget toward the baseline.

Illustration 1. Waterfall

• In the Agile process cost and time (time bounded iteration) are constant and the scope is more variable. In this case, the project manager is always working to control the scope toward the baseline.

Illustration 2: Agile/Scrum

Now add to these a third model – a hybrid one. The hybrid model combines some of the best features of the Agile and Waterfall methods. See the columns below:

Basically, the hybrid model improves agility on Waterfall projects.

I will be writing a series of blogs on this topic – talking about what works best for ETL/BI projects, and how we determine whether to use Agile/Scrum, Waterfall or Hybrid methods. I’d like to hear your questions or feedback on this post and my future ones, too.