The Death of The Agiles

Many are touting the death of agile since like forever, the truth is, Agile wasn't ever alive in the first place.

Articles have been resurging about how agile projects fail at a greater rate than non-agile projects.

Leaving aside that the methodologies for these comparisons are dubious, at best, the fact is nobody’s measuring anything that matters. There’s plenty of bullshit about operational outputs (i.e., on-time, on budget, delivery of some garbage), but, as is always the case with even the agiles, outcomes for both business and customers are entirely overlooked.

The problem with the Agile Manifesto

Let’s go over the Agile manifesto quatrain, which, on its surface, is hard to argue.

Individuals and interactions over processes and tools:

Following rules (processes) or subordinating your system to using a specific toolset in software development for the sake of doing so itself is foolish. Processes and tools that aid in the interactions of individuals to make better customer and business decisions are great.

Working software over comprehensive documentation:

If our product is software, and that’s all these 17 men were discussing, software, then wasting time manufacturing documentation isn’t useful. Documenting within the code, such as writing code that’s self-documenting and explains its purpose, is great. Documentation of a software system that’s not yet been built is usually an exercise in futility as the specification is outdated the minute an engineer figures out something has to be done in a manner different from what’s been documented, and seldom do those changes end up being retroactively updated in any static document.

Customer Collaboration over contract negotiation:

Talking to your customers as you solve their problems and discover hurdles and opportunities in how you can or should solve them is far more useful than translating a customer’s half-baked idea into a contract with every possible caveat and risk highlighted. Contracts suffer similarly to how documentation goes wrong.

Responding to change over following a plan:

Did Von Moltke mean, “Planning is all bad, and you should never do it?” of course, he didn’t. But many agilists mistake the part of the quatrain to mean all planning is bad. See the #NoEstimates yahoos with their “It is in doing the work that we discover the work to be done” silliness. Planning is valuable, but sticking to a plan once reality has set in is foolish. I’ve always taught that’s what this means, and it’s been most unpopular with PMO executives.

Agile is just the latest in an unending series of well-intentioned process improvement approaches to collide with stage 4 metastatic capitalism.

At its core, Scrum is about creating strong, collaborative, self-organizing teams, reducing batch size to manage risk, and communicating directly with customers while visualizing work.

At its core, Kanban is just visualizing work while managing flow through limiting work in progress.

Both systems require empowering the people closest to the work and the customer, just as Lean, Total Quality Management, and other process improvement approaches from the last century have tried.

Ultimately, these approaches want people to pay attention and to stop allowing incoherent, politically motivated psychopathic executives to remove agency and purpose from the people ostensibly being paid to do the good work the organization claims to have hired them to do.

Why doesn’t any of it work then?

It’s easy to point at consultancies and blame them because they seem to come in and do all the worst things. Twisting the well-meaning intentions of these approaches into something more palatable to the ruling executives and less compatible with the values originally espoused. However, those consultancies are a symptom of the larger problem of authoritarian rule. More cooperatively structured companies would be somewhat less compatible with individual autocrats gathering power and making decisions for everyone.

It ultimately comes down to authority, power, and control.

Let’s look at the righthand column of this manifesto and why it’s so hard to escape.

Processes and Tools:

Individuals and interactions are harder to command than processes and tools are, and most of the wasteful processes and tools that are so popular and harmful are attempts to automate the reporting and, therefore, centralize control of those individuals and their interactions. Can anybody say “You didn’t log every hour in Jira?!” I knew we could.

Comprehensive Documentation:

“Comprehensive documentation” generally means' a bunch of garbage nobody’s ever going to read that’s wrong the day it was written,’ but it also means a degree of performative control for the PMO and, by extension, the leaders. We can at least pretend to have been tracking or reading these specifications, and if something doesn’t work later, we can use the documentation as a cudgel against teams.

Also, nobody, even the manifesto, can seem to define what the shit “Working Software” actually means. So on the flipside of the coin you get development-focused leaders saying “We don’t need to know what the business wants, we’ll just crap out a lot of code behind feature flags and then tell you what our unbridled brilliance hath wrought!”

Contract negotiation:

It is much easier to control because allowing engineers to actually speak to a customer cuts out the middle. Again, it’s entirely about control.

Every time I meet someone who loves Extreme Programming (XP) and tells me how amazing it was to do it somewhere, I always ask how they did the part where the customer is actively involved in the development process, and the answer is always, “Oh, we didn’t do that part.”

Except for the one hilarious executive (who did not support XP practices in his organization) who had some weird tick: Every time anyone said “XP” within his earshot, he’d inexplicably tell everyone, “I love XP. I even paired with Richard Stallman one time.”

Following a plan:

Obviously, the main reason you’d not want to follow a plan is when it’s failed to survive its first encounter with the enemy’s main force. Still, suppose you’re a psychopathic WW1 aristocrat commanding battalions of colonists in the trenches. In that case, you demand they follow the plan and go over the top no matter how many are mowed down.

Agile hasn’t failed; it was dead on arrival, just like Lean and other well-meaning processes that came before it.

I remember John Shook, president of the Lean Enterprise Institute and a really great guy whom I respect immensely, giving an amazing talk at a conference in New Jersey, where I also spoke. He told the story of bringing the Toyota Production System back from Japan and helping NUMMI adopt its practices. He explained how they’d been massively successful in a short period of time. I’ll never forget how he ended that talk.

”We were sure this would be everywhere in no time….and we’re still trying.”

Lean has fallen victim to the same problems. These days, you cannot even say the word “Lean” without someone adding a “Six Sigma” to the end. And few things are less aligned with actual lean principles than the dogmatic control framework that is Six Sigma.

The problem isn’t that we don’t know how to do work or even knowledge work well. Plenty of proven effective theories have been put into practice with great success. The problem is corporations, especially large ones, become authoritarian organisms entirely driven to enrich the few executives at the top. Everything else becomes, at best, secondary.

Until organizations change their structure and become more egalitarian, all frameworks that encourage transparency, autonomy, and coherence will fail in those organizations. This is also why the unnamed alternative process being implied in these ridiculous “agile failed 258% more than <amorphous thing we didn’t even bother to make up>” articles also doesn’t “succeed” a lot of enterprise success is luck.

Product-market fit, investment capital, right place, and right time contribute far more meaningfully than any process framework. As such, enterprises who’ve enjoyed all that great luck are often run by performative psychopaths who come in, pretend to change a bunch of stuff, and then leave with millions in compensation protected from any scrutiny whatsoever. The toxicity of stock market speculation protects many of these execs because boards of directors can never admit they made a bad call at the C-level lest confidence wanes and overinflated stock values plummet.

I’m not saying Agile helped or harmed these enterprises; I’m saying it doesn’t matter all that much. I’m not interested in hearing nonsense about “failed” projects until we define what a successful one even means.

Anyway, my .02c on this ridiculous recurring “Agile fails all the time” nonsense.