> In that: if it fails, it is only considered evidence that you were not doing it enough.

I think you are purposely omitting the fact that those failures have root causes that come from violating key Agile principles.

Things like "we started a project without a big design upfront and we accepted all of the product owner's suggestions, but whe were overworked and ran out of time, and the product owner refused to accommodate requests, and when we finally released the product owner complained the deliverable failed to meet the requirements and expectations".

This scenario is very mundane and showcases a set of failures that are clearly "not doing enough Agile" because it violates basically half of them.

> The solution can never be at fault, it's your execution, or your devotion to the process (in this case) that was faulty.

Agile is a set of principles focused on the process and its execution. What compels you to talk about Agile and pretend that processes and execution are anything other than the core topic?

If your stakeholders change requirements but don't change allocated resources and fail to stay up to date in the daily affairs to monitor and adapt, how is this anything other than glaring failures to adhere to basic Agile principles?