It's not just management that gets into cargo culting. And it's not just "top-down" that results in pain in an agile working environment. Sometimes "bottom up

It's not just management that gets into cargo culting. And it's not just "top-down" that results in pain in an agile working environment. Sometimes "bottom up" can be a shitshow too. I've (tried to) work with developers (special-grade assholes) who were quite far up their own orifice at using the language of "Agile" processes in an adversarial but socially point-scoring way. To beat other people over the head, and even harass people out of their jobs (including management), implying that anyone who isn't doing what they say, or providing continuous, detailed arguments why not, is doing software wrong - while producing mediocre, low-effort, low-results work themselves. That isn't Agile, but I have seen the language of Agile used to abuse and pressure in a seriously uncool way. So I'm personally a bit cautious when I hear Agile advocacy from individuals, until I learn what they really mean, and how they use it. Among other things, I listen for whether they have a working empathy gland, and use their tools and knowledge to lift up people they work with, or knock them down. I've also seen it used to ignore proper handling of PII (GDPR-worthy personal data), via the principle "everyone is equal in the team, so should all have access to production data". Naturally this causes tensions, when some people pay attention to PII issues, and some would rather ignore them, perhaps disagreeing about how important it is, or perhaps just sloppy. (Related, I've observed a really interesting dynamic between privacy advocates and anti-privacy advocates.) And the same with other quality-control issues when the level of care varies considerably. At the same time, some people are very happy in their agile teams, and report that the rest of their team seems to be as well; and they are constantly shipping good work. It seems to be working for them. Between all the things, I have the impression that some people's "Agile" approaches risk a "productivity feel-good illusion", where the perceived productivity over weeks and months feels great, and there's a happy buzz in the team, but long-term business-affecting output is sub-par because the feel good factor and constantly doing useful things misleads people into thinking they are operating at the best they can be. And yet, it's not like planning everything, or top down direction changes from the business arm, makes for particularly good results in software either. Since it works really well for some, and is used as a tool of abuse by others, I'm neither for or against "Agile" as such, and instead, prefer to look past the buzzwords used by each company and team, and look at what they actually do each week/month, how the individuals feel (not just "the team" but each member), and what sort of results over time they are producing (measuring strategically useful outputs, in addition to whether they seem to be busy and happy). I think the principle of developers deciding themselves how to develop is an excellent one, to the extent we can encourage and assist that. But when developers are in conflict with their peers, and using the language of "Agile" as part of conflict or even abuse, it can be quite messed up, and may need an intervention from above.