I think it's worth linking to the original Agile Manifesto[1], because that's pretty much all the consensus you're ever going to get on what's "agile" and "what's not".
Lewis is right that most of these principles were described before the manifesto, but I can vouch for the near-impossibility in many contexts of convincing anyone who wasn't a coder (and a lot of coders too) why these might be sensible defaults.
For every person burned by a subsequent maladaptive formalization of these principles, there was someone horribly scarred before the agile manifesto by being forced to go through a doomed waterfall process.
No, you are not going to get that consensus, because middle management and hire ups don't want to know what agile actually means, but want to continue believing, that the processes they impose are agile, and they have probably never even seen that page. In a truly agile team, the team takes many if not all of their work and responsibilities, so that even the jobs of PMs and low middle management would be on the line. As we know it is difficult to get someone to understand something, when their income depends on not understanding it.
Yes!
Ask anyone with 30 years in the industry whether "agile", for all its problems, was a force for good or bad, and the answer will be an emphatic Good!
If nothing else, it gave us ammunition to argue against the impossibility of delivering a fixed thing in a fixed amount of time - which was the universal view from senior stakeholders of what competent software delivery looked like.