And a lot of the flack agile has taken recently has been due to people focusing on what happens when teams adhere rigidly to the processes, to the detriment of the values, when it should be the other way around.
The problem is, that's how it's being sold. The perfect Platonic "Agile" may not have strict processes, but the in-practice "Agile" that comes with consultants and certifications and marketing does.
Like many other products, if the person buying doesn't actually understand the difference, the bad stuff will tend to drive out the good. This is not a problem of Agile, it's a problem of the people who choose to hire consultants and adopt methodologies.
It might be a problem for Agile -- it damages the brand -- but that'll be a problem for any set of principles in the same space. You're always going to need to keep your eyes open, do your research, and carefully employ both reason and lessons from experience.
> The perfect Platonic "Agile" may not have strict processes, but the in-practice "Agile" that comes with consultants and certifications and marketing does.
If you are substituting reliance on marketers and consultants selling canned processes telling you what to do instead of your engineers developing their own knowledge of what Agile is and applying it, then, yes, you will get some canned thing sold by marketers and consultants that has an "Agile" label stuck on it but which is the exact opposite of what Agile is -- since any canned, externally-defined, process sold across the industry by marketers and consultants is not only "not Agile", but exactly the problem that Agile was defined to solve.
OTOH, that's not a problem with Agile, that's a problem with outsourcing the basic function of engineering your own internal processes without developing internal understanding.
In an environment where employees stay with a single company long enough, consultants may be a valuable way of moving information between companies. I'm skeptical that much software development work sufficiently resembles that, though.
I'd not go so broad as that, though I tend to agree.
Bringing in outside consultation can help when the team is fractured, or when there's a disconnect between the team's needs and what management is willing to allow (that is, an outsider saying to management "Look, you've already agreed to be agile; that means you have to give the team autonomy to try this" can be more effective than the team saying "We want to try this"). But yes, there's a lot of snake oil salesmen, "Agile is good for what ails ya!"
The problem is, that's how it's being sold. The perfect Platonic "Agile" may not have strict processes, but the in-practice "Agile" that comes with consultants and certifications and marketing does.