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.
