I'm not saying waterfall is a good alternative. Waterfall is just as shitty as Agile, but one benefit is that wastes less of everyone's time with meetings and busywork. But waterfall is equally guilty of a one-size-fits-all mentality, from the opposite view of Agile, and this cookie-cutter property is what makes both methods attractive to bureaucracies.
I'm a fan of common sense. If it's clear in a given team and project context that two week sprints, story points, and frequent meetings are really going to help, then just do it. And when that stops working, just switch and do something else. When architects or researchers are telling you a given project direction needs to slow down for some more intensive piloting research, do it and don't hesitate to violate sacred Scrum principles.
This stuff should be figured out organically, based on the given project and given personnel. Never with a fixed mandate to a single prescribed method or time frame.
Continuous improvement of the process itself is part of any good agile process. Corporate buzzword compliance agile is often guilty of not doing that - the "cookie-cutter property".
But importantly, I've found that a refined agile process saves more work than it costs, by figuring out what doesn't need done before doing it, and prioritizing immediate value over future value. It's very important to be able to say "This is good enough for now, but we know it's not good enough for the future". It keeps the perfect from being the enemy of the good. Likewise, it's important to be able to say "Well, I guess that didn't work", and have it be an integral part of the process. Without process, you have no guidance over what wrong turns you took and what those wrong turns cost.
I dunno, what you say just reads like a bunch of buzzwords that Agile, even supposedly "refined" or "good" versions of Agile, never prioritizes or delivers. More often, when quality work is produced it's produced in spite of Agile, not because of it, which is a shame because then people falsely attribute that success back to Agile.
I admit though that it's hard to know exactly what you mean just exchanging textual comments like this, so I'm happy to leave it at that.
I'm a fan of common sense. If it's clear in a given team and project context that two week sprints, story points, and frequent meetings are really going to help, then just do it. And when that stops working, just switch and do something else. When architects or researchers are telling you a given project direction needs to slow down for some more intensive piloting research, do it and don't hesitate to violate sacred Scrum principles.
This stuff should be figured out organically, based on the given project and given personnel. Never with a fixed mandate to a single prescribed method or time frame.