Has the waterfall been obsolete, since Agile is dominant everywhere?

[asadiq]

Since Agile is dominant in the world of software development and delivery, I am wondering whether Waterfall has been obsolete from the market. If it is still in the market where it is being used? 

[Stephen_Lugton]

Hi @asadiq 

Imagine the process for creating and releasing a new application:

• Product Discovery
• Scope / requirements refinement
• Development
• QA / UAT
• Marketing
• Release
• Feedback

Each of these steps is carried out in an Agile manner, but they follow a logical sequence, so although individual aspects of the work are use Agile as their way of working, and can overlap each other and be repeated for different value producing activities, the sequencing of the steps typically follows a waterfall approach i.e. do this, then do this, then do this ...

In fact taking Scrum as an example, the entire Sprint cycle follows a waterfall process:

• Refine the backlog
• Plan the sprint
• Do some development
• Review the potentially releasable increment

[Frankie C.]

Not obsolete :)

Big corporations and federal entities still rely on waterfall/hybrid approaches, especially for big initiatives that require deliberate pacing and coordination across multiple functions. 

@Stephen_Lugton had an interesting point in making an association between waterfall delivery and sequential processes in general. I'll add that to me, one of the differences between waterfall and agile is that waterfall is less of a mindset, and more of a means of structuring and delivering work; While we put the "agile" label on everything, agile is actually more of a mindset and set of behaviors, with different flavors of delivery (like Scrum, Kanban, etc.) being the method to apply that mindset/behavior set. 

[Nigel Budd]

The only area where I've found Waterfall still being successfully used in software development is for use-cases such as a web-site development based on a builder-app where the resulting product is fairly fixed in it's nature, and the expected outcomes are well defined.

The customer expectation is set early in the project, they know what their site is going to look like, perhaps with a small amount of adjustment, so there is no benefit from the close feedback loops that are part of the Agile team DNA.

These tend to lend themselves well to fixed price types of engagements as well.

[Staffan Redelius]

Many organizations do waterfall but call it Agile because they have some agile ceremonies in place.

As @Stephen_Lugton wrote the actual process is similar. Agile is just short "cycles" of gathering requrements, development, test, deliver and evaluate.

There is a big difference in doing Agile and being Agile. It is not a religion, it is a framework for continuous improvement.

The big flaw with waterfall was the ambition to freeze requirements and try to deliver towards a fixed goal, budget and time frame. A good project manager would set up milestones for evaluation of the current direction and change course when/if necessary.

I met a project manager working in a project regarding long term storage of nuclear waste. They had spent 6 years on just defining the scope for the prestudy.

So yes, there are still areas where an experimental agile approach would be... well not a very good option.

[asadiq]

Hey Staffan

Thanks for the input.

As  @Stephen_Lugton said, both are pretty much the same but, they are more of a mindset and frequent delivery.

"There is a big difference in doing Agile and being Agile. " Agreed with your statement.

This is the weakness "The big flaw with waterfall was the ambition to freeze requirements and try to deliver towards a fixed goal, budget and time frame" which turned into the opportunity for the Agile.