I feel like you're spouting Agile (TM) rather than https://en.wikipedia.org/wiki/Agile_software_development - Agile is not one thing, it's certainly not a checklist. There are general philosophies of software development.

The core is really adaptive planning and acceptance/flexibility to uncertainty, biasing towards shipping first. There is no requirement to be spending all day in endless meetings, nor an opposition to documentation. If more documentation increases velocity, why would that be anti-agile?

More importantly, what works for you does not discredit another team's agile approach. I lead large and growing teams rapidly releasing greenfield software. We are definitively agile, and documentation is empirically key to that process. Perhaps your experience differs. I don't discredit that, merely provide my experience in contrast.

I'll second the concerns at touting FrAgile (TM). Too many teams woefully underestimate the level of work yhat goes into maintaining the full delivery of product, and the fact that as you scale up, process has to be in place to keep people working independently without running into issues.

Waterfall's issue was that it stipulated there shalt be process from stage 1 before anyone even understands WTF anyone is doing. FrAgile(TM) is notorious for just cutting people loose and winging it, with no regard to system design, architecture and maintaining a cohesive whole over the entire process that keeps your business functioning.

You can't just NOT make SOP's you can't have an onboarding process that can't ne negotiated by the average person. Doing so is a recipe for burnout/churnout and failure.

So when you see, "Individuals and interactions over processes and tools." and, "Working software over comprehensive documentation." how do you square that with, "You can't just NOT make SOP's"?

Hm, what is your opinion of the Agile Manifesto?