Lots of $%&#! Agile
16 Feb 2019
Everywhere I turn today there is something about agile. Lots of agile acronyms and names I’ve never heard before. People look at me like I’m supposed to know that one. And that other one, too. Who has time for all this agile?
I remember hearing about the agile manifesto a few years after it came out. It isn’t full of process declarations like some folks are telling me about the new WhizBang agile they’re doing. What happened?
Martin Fowler’s gave a talk this past year, that was mostly about his reaction to the last fifteen years. He calls it the “Agile Industrial Complex.” There are a million different practices that call themselves agile, some of which—according to him—ought to be called “faux agile”. Frankly he gets the right to make that call.
Fowler added that he finds himself, and those pushing some form of agile, complicit in all this. He stepped up to address it and fight for the spirit of agile, for the principles they stood for when they penned their manifesto.
Agile’s bottom line is actually about the business of management. Its first principle is: self-organizing teams. So, when a large organization decides to “adopt agile” and change over their titles and processes all the employees are now subject to a process foisted upon them. I would not call that“self-organizing”. Agile was precisely a reaction against that sort of management. It was making sure that those engineers who were doing the actual work were deeply involved in the conversations about what work was important, and how it ought to be solved, and what success actually looked like.
Agile was not intended to be another layer of management. It was not meant to be the next process that got management a higher quality Gantt chart. Furthermore, agile has very little at all to do with technology or software at all! There is even a quote from signatory, Chad Fowler (no relation), way back in 2002:
Agile methods are less about software construction and more about humans working together and communicating. No matter what field you’re in, there’s something to learn here.
Here is an mental exercise as proof—swap “software” throughout the manifesto text with any other noun you’d like. Go ahead, I’ll wait.
Agile has nothing to do with the career, calling, craft, or enter any adjective you’d prefer, of being a good Software Engineer. Agile is about the business of management. Furthermore it is about Engineers being directly involved in management. Anything less than that should not, according to the manifesto, be called “Agile”.
Python core development will never “be agile”. New architecture styles (e.g. distributed event platforms like Kafka, or distributed column stores like Scuba/Retriever) have nothing to do with agile. V8 engine core improvements have nothing to do with agile. The next version of ReactJS will not be built using agile techniques. The creation of distributed Map-Reduce at Google had nothing to do with agile. The firmware that ends up on your HDD chipset or BIOS or motherboard will never have anything to do with agile. Neither will your printer or USB drivers. Problems that are highly technical have nothing to do with agile. Software that inherently takes a long time to make because the problem is brand new at a scale we have not encountered before has nothing to do with agile.
If you follow any of those projects listed, or any other projects I could have possibly listed, just because they “aren’t agile” doesn’t make them “bad”. I don’t even know what that statement would mean—it is a category error. Just because it “isn’t agile” does not mean that they aren’t pivoting to more important problems to solve as things come up. It doesn’t mean that they’re not listening to their users. Meanwhile, these projects that are open source are, in fact, self-organizing teams. Teams made up of only Engineers. [Aside: if that doesn’t fit the definition of agile according to the manifesto I don’t know what does. But I doubt anyone on these projects would ever self-describe them as “agile”, so we also shouldn’t force the term onto them.]
Agile has a purpose, and I applaud it. But let’s not be religious; it’s not for everything. It is not a universal fix you apply. It isn’t a checkbox on a list that needs to be marked. Don’t turn to Agile as a savior. Only an organization interested in maturing can succeed at being self-organizing and involving Engineering in business decisions.