The Agile Community is the Priesthood of the 21st Century

Yesterday I shared my thoughts on LinkedIn about agile. I typically get one or two likes on my LinkedIn posts, if I'm lucky a couple of comments. But this post has 38 likes, 94 comments, 6 reposts, and 4,364 impressions. I posted it less than 20 hours ago, so that's kind of a "big deal" for me on the platform.

About half the comments are from individuals trying to save what I perceive as their "holy cow", while some few are from people obviously having been burned by Agile, and largely agrees with me. People tend to comment more if they disagree, since it's a part of the human condition to try to save that which you love once it's endangered - So the comments doesn't necessarily reflect people's actual opinions. Something I am sure most psychologists would agree with me on.

However, a small LinkedIn post is not really the right venue for explaining deep thoughts and complex opinions, so I thought I'd write up my reasons for writing what I wrote here, to such expand upon my reasoning for speaking my mind.

1. Agile cannot be defined

The word "Agile" literally means "flexible". The result of its meaning becomes that it's by the very definition of the term impossible to define. Once you define it, it's no longer "agile", because according to the term "agile", you're supposed to "adapt". Agile is full of assumptions and rules, which prohibits you from adapting once you've bought into it heart and soul. Below are some examples from Scrum, one of the most famous Agile methodologies in the world today.

Use backlogs
Use velocity points
Create user stories
Have standups
Etc, etc, etc

The above set of "rules" that most are expected to obey by, makes it everything but agile. What if I don't want to have standups for instance? Does that mean I'm not "agile"? Agility means "having a flexible ruleset". Not having standups is probably a violation of Scrum at some deeper fundamental level. If not in its exact wording, definitely in its actual implementation. How do you think the average PM would react if I entered a meeting with him and the rest of my team and said; "Starting from today we'll drop standups". I'm fairly confident in that both the PM and the rest of my team would object and inform me of that this is in violation of Agile at some level. Whether or not it actually is a violation or not is besides the point, the point is that most people feel it's a violation, because accountability, orchestration, and planning is kind of a big deal in Agile, and standups have historically been declared as the means to achieve this.

This oxymoron isn't unique to Scrum, you will find similar rules in eXtreme Programming too. I'm sure at this point careful readers will object and inform me about how you're supposed to modify the process if it doesn't work. For instance, XP has a rule that says "fix XP if it doesn't work", which kind of works like a safety guard in case the process needs changes. However, this is an opt out few applies, because they simply want an easy solution for how to manage their software development projects, so they tend to swallow the pill whole, without considering what parts of the pill is actually good for them or not. So even though you're in theory correct to object here, in practice you're not entitled to object.

The Tao Te Ching explicitly states the following.

The Tao eludes definitions, because once you define it it's no longer the Tao

In fact Tao Te Ching goes even further, and admits it's got thousands of names too, and that no names are better than the next name. The closest thing you come to a definition of the Tao is that "it's very, very old, and was here before all things".

Agile software development have a similar oxymoron at its heart, because once you define it, it's no longer Agile, but rather something else. Agility can no more be defined than the shape of water can be described. Therefor, when asked what software development methodology you're using, you might just as well answer the following.

We're using the Tao as our software development methodology

The observant and intelligent recipient would purely logically have to reward you for actually being more honest than those using Agile methodologies, because at least the Tao Te Ching is honest with you, and tries its best to escape definitions, shapes, and forms of any kind. Hence therefor, "The Tao methodology" would by the very definition of the term be more "agile" than Agile, and also easier to adapt, since there exists no pre-defined assumptions about what it's about, allowing you to follow the only software development methodology I personally think is honest, which is as follows.

Whatever works!

2. "Whatever works" is better than Agile

If you want a better alternative to Agile, based upon Tao, we could try to formalize "The Whatever Software Development Methodology". However, its only definition would be as follows.

Whatever works!

Even "whatever" have definitions, because in it lies the assumption of that it must work in order to be useful. So the "whatever" methodology wouldn't be 100% perfectly Agile either, since it assumes a process needs to work in order to be useful - But it's a much better and more agile methodology than Agile.

3. Agile is an oxymoron

The above problem results in that Agile is an oxymoron, impossible to define, and hence holds the same position amongst software developers today as dogmatic and superstitious religious beliefs used to hold for our priesthood 1,000 years ago.

For instance, don't agree with another person's definition of Agile, or want to argue against somebody having bad experiences with Agile, redefine it, and inform your fan base of the following.

That's not true Agile, this is how Agile is supposed to be implemented

At which point you'll be "forgiven your sins", and allowed to demolish yet another software project with dogmatic and superstitious beliefs, who's purpose it might sometimes seem is to destroy everything good in this world. I've literally had to defend myself in debates where the other party proclaimed that the project failed because, and I shit you not ...

It failed because you didn't use gummy bears to measure velocity points

Agile made itself into the laughing stock of the future, the same way debates in the 12th Century Catholic Europe turned itself into the laughing stock of today for debating for 3 weeks whether or not Jesus owned a purse or not. "That's not true Agile" is the same argument as "That's not true communism". Sorry guys, I don't have time for these debates, because I'm too busy following the "Whatever Methodology" ...

Agile is a scape goat. You can put anything into the word, and be given redemption for your sins. Because regardless of how stupid your process is you can find some ridiculous Agile methodology giving you excuses for proclaiming it - Something the above gummy bear velocity points measurement idea perfectly illustrates.

4. But Agile works, how do you explain that?

Well, communism worked too, because it was better than dictatorship. This doesn't imply communism was "the end of the argument" anymore than democracy being "the end of the argument". Even the champion of democracy, Winston Churchill once said "Democracy is a terrible governing form, but it's the least terrible form we've ever tried". To avoid turning this article into an argument about democracy, I'll avoid the temptation of creating an argument to Churchill, but you can kind of intuitively see where I'm going by extrapolating my Agile counter argument below ...

If Agile is the least terrible software development methodology we've tried, this doesn't imply it's perfect, or the end of new software development methodologies - It simply implies we haven't tried what's better than Agile (yet!)

However, the "Agile Priesthood" will of course rush out to save their golden cows if anybody even dares to go closer to the above argument than a thousand miles. If you want my explanation of why Agile works, you can find it below.

Agile worked because IBM were idiots. For crying out loud, they had corporate policy for the colour of your sock holders back in the 1960s. Being "better" than IBM in the 1960s is no more an achievement than "being better" than Stalin was an achievement in the 1970s.

5. If Agile is no good, what's good then?

I have no idea, and paradoxically I'll need to quote a religious teacher here to help you on your way to figure it out for yourself.

The story of the Wise Man

A wise man was once confronted with a stranger in the desert. The stranger asked the wise man "how many days do I need to walk to Mecca?" The wise man answered "GO!" The stranger was upset by this answer, and repeated his question several times, but each time he was given the same answer "GO!"

Finally the stranger gave up and walked towards Mecca. When he had walked for 200 meters the wise man shouted after the stranger "you'll need 3 days to get to Mecca". The stranger asked the wise man "Why didn't you tell me before?" At which point the wise man answered "I had to see how fast you're walking before I could give you an accurate answer".

If we're to use the above to our advantage and create a software development methodology that's better than Agile, the only remaining word we're left with is as follows ...

Whatever ...

Use the "Whatever Methodology". Purely logically it's more agile than Agile, and it's almost impossible to end up with something worse than Agile - Because Agile is fundamentally broken. Just because it's "better than communism" doesn't imply it's good, it just implies it's "better than communism", full stop!

Now GO!!

Have a Custom AI Solution

At AINIRO we specialise in delivering custom AI solutions and AI chatbots. If you want to talk to us about how we can help you implement your next custom AI solution, you can reach out to us below.