Waterfall vs Agile, advantages and disadvantages

7/17/2015

Though I am an adept of Agile methodologies since 1999, I do recommend Waterfall, when it is better for your organization/project. It is a nice saying: "Choose the vehicle which fits your culture!"

But probably we should have a look over these 2 sets of methodologies, Waterfall vs. Agile, what they are, what are their advantages and disadvantages and when should we use one or the other.

Following this path of thinking, I believe that it may be a good idea to point you to a very clear article, with these topics. Please read here the full article.

10 Comments

Axel Vanhooren

1/15/2016 02:57:54 pm

Does the waterfall methodology exist? I never saw it.
AFAK there is unique formal description of THE waterfall methodology.
When we talk about the waterfall the discussion is always about the 7 to 9 (or more?) phases (they don't even have always the same name).
And I do see plenty of methodologies are based on a sequence of phases.
They use the same methodological concept.
So to me, that's what the waterfall is ... a methodological concept.

Often I read that the developers (it's not just about the developers) may not go back to a previous step. Where in the waterfall standard is it written? And even if it was written, if I was the PM of that project and it turns out something hasn't been done well in an earlier phase, you bet I will tell the analyst or designer or whoever to go back and get the stuff right. This is not about "moving the whole project to an earlier phase" or "restarting the whole project". It's just about solving that issue, redoing that part of the project that hasn't been done well.

I, but also the the whole team, bears the responsibility of the project, not the methodology. So we would not let one or another methodology dictate how we should work. Don't we have to adapt any methodology to the needs of the project? Procedures have to be followed strictly. Methodologies not!! Methodologies are like templates. They just offer you a basic scheme that has to be adapted. This is normal since projects aren't the same. You would be very lucky of your methodology fit your project without having to be adapted.

Basically, the phases of a waterfall project indicate the type of activities on which the focus is. During the analysis phase, the focus is on the analysis. Can some programming work be done during the analysis phase? Of course it can. Why not?

With waterfall or with any method, I saw many clients that have no clue about what it will get. They don't always understand the models, the explanation, the analysis document and presentations. Or maybe they don't want to. It's always possible to build a prototype.

Does the 'waterfall' prescribe to "write as much documentation" as possible? We need to make those models and write those things down that do matter. Nothing more.

If some requirements are erroneous and I know this, I won't continue the project. This will be discussed and whatever needs to be redone or whatever plan will have to be adapted will be. It makes no sense to continue building on a non-solution. Again, it's a matter of taking responsibility and knowing how to deal with issues that may occur. It doesn't prevent me from following the waterfall concept.

It is true that the phase 'testing' occurs late. But,tests are done, even in the waterfall from the very beginning. The findings of the analyst are tested, design models are tested, prototypes can be build, and so on. There is a kind of testing during the whole project.

Many changes are asked by the client and are therefore perceived as if the client changed his needs. Many changes are due to the growing insight in the problem and its context as the project evolves. It is the lack of 'upfront' knowledge about the problem that causes many changes, much lesser than real needs that changes. This is the very purpose of the analysis!! The analysis is there not to record and refine the demand of the client but to learn about the problem and its context and so to avoid these changes due to ignorance (and bad decisions).

Planning is not an waterfall-issue, but a PM issue. Making plans in the beginning of the project when little is known (based on little knowledge) and trying to stick to the plan is rather a destructive usage of plans. Planning is very useful because they forces us to think about what and how to do things and the plans resulting from the planning activity can HELP us to guide a project (plans themselves don't guide!). Plans are useful if they are allowed to evolve (and if they do when necessary) over the course of the project.

The 'clear' picture of the product is created during the project. Scope-change procedures can be foreseen (This is rather a PM issue). The waterfall-based methodologies can deliver in iterations as well.

Basically, what is the waterfall as a methodological concept? It says learn what the real problem is before you do anything else. Think about the solution, about what you will build before building it. Then build it. Since it is a complex solution, maybe it's better to do a last full test before releasing it. If it works fine, then you can release it and if it doesn't correct it. And basically, this is the way I solve problems.

Cristian-Stefan Turcu link

1/16/2016 01:12:41 am

Thank you very much for your opinions, Axel!

Karthikesh

1/17/2016 08:34:15 am

I can't agree with you more Axel!

Ahmad

1/18/2016 11:27:14 pm

Thanks Axel, you have a point, but I didn't agree with you.

Fred

3/11/2016 02:14:51 pm

Hi axel
I fully agree with you.
Management of expectation is the key point and need to be documentated in a manner that all project team member can rely on. For our software development we are using the hybrids methodology VScrum. Specification and design associated with iteration on dev level associated to intensive early stage test.
Since I am applying that methodology the delivery surprise effect reduce (sometime disappeared) amazingly.

Fredrik

3/12/2016 03:47:36 am

Although not an expert on waterfall, I do agree with a lot in Axels's comments, so won't comment on that further. However, I strongly disagree with the claim that agile values speed before quality, where I also think you contradict yourself, as you correctly say that a great advantage with agile is testing early in the project.

The fact that you focus on small parts of the software at the time, have a collaborative approach with client and fully functional incremental releases, makes agile very advantageous in delivering quality, both in terms of software quality but also as in meeting client's requirements. Then downside from a quality perspective may be that you will not have all bells and whistles from first release.

Scott

4/8/2016 04:30:58 pm

Re: the statement:
"I, but also the the whole team, bears the responsibility of the project, not the methodology."

The applicable methodology that is most effective should reflect the attitudes and thinking of both the Client and Technical communities.

Whether a CMMI level 0 or 5 shop... consensus and collaboration are key to any methodology utilized.

I concur that the most effective approach to Business/Systems analysis is the one that is tailored to a Client's current business climate.

Cristian-Stefan Turcu link

4/8/2016 11:32:13 pm

I appreciate your points, Scott. Thank you for sharing them.

Prashad Lodhia

11/15/2016 03:34:48 am

I often use a hybrid approach where you do a number of mini-waterfalls where you still analyse, design, develop, test, but you repeat this a number of times so that changing business needs can be accepted. Also any flaws in the ways of working or technical approach are identified much earlier and can be resolved in the earlier cycles.

Cristian-Stefan Turcu link

11/15/2016 08:51:17 am

PRASHAD LODHIA, I can understand this approach. It is better than traditional way (Waterfall), though Agile is much more than a set of mini-waterfalls.
For the beginning, it is a good approach when migrating to Agile.
Keep going!

Biz-IT Bridge

Terms and Privacy

Concept and Design by Cristian-Stefan Turcu

Biz-IT Bridge
Articles