Even with Agile and Scrum waterfall will sneak in

"Analysis, Specifications, Requirement, Design".

When people hear "waterfall" they imagine doing this for the entire project end to end. It's super risky to do this because nobody knows what they want until some of it is built. And if you just spent a year of a teams time building something and "tada" you show the user... odds are not in your favor that it will do what everybody actually wanted. Plus odds are good it might not work because there was no iteration to shake out the rough spots.

To me, the key for "agile" is rapid iteration. It's a bunch of mini waterfalls where every step delivers something of value (even if that value isn't directly visible to the end user yet). Each iteration forms a feedback cycle that helps make sure a team is delivering something the end user actually wants.

In practice I don't think anybody is actually doing "waterfall classic". It's more of a story we tell to remind us how important it is to get in the habit of rapid iteration.

(Sidenote: there is plenty of other reasons to rapidly iterate. The end project is built on a moving target. Business processes change over time, the competition changes over time, etc... if you have your specs 100% locked in at the beginning you'll find that half of them no longer apply after a year because so much has changed in your environment. There is also inventory costs of keeping so much code out of production for so long.)

So I'll start by saying I detest the snake-oil salesmen professional scam artists that are "Agile consultants", as they have now begun to leach onto DevOps which honestly is in large part has the same end goal of agile. These people are largely talentless hacks and parasites that extract value from coporations that are making money and then move onto the next victim while the actual engineers deal with the infection their ideas have left.

That being said the issue I've seen and read with waterfall is that it is very slow and cannot adapt very well. Which honestly is a super great thing in certain fields, like avionics, NASA moon landers, those kinds of things, because with this lack of speed and rigour you also get a certain level of assurance and quality and predictability, assuming things retain a certain level of consistency.

However in the world of newly emerging markets and the .com bubble and the new SAAS bubble being slow is a death sentence because at this point it is better to spray and pray because their are plenty of VCs willing to handle you fistfuls of cash to shoot at the wall because they are hoping to get in on the next big Facebook or Google (in reality now they are just hoping you will get bought by FB or Google which is another rant for another time.)

That being said agile offers flexibility and adaptability in return for offering less predictability. This causes a huge rift however when you have in house tech resources, that are part of a larger organization that needs all the assurances and predictability promised by waterfall, but the in house resources have to compete against SaaS opponents that management is all to happy to use a credit card to purchase.

The end result is tech teams saying they are agile by which they mean they respond to whoever is yelling the louadest and success is determined not by value but instead by politics and in the meantime no one is taking care of the customers because and you end up with everyone's data getting resold a dozen times, having more security holes than an Alabama "don't shoot at signs" sign, and companies spending several million dollars a year to keep some rusting old COBOL application running because it is the only thing they know for sure works right now.

Sorry I might've been unloading some baggage in this post.

Is it valid tho? Deploying an app to get feedback is totally backwards. Make an interactive demo with no-code tools, record it and iterate on that based on stakeholder feedback.

The thing I don't understand about agile is that many projects require a year+ investment before anyone will use it. e.g. say you're building a competitor to Google Docs. How do you get any real user feedback after < a year of work by a substantial team of engineers? No one is going to want to use your prototype that barely does anything. Or worse yet, your backend that doesn't even have a UI yet, and also barely does anything.

I've watched this video a few times, and I recommend the part at 25:43 which describes agility. To repeat it here:

1) Find out where you are 2) Take a small step toward you goal 3) Adjust your understanding based on what you've learned 4) Repeat

I think this is useful as a high-level guide, and it's both easily memorizable and generally memorable. I use a silly mnemonic "FI-TA-AD-RE", and I come back to it whenever I'm working and get to a point where I have to ask myself "What the hell am I doing?"