Lots of $%&#! Agile

Photo by Josh Applegate on Unsplash

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.

--

--

--

Solving Problems & Saving Time through Software and Crushing Entropy. Twitter: @EngineerJohnO

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Implementing Sign In with Apple in your Django (Python) backend

Localize your web application using DeepL API

How to build a REST API with gRPC and get the best of two worlds

Magento to Shopify: A comprehensive guide to migrate your store

A ‘Scope’ful of Syntactic Sugar

Applying PSPs to istio-cni-node pods

READ/DOWNLOAD< Modern Graphics Communications FULL

Meddy’s Tech Stack

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
John Obelenus

John Obelenus

Solving Problems & Saving Time through Software and Crushing Entropy. Twitter: @EngineerJohnO

More from Medium

Waterfalling The Timebox In Agile — Anthony Software Group

Manage vs. Agile — How to 💯 harm your agile work environment

Fragile Manifesto for Management by Stefano Sostak

Agile Software Development

Mission Impossible: Hire Scrum Master