TL;DR Annoying processes and tools, often established as a quick fix, are symptomatic in this industry and “commercial Agile” is only one of the symptoms. To discredit “inappropriate usage” often requires developing an understanding of the offending process or tool that typically goes far beyond what some of it’s proponents are willing to develop. And even when you make a well argued case for “you are doing it wrong”, you’ll often be countered with “I’m just doing what he/she/it told me to do”. Bad implementations don’t invalidate the core principles.
Many of the deployments of SCRUM would be in trouble once they were scrutinized for the “individuals and interactions over processes and tools” value under the agile manifesto - i.e. in many places SCRUM has become the Process for it’s own sake and no longer serves to enhance interactions to allow individuals to contribute effectively to the project/product.
In my view the scourge of “commercial Agile” is only one of a number of constantly mutating symptoms that have been manifesting themselves over time which I believe comes from the divergent mindset between “makers” and “managers” which is alluded to in Paul Graham’s Maker’s Schedule, Manager’s Schedule.
In this particular case, “meeting” is a tool that is well understood by managers - they gather information during meetings (information which is often researched independently by other attendees) and they delegate work during meetings. So to some managers “meetings” is how work gets done. But of course meetings simply route work. If the right work gets routed to the right place things get done, otherwise things can devolve rather quickly, especially when all that routing time eats into the working time.
Frequent meetings also appeal to some managers because it gives them the illusion of being more in control, not having to trust their makers as much.
So in my view SCRUM is something that some management can easily get behind because all those meetings keeps matters in their comfort zone.
In some cases there is also the desire to have “Process replace thinking because then non-thinking (cheap and easily replaceable) drones can handle this incidental part of our business”. That motivation seems to be a factor with the adoption of a lot of shiny objects in our industry - sometimes it even becomes a key part of a new product:
Go lang - language design
Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical.
… it’s more important to make a relatively “cheap” workforce “productive” rather than having a workforce that creates professional and mature products?
Another example outside of “Agile” where valuable insights could be buried under problematic adoption:
Ted Neward on Web Services and Security (2005)
Start from your code, just sprinkle some web service magic pixie dust on it and lo and behold you have a web service, bad things, bad, bad, bad, bad. I need to beat the vendors over the head to stop doing that
Basically that “magic pixie dust” dust enabled a run-of-the-mill programmer (prone to the “leaky illusion of local/remote transparency”) to deploy a webservice without ever really having to bother to find out what makes a well designed webservice.
This of course escalated to the frenzy of SOA-tooling which ultimately collapsed in 2009. Ironically important strides where in fact made in service oriented design but for the longest time that experience was tainted by association with the period of SOA-tooling - to the point that some people need to be reminded that these same design principles also apply to the now-hyped microservices.
Also hype or popularity rarely foster actual understanding. Once the SOA-tooling collapsed, attention focused onto REST - but many people still associate REST with JSON over HTTP, pretty URLs, something cranked out by swagger, etc. - rather than something based on the 4 core concepts of resources, their names (URIs), their representations and the links between them with the 4 core properties of addressability, statelessness, connectedness, a uniform interface.
The point being, something can be valuable at the core, be it the values of the agile manifesto, service oriented design principles, REST, etc. - there simply is no guarantee that people will make the effort to truly understand the fundmentals, nor is it guaranteed that somebody won’t come along and turn it into some cookie cutter process or tool (typically but not always for profit) that can be misapplied to all sorts of situations.
Unfortunately it often is far easier to apply a process or tool than it is to acquire the wisdom to know when it is appropriate to use it.