I finally figured out what is wrong with criticism of Agile.
My brilliant friend Jeff wrote a piece on why we should drop Agile:
https://jeffdoolittle.com/2020/05/22/dont-disrupt-agile-drop-it/
This follows a recent trend of calling out Agile Methods for their failings. I too have written extensively about this topic.
But there remains a reluctance, at least on my part, to suggest that we forget Agile entirely. There are some good values expressed by the goals of Agile. No one, including myself, has quite captured what is wrong with Agile in a way I felt hit the mark. Now I know why.
Agile is not about writing software. For decades we’ve seen it applied to writing software. Agile is not about teams. For decades we’ve seen it applied to teams. Agile is not (necessarily) about how teams and people work. This is what we’ve been complaining about and it cannot be fixed. We’ve focused on the wrong thing because Agile has been focused on the wrong thing.
Agile is about the machine that builds the machine (which will be used to build the product). Agile is about the machine that makes the machinery which we we will then deploy to build the product. In other words, Agile is not about building the product, it’s about the factory in which the product is built.
Since software developers don’t think of themselves as “factory workers” we have no notion of a factory. We sometimes say “shop” so you could say, “Agile is about the software development shop, not the software developers.” But again, this would miss the point because software developers don’t have much of an assembly line mentality.
In modern web development there’s a pretty fair analogy to the assembly line. It’s common that there are dba/database functions that feed into a middleware function that feed into a services function that feeds a routing function that feeds a messaging and/or API function that feeds a client function. This could be viewed as an assembly line, but it would be a rather crud assembly line. It would be like an assembly line where each station assembled complete complex products before only passing the API on to the next station. Not a great comparison.
Because of this we just don’t have a good notion of the machine that builds the machine (that then is used to build the product). We operate the machine that builds the product manually with minimal automation of that machine. In part this is because that “machine that builds the machine” is often built by the vendors. If you’re a .NET developer and use a code generator, it was likely written by Microsoft. It’s even this way for the open source front-end developers. They rarely contribute to the builds of REACT or Angular, etc.
Agile was originally developed to facilitate improvements in the machine that builds the machine. To improve the assembly line, not the cars or whatever was being built. It was (correctly) believed that to improve the cars you had to improve the assembly line. In fact, the original intent of Agile’s “stop the line” meant to “stop the assembly line” so that it could be examined and fixed so that the assembly line could be made to make cars better.
No wonder our notion of Agile is so messed up. We have little to no notion of an assembly line and our entire process is pointing at the car and saying, “We have to make that better.”
Wow, talk about “cargo cult culture.” We’ve invented an entire narrative about how a process for the assembly line applies to output product, and then built a process of rituals around that.
