Another good article on Agile *
This article links to some things I say later on, like what are you talking about with these psychology experiments and ‘change smuggling’…
A few months ago I wrote ‘Agile vs French Dreadnaughts’ about my disdain for real-world agile. After working more in ‘agile’ environments and doing relevant certifications, I have come yet again to scream into the wind.
The agile values are great, but are just so fundamentally misunderstood or outright ignored in what they actually mean.
People seem to not understand something fundamental: if a team can collaborate, it will. If it can’t, it won’t. No amount of Agile, or an other project management methodology, can force it.
Everybody also keeps saying ‘you’re not doing it right’. It’s like communism: let’s just try it one more time. This time it’ll work! I’m sure of it!
So, let’s go over the values of agile, and why they are, in practice, not very good.
Individuals and interactions over processes and tools
This is the only value that is generally good in practice, because it’s ‘agile’ to not have anything standardised I guess. However, there has to be limits. When you have discussions and documentation spread accross umpteen different tools (or chats…), you end up losing things, and getting outdated and contradictory streams.
While you can have ad-hoc meetings and chat over lunch, you still need some structure and global tooling for organising and working. Lest you lose coherence and the big picture of what you’re building. Otherwise, it’s like saying the dev team uses c++, but everyone uses a different language version and compiler.
Speaking of people, during one of my agile certifications, I also felt what was sinister, borderline villanous behavior. We were literally being told to ‘remember that the people / developers are humans’ and ‘empower the lowest levels’. You have to be psychopathic to need to be told these things, or that you are ‘higher’ than the people doing the actual work. It’s completely against this value: if you have to be told to value ‘these peole’, it means someone doesn’t see them as people.
Working software over comprehensive documentation: Is everyone illiterate
I swear, every time someone says this, it means that they document squat. Every. Single. Time. That I have seen this, it leads to massive issues, not even far down the line. Even just weeks later, someone’s asking why something was done some way, or why X requirement exists. If you’re lucky, someone remembers. But if no one does, or you’re months later, you’re out of luck.
The reality is that so many decisions and system-level designs get lost to the void.
Don’t get me wrong, I understand what the value is supposed to mean: don’t get your feet stuck writing documentation that no one is going to read. But people in practice just seem to forget to write anything at all.
Customer collaboration over contract negotiation: How to make a failing business
This is the only value that I fundamentally don’t agree with. Even from the developer’s perspective, you need to make sure you do what is asked, and what is in scope. I’ve seen it, and I’m sure many other people have as well, where clients try to get you to go to the moon, when the contract wants you to dig a two-foot deep hole.
Now, okay, I get why it exists. We don’t want absurd levels of nit-picking, and basically nothing being covered in a contract, and every requirement ends up being an extra. But come on.
This goes two ways: the client wants what they paid for, and you want to do what you are paid to do.
Responding to change over following a plan: Being adaptive to a fault
While good in theory, in practice too many business people take it to mean throwing shit at the wall until it sticks. It is based on ‘changing market requirements’ and ‘changing customer needs’. It’s presented as trend-chasing: you will eventually fall off into irrelevance.
And people just don’t understand waterfall: I’ve worked with people that started their development journey with punch-cards. The idea that waterfall never ‘iterated’ or never got client feedback is completely ignorant. Work packages were a thing then, and considering an Agile’s increment any different is assinine. Clients signed off on statements of work then, and they validate increments now.
Regardless, in years of dev, I have never seen an actual ‘need’ change. It has always been a massive bugger up of requirements analysis.
A good example is at one job, when we had a sudden ‘stop the world’ moment. The business said that we were missing an absolutely critical feature. We needed to drop everything to finish it as quick as possible. No timeline was given, we were told to just drop everything else, and get something to market ASAP. A few months later, a very, very complicated set of features was finally delivered.
And nobody used it.
Months later, we learned that someone was told at a conference that they needed this feature to buy our products. Nobody thought to estimate how big of a client they would be, or to even ask any of our existing clients if this type of feature would interest them. To this day, I have no idea how this business decision was reached.