Basically the waterfall approach is intended to apply civil engineering practices to software

That's certainly one of the problems that causes the waterfall approach to fail:

• Mechanical engineering practices in general fail with software development because hardware deals with real, finite and deterministic units, measures and quantities.

  Software has few if any reliably measurable metrics;

• Even the most complicated of machines -- the space shuttle for example -- has a few million parts.

  Even fairly modest software projects can have 10 or 100 times as many 'parts'.

• Mechanical engineering projects can afford to spend big on development and testing.

  Infrastructural projects like roads, bridges, tunnels, railways, dams, houses and factories have serviceable lifetimes measured in multiple decades if not centuries; thus their development costs are amortised of those long lifespans.

  Industrial projects (turret lathes; tunneling machines; welding robots; aircon plant; windmills; aircraft etc.) amortise their costs over the production of millions of units of consumer goods or services.

  Consumer goods (cars; phones; light bulbs; printers; fridges etc) amortise their development costs over millions of units sold.

  Most software projects are one offs; and often associated with cost centers rather than profit centers. Ie. Administration rather than production.

• The specifications for hardware can most times be definitively written down.

  If a bridge is too short...; a plane doesn't have enough fuel capacity ...; a dam can't hold back the water ....

  Software is nearly always far harder to specify.

But that is far from the only reason:

• The single biggest problem with the waterfall methodology, is the belief by the analysts that they can construct a definitive specification up front.

  It has been proven time and time again that even the best analysts cannot fully specify anything more than the most trivial of software systems.

  And the moment you recognise that, waterfall is inevitably indicted as the root cause behind huge numbers of software projects going back 40 years or more.

• Waterfall 'works' in the same way that erosion works: it gets there in the end.

  But unless you're writing software that will not be needed for 5 years; and will stay in service for 30 -- and almost nothing does these days -- by the time it gets there; the world has moved on. Twice if not three times.

• Waterfall is a management heavy process from a bygone era of demigods and vassals. And it didn't even work well when that was an acceptable working practice.

  Anyone still advocating waterfall as a workable methodology in the modern world simply has no stake in anything real and current. They are living in a rose tinted vision of a misunderstood past.

• There are perhaps a few dozen projects that have the funding and time and reason to be developed that way in today's world.

  Aircraft & space craft control systems; nuclear power plants; medical monitoring systems; military projects. Projects with huge budgets, very long lead times and failure-is-death criteria.

  Your website, database, word processor, browser, compiler, PoS, phone, washing machine, even banking systems do not have either those kind of budgets nor those kind of reasons.

Better to get something working next week, find its weaknesses the week after and improve/fix them the week after that, and iterate that RAD process 6 times; than spend 6 months trying to definitively specify every last function and feature, and another 6 months getting to the point where you have something to test, only to discover your data gathering was flawed, your guesses were inaccurate, your assumptions wrong and your vision of what the customer needs is completely different from what they actually require.

But, you don't need stand up meetings or scrum masters or story boards etc. to achieve fast feedback RAD development either. Pretty much all you need is a customer's advocate with the authority to conduct regular, hands-on progress inspections; challenge decisions; and require changes.

Beyond that, there are many ways of running things -- pair working or peer reviews; tests first or mock-up and comply; continuous builds or weekly commits -- some are more appropriate to some types of software; others to others.

Strong technical leadership is good; overbearing micromanagement is bad; non-technical bean-counting counter-productive; automated bean-counting a piss-poor substitute for open and blame-free peer support and review.

Guidelines are good; blind adherence (to anything) is bad; manifestos, buzz-word compliance, cheat sheets and road-maps sops to being seen to be following 'the process'.

Waterfall has all the bads; and none of the goods. In either sense of that last word.