Hang on, don't blame the agile manifesto here. Blame the management that adopted the agile manifesto as "do all the exact same things we used to do that didn't work, but call it 'agile'".
I totally can, and will. It's on them if they popularized slogans that can be too-easily misunderstood. That's meant that agile, in several respects, has been an exercise of throwing the baby out with the bathwater.
> Blame the management that adopted the agile manifesto as "do all the exact same things we used to do that didn't work, but call it 'agile'".
We’re now at a point where the widespread and rampant destruction that’s been wrought in the name of agile is so bad that it’s not reasonable to say “oh you’re not doing it properly”.
That excuse could be used to avoid responsibility for literally anything.
Hype bros use that to defend token scams (“you just don’t get it”).
There’s an increasing mountain of evidence that shows agile just doesn’t work, makes things actively worse by forcing the creation and then concealment by neglect of engineering problems, and (as discussed above) actively reduces documentation so that agile cheerleaders can pin their incompetence on the engineers that inherit their mess when they cruise on up the ladder oblivious of their failures.
All of this and not a shred of empirical evidence, ever, that it actually achieves anything other than obscuring management stupidity.
> There’s an increasing mountain of evidence that shows agile just doesn’t work
Do you have any keywords I can search for to find this evidence?
I haven’t looked at in in ~4 years, but the Project Management Institute (PMI) used to publish some reports based on surveys that said ~70% of corporate projects fail. I am interested in comparing the evidence you’ve seen with the evidence the PMI has put together.
Edit: I think the language is “70% of projects fail to realize the planned benefits”
I haven’t looked at it in years, so I could be way off. I believe that projects that are completed 2 weeks late are classified as failures the same way a project that is abandoned half way through is.
Good ol’ intent vs impact. If you’re proselytizing something, it shouldn’t be judged by your intentions or how true it is, but the impact it has on the world. Agile was not great in that regard.
If I hear that damn mantra again, I'm going to puke. Xtreme Programming had it right
If you aren't writing the damn manual, you aren't delivering an entire dimension of product to your user.
I sat down a little while ago to an old 80's handheld digital business organizer. The device itself was meh.
The manual tho! My God, I'd forgotten what it was like to read a primer on a product that had actually had some effort put into it. People think UX replaces training/SOP's/manuals, and it really doesn't. Your manual is how you mass produce user expertise. Your manual, at least by consumer's opinion is the difference between Yet Another Agile Heap Of Kludged API's and Business Processes and a truly coherent whole.
The problem with most Agile extremists though, is they never take Minimum viable documentation to heart. Or they completely externalize the cost of clear, complete communication to the User. If I had to put my finger on why, it would be because Engineering spends too much time writing and not enough time using their code outside of bench testing.
This isolates from the consequences of poor decisions; and prevents people from facing the One Great Problem of Humanity: Communication.
Keep a bucket handy, because you are going to hear it again, because it often isn't. The fact that a million people are acting entirely contrary to the spirit and text of the agile manifesto, but calling it agile, does not change that.
>> If I hear that damn mantra again ... never take Minimum viable documentation
> But... you're not doing it right. Like, not at all.
Nope, sorry. You can't honestly say someone's doing it wrong, especially when "it" is defined so vaguely, or when "doing it wrong" seems to emerge from the document at least as much as "doing it right," if not more so.
> Where on earth do you get "don't provide user manuals" from the agile manifesto?
Where do you get "provide user manuals" from the agile manifesto"? The problem is that it's most easily read as a rejection of documentation, in general.
> Working software over comprehensive documentation
and use it as a reason not to do documentation at all. It's ambiguous, and can clearly be read as "you should not work on documentation when there is software to work on", and there's always software to work on.
It's perfectly OK to blame the agile manifesto. Part of the issue with the agile manifesto is it was written by developers, which makes it sound credible. In addition, you have a lot of cult adoption by developers, which made it difficult to refute. Once law is written in stone and some boundaries are established, that's when business processes come in and do what they do best: see how to manipulate their actions around that language to get what they desire from what is accepted/legal. They tend to always find paths around the bounds that lead to new undesired behaviors.
I used to run public community driven online video game servers in a different era and they were quite popular, sometimes the most active/hearts in their communities. One thing I always struggled with was writing down rules for player behavior on the servers. Once I write a rule it does two things: establishes what NOT to do explicitly, but opens a huge gray area of what isn't explicitly defined that can be done or opens up a subjective gray area that shouldn't be done but is not clearly defined. I now have to enumerate everything I don't want people to do which may be a massive list if you want clarity and no ambiguity. People get creative, always, and find new undesirable behaviors within your rule framework.
In the end, when you write some base rules, the only real solution is to continually ammend the bounds of your rule system over time to adapt and adapt, leaving less surface area to attack. This is why the US legal system is so darn complex. Basic constitional laws are established, some explicit don'ts, some explicit dos, and everything missing becomes questionable. I didn't want to do this on a video game server because... it's a video game server, nor did I have the time. I instead took the "it's private property and I am the tyrrant approach" and wrote a very simple rule to play with etiquette, then ruled over the server benevolently (at least I think so, joining anonymously for occasional sampling to adjust some server settings I found being abused and never banning people just because they were unenjoyable to play with) and it worked well. The servers remained the most popular servers.
The agile manifesto never adapted and business leadership is who calls the shots. A culture said let's adopt this and businesses said ok, sure, then this is how we're going to interpret these poorly defined bounds. You said this is what you wanted and everyone agrees so here you go. For the US constitution, vagueness and broadness works well because it was designed to be a living, extendable, changeable document. The agile manifesto is not. Given how well businesses skirt around the meaning of law to do legally, ethically, and morally questionable practices, what hope does some silly manifesto with no teeth someone writes have? Business rule as small little hierarchical dictatorships with tyrants ontop within a democracy and I've found the characteristics that compose leadership is often the opposite of benevolence. Be careful what you ask for in such environments, your requests will be twisted against you.
Hang on, don't blame the agile manifesto here. Blame the management that adopted the agile manifesto as "do all the exact same things we used to do that didn't work, but call it 'agile'".