I mean, if you use a process that's apparently fixed enough it's worth making certifications around it, it's quite likely not "agile" in both the dictionary sense of the word and in the sense of the agile manifesto.
The agile manifesto is so broad and vague, it is all things to all people, and therefore useless. As soon as you start transforming it into actionable items, in a non-working team, you immediately start getting capital-A 'Agile' abominations, because there are always capital-R 'Reasons' for why <your company's particular flavour of horrorshow> is having a negative impact on developer productivity. 'Reasons' that neither you, nor your team lead, nor his manager have any power to change, regardless of whether or not you are six-sigma-black-belt-scrum-master-rock-star-certified.
There's only two valuable ideas in agile, that are actually broadly applicable.
1. Do continuous integration.
2. If it doesn't make sense to do something, don't do it.
You don't need to get into philosophical discussions over the manifesto, and the purity of your adherence to agile philosophies, or any of that nonsense.
What you do need to do is to go and deploy Jenkins (Or whatever the new hotness is in the CI world), and don't build features that nobody needs.
As soon as you start transforming it into actionable items, in a non-working team, you immediately start getting capital-A 'Agile' abominations,
I think we should stop referring to those things as "Capital 'A' Agile" ( which isn't even an actual thing to begin with) and refer to them by their actual name: Scrum, Scrumban, SAFE, XP, Crystal, RUP, USDP, AUP, etc. At least we can try to make the point more clear that when we criticize these things, we're criticizing a specific "thing" and not some catch-all term. Given that there is no concrete methodology named "Agile" to actually criticize.
I work in an environment with projects for many different customers, and almost as many different approaches to coordination with the customer, and I'd say the points from the agile manifesto are quite useful to suggest and evaluate the process for a project. Can we get a proper quick feedback loop? Can I talk directly to people that actually know about the details? How does the change process work? How much overhead is there that's not directly relevant to doing whatever it is were asked to do? What kind of decisions do we need to stick to that have been made without/against technical guidance?
It really depends on the customer if that process is something that can't be influenced. Although of course we're as an external party often have more freedom in that regard than a customers direct employees.
