There is no "right" way. There is what we did and the results: successes and failures. How teams respond to these outcomes seems to come almost entirely down to leadership and the team and have little to do with "agile" or not.
Too many people try to attribute the principles of the agile manifesto to the practices of "Agile". I don't see the relationship most of the time.
There is what we did and the results: successes and failures.
I’d consider that OK, it’s how software development works. I don’t have that much experience to make general judgements, but in my opinion agile does not try to offer you a recipe for a successful software project. Because such recipe simply does not exist. Agile just tries to guide you away from some obvious and tried wrong turns (like relying on processes too much). The rest is up to your team and your customer, and there are bound to be both successes and failures.
I used to defend "Agile" against the "haters" in much the same way. As I gained more experience I began to see that most of what people claim is "Agile" is just prescribed processes trying to hitch themselves to the manifesto and the community it started. They have little bearing on what is or isn't agile though.
Scrum is scrum, if you like it fine, I don't. XP is XP, and so on. Each does in fact try to offer up a recipe for successful software projects. But there is no such thing as an "Agile" process. So, try to embody the principles and it may help you to be a better, smarter software developer, but even if you do it may be of little to help to cure a dysfunctional team or business.
Too many people try to attribute the principles of the agile manifesto to the practices of "Agile". I don't see the relationship most of the time.