Waterfall vs Agile

In my life I have seen only 2 projects failing miserably - it all depends on the definition of "failure" anyway.

One was a PURE (pseudo)WATERFALL approach: developers were told that they needed to read the requirements, then do ALL the High Level Design with Rational Rose, then ALL the Low Level Design, then ALL the coding, and only then, 6 months later, deliver to the client.
The result was:
- two months spent with people scratching their head asking themselves what on earth should go into a HLD or LLD... and deliver some approximated sequence diagrams just to please the architect. Then, they spent 3 months sort-of-coding with continuously changing standards, and trying to interpret the requirements.
They delivered, and the feedback from the client was "but this is not what we actually needed!"

The other was a PURE (pseudo)AGILE approach: just hack things, cannibalizing existing legacy systems without any analysis nor design nor clear attribution of responsibilities, leaving the developer entirely alone in deciding how to implement stuff, changing architecture, schema and strategies every week. No design, no analysis, just headless coding. The result was the typical big ball of mud http://www.laputan.org/mud/ , useless and unmaintainable, because it would lack coherence and solid design. People would dedicate a disproportionate amount of energy to discuss methodology issues, and almost none to address functionality issues.

What I learn from these 2 extreme experiences is: talking about methodology alone will not bring you anywhere, and is no substitute for good practices, hard work, commitment to quality, automation and good communication (verbal and written). At the end of the game, it's the quality of the people you have on board, and the effective way they cooperate, which matters.

Pure Methodologist sometimes/often are failed professionals. As a proverb says: those who know, do; those who don't know, teach. Or criticize those who do. The more often your people repeat the word "Agile", the more CPU cycles they are stealing from the actual resolution of your problems. You can't buzzword your way to success.

Too much stress on methodology mean, basically, that you believe that your team is made by kids from a kindergarden and that you must micromanage them otherwise they will never get anywhere. Macromanagement is good, micromanagement is bad. When I am asked to break down a task in its atomic components and produce an estimate for each one, with 1 hour resolution, something is seriously wrong.

Success is a hard to reach target; it requires rigorous analytical minds, experienced professionals relentlessly banging their head on the wall searching for the best solution, the best design, surfing through zillions of forums and documentation searching for a path to a solution, putting together solid POCs and working closely with the business.
It requires passionate, dedicated people, with solid scientific education and good moral values, integrity as a mission.

There is no silver bullet, no magic product, no wonder methodology.