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!!
Top comments (13)
Agile CAN be defined : agilemanifesto.org/
4 values, 12 principles but you'll never see any rule.
Scrum is not Agile, Agile is not Scrum (btw scrum was created in 1995 and Agile manifesto written in 2001).
Scrum is not even a methodology, it's a framework.
Great points, but you can ask 20 million developers what Agile methodology they're following, and I suspect 20 million will answer "Scrum" ...
So blame Scrum not Agile 😉
Hehe :D
I remember my original fascination for XP back in its early days. The pair programming parts was simply amazing for knowledge sharing. Then a couple of years later (think early 2000s), I adopted CI, which blew me completely away due to its ability to easily fix bugs and get instant feedback.
Agile , and its associated disciplines, has a lot of going for it - However, Bruce Lee was right when he said "No style is better than all styles" ...
Which is kind of the point with my attempt at creating the "whatever works" idea ...
Indeed but self improvement is part of Agile too 😁
"At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly."
There are Indeed numerous methodologies, Agile or not, with benefits but in the end of the day what I really don't wan't is to go back to waterfall. Even if some teams fails in application of Agile values, Agile strenghtened us as developpers in companies by giving us autonomy and by placing us in the heart if the system.
Try the "whatever" methodology, you'd be surprised at how efficient it is ... ;)
Indeed ! A self organized team, a working software, responding to change. That is Agile 😁
I've always been a fan of "agile", in the original sense, software development. Finding workflows and methods that work well for any given project at a given stage in its development, and just overall being focused on getting actual work done.
Agile, as a methodology, has never really appealed much to me. Every look I've had at it has given me the impression that this was once something that worked for some people, and then had to be formalised to make it more appealing to management people.
Nothing in agile sounds necessarily bad, if taken more as a sort of tool belt. But in the end, responding to the necessities resulting from the current reality of a project should always be more important than the rules of some methodology.
"""Agile""" just seems like a scam to me.
Note: When I say """Agile""" is a scam, I'm primarily talking about attempts of over-formalising it into a strict methodology for the purpose of selling books, courses, etc.
Or, had to be formalised because people are lazy and want easy solutions ...
Word!
I saw the LinkedIn thread, and its typical tone policing and toxic positivity.
LinkedIn is such an hostile place to write.
You try to say something but no real discussion of the substance is possible. After all it's a social network, so people are here mostly to waste their time ; but also to sell something in front of many strangers, which is not a great settings for conversations ; anyway everyone scroll down very fast on their smartphone and you have only the two first lines in the post to create a strong impression, so better use click bait if you care about being read.
100% spot on, this was exactly what happened. In fact, most of the sceptics literally had "Agile Coach" as their description :D
To be fair, I hate so much being on LinkedIn that when I am there, the only reason is that I'm trying to sell something. And you can be in selling mode or in discussion mode, but both at the same time, that's tricky.
The important thing is the contract. Agile is not serious business just a social game to make people happier and boost morale. Ask yourself how does it map to a statement of work contract? Back-log I have seen with 2 years of tasks stalled. I don't care about the methodology, I care about what has been agreed upon to be done; real work which brings benefits and gets you paid. If people are paying me to appear and do work, that's what I do. The methodology is just an additional record, it isn't an official document. Also, to implement such a methodology, the tasks have to be 4-hours-ish. A task estimated to be 1-week is not really a task. It is hard to implement the methodology and sometimes people think it's just a matter of setting up a board, couple of columns and a back-log. It requires discipline.