Waterfall vs Agile, advantages and disadvantages

----------------------------------

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.

17 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!

Ujjal link

11/28/2018 05:32:52 am

Alex, I am 100% in agreement with you. There is no contradiction between the two approaches - agile and waterfall. Nothing, if not the personalities involved and the project management, prevents project teams to be collaborative in a waterfall. There is no hard & fast rule as you stated that one phase cannot start before everything is finished in previous phase. In fact the opposite happens all the time. Big-bang vs drip implementation - that's not a new concept. I see very little novelty in agile practices - just new language - such as 'definition of done' instead of 'acceptance criteria' etc etc.

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.

Axel

10/18/2017 02:39:22 am

In waterfall-type projects, the analysts collaborate with the business stakeholders. However the tendency exists (spitefully) to collaborate only later with the developers.

Phases are often confused with activity types and with activities. Often 'phases' in the WBS simply group activities. Let's say that the project is in the development phase, and a component is ready and can already be tested. A test is performed. This test activities can then already be booked as hours spend on activities under the WBS-branch "Testing".

The role of the test phase is often misunderstood. The real test phase is not to start testing only then, but to start the series of final tests that should prevent bugs to make it to production.
But often other test activities (one earlier) are then grouped in the WBS under the test-phase branch as well.
And the test phase is also often misused as a first presentation of the product to the client.This should be done earlier. Even WIP can be presented. But that's up to the team. The waterfall doesn't say "the client may only see the product during the test phase". It doesn't. So it's just a bad habit. Well, we all have something ... still a lot to learn. ;-)

Waterfall can have several deliveries. It can be organised in sub-projects. Or, a first minimal working version can be built first and a second waterfall will expand the version with lesser critical features.

The well-known waterfall diagram is in fact a basic (and therefore simplistic) representation. But it is just a concept and we have to learn to play with it. So it is up to the PM and the project team to model their approach (releases, intermediate deliveries, PoC, parallel tracks, work packages, prototyping, sub-projects, increased collaboration, intermediate tests, component based approach, ...).

Cristian-Stefan Turcu link

10/18/2017 03:17:52 am

Thank you for your insights, Axel!

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!

Jeff Robinson

12/27/2017 04:52:46 pm

My Agile / Waterfall experience has been on software projects. Have you used Agile for non-software projects?. The ability to use Agile methodology has been governed most by the developers ability/comfort and if authoritative business representatives work with them regularly.

On one project, two other subject matter experts (SMEs) and I documented the key work flows, processes, interfaces, and reports and then validated them with business expert users who did not have time for recurring meetings. Then when the developers were selected, they required packets of work with 10-15 screens with role-based business rules, security, and navigation information to work on for 2 month or so. Next the SMEs helped onsite QA test the packets where critical issues were fixed fast and retested before the packet was released.
As the first packet was released, the next packet was sent to the developers. This project had 4+ quarterly releases.

Another project used a vendor product where our team had conference calls with the vendor each week to discuss any issues we had, features we would like added to the tool, and adjust the priority of our needs and wants with the vendor. The vendor worked from their master list of features and fixes to deliver quarterly releases. Some of the bugs we showed them were significant enough for them to fix and provide a patch in a matter of days.

From what I have read and learned recently, I think Agile is a better way to give the customers what they need most until

Cristian-Stefan Turcu link

12/28/2017 07:47:03 am

Hi Jeff,

Thank you for your comment.
Yes, I used Agile in organizing sales.

Pablo

4/19/2018 09:54:26 am

I still think that key differences between the two methodologies relies in the three key constraints: scope, cost (or budget) and time. In waterfall you plan and estimate according to the scope and define a baseline, and then derive the cost, but in agile (i.e. scrum) you will define your scope based on how much money you would have and the time you have until the end of the project, so you can move between those boundaries.
If you need to change the scope in waterfall, you must re-define your baseline and start a change request process, so that means time and more cost, in agile you can play with the scope and reduce features.
Based in my experience with both methodologies in IT projects, I prefer to use some hybrid by taking some processes from waterfall as the requirements gathering but manage my releases like in an iterative agile way. Stakeholders participation is also better in agile and creates more engagement. That's my opinion.

Cristian-Stefan Turcu link

4/19/2018 10:23:16 am

Thank you for your comment, PABLO. Valuable opinion!

Biz-IT Bridge

Terms and Privacy

Waterfall vs Agile, advantages and disadvantages

Leave a Reply.

Articles

Categories

Archives

Search

Keep up to date

Author

Biz-IT Bridge