This is _exactly_ the problem - agile is never defined by itself, it is defined in terms of some desirable outcomes. Project was on time and succesful? Great victory for agile. Project failed? Need more agile in the future.
In my experience, all this is used as a smoke screen by management types who have no real idea what they are doing to externalize their own accountability.
In some ways that's appropriate, because nobody actually cares about being agile. They care about shipping working software on time. So the real essence of agile is asking "How can we ship working (or closer) software faster?", and adjusting your process in response. If you aren't at least willing to adjust your process, you aren't doing agile.
Replace agile word with that in your paragraph and it makes sense without sounding silly.
If you've done well you've probably learned and adapted.
If you havent done well, you probably need to reflect and work how to do it better next time.
Things arnt 'proper' agile when they are not about adapting but instead following a specific process your team cant change.
Cool, tell that to your "scrum master" next time you see him.
The key thing is that the changes have to make things better. You should be able try those things and see if they improve things.
Lots of teams use kanban, and some teams mob. If you mob as a team what's the point in standups?
What's the point in sprints, if your continously improving, continously releasing, continously getting feedback and able to forecast well without them? Your better than scrum in my opinion then.
Scrum is a bit basic these days, but it's a good baseline start from. Thats the problem with a lot scrum purists. They will never get beyond a fairly basic level of performance.
If you havent done well, you probably to reflect and work how to do it better next time.
In that case, you can also replace "Agile" with "Kung-Fu!" Actually, I'm serious. There are various anti-philosophies in art and the martial arts which say something like this.
OODA loop, plan do check act, kaizan etc
The core is the same.
Now the kittens do stand ups everyday and meow on cue. It's a success for management.
The software will be slow and buggy and do the wrong thing. If you find this out in month 1, then that's great. If you start with 2 months of careful planning to make sure you don't get it wrong, you'll find out it's wrong in month 3.
In practice I find retros to be a special place where engineers can vent their discontent and nothing will ever be done about it.
At the place I worked, we started with a pretty regimented scrum - Monday morning planning poker, fixed-length sprints, which were closed and groomed, etc. I hated that crap. There was also a tech lead bully that insisted on doing things his way, and would use the code review process to keep other people's code out of the system. It was a real death march. By the time we had the basics of the system running, it was a dozen layers of synchronous blocking code where simple REST requests would take between 2 and 60 seconds to complete.
Eventually the bully left, and after that we eventually wore our (non-tech) team lead down into getting rid of discrete sprints and planning poker, and the devs tended towards just 'working on the next thing'.
I think the biggest factors we had in our favour were:
1) The team lead (pretty much the boss, too) was not technical, so he had no choice but to leave the tech decisions to us.
2) The tech bully left us in such a shitty state that it became obvious we'd need big changes, rather than token ones.
3) We got quite a bit of rapport happening and eventually the team lead understood that we actually wanted to get the system working nicely. The devs also got better at pitching ideas, like why a certain large changes were necessary.
I can't imagine we would have gotten to steer the ship in any meaningful way without a bunch of factors lining up like that.
#1 was clustering similar sad faces.
#2 was as a team, agreeing on actions we could take on those clusters.
#3 was tracking how well we did on performing those actions.
If it's just venting, it's not overly useful.
I would try to fix the retros though or have some kind of alternative to allow the team to change the process.
Like other dogmas or ideologies, it's unfalsifiable. No amount of real-world experiments can invalidate it if the reason is always "that wasn't real Agile".
You throw out the rituals ("processes and tools", "plans") when they don't work. That's called a retro.
How do you know if you're doing it right? You'll have "working software". That's a pretty subjective idea, so you'd better have someone to help you judge that, i.e. a "customer".