"So far, only devs knew it was worthless"
The things devs *think* they know but wildly misunderstand could fill volumes (and create thousands of hihg-paying "cleaning up after the elephant" careers).
Conversely, I remember the waterfall days before Agile, when once requirements were signed off, the business and the engineers would essentially have no contact for 6 months to a year, until the inevitable "What the hell is this shit??? What?! It's what you asked for!" moment.
"Customer collaboration over contract negotiation" and "Business people and developers must work
together daily throughout the project" are a VAST improvement.
"The agile manifesto says that they [the developers] are the owners"
No. It. Fucking. Doesn't.
"Its stated aim: Continuous delivery to customers"
Wrong. The authors of the Manifesto state that they have come to value:
"Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan"
Wild idea out of left field: Maybe reading the Manifesto (for the first time?) before attempting to criticize it?
This feels a lot like talking to most Christians about the Bible. Ahem.
Even the "Principles behind the Agile Manifesto" states that "our highest priority is to SATISFY THE CUSTOMER through EARLY and continuous delivery of VALUABLE software". Big difference.
"Its method to achieve it: Via continually tracking and imploring developers"
Bullshit. There is no mention of tracking, reporting, or imploring, but it does say that "Working software is the primary measure of progress" -- not standups, not Jira statuses, WORKING software.
There are lots of actual problems with Agile, but none of them are mentioned here.
Agile done poorly or wildly misunderstood is not a valid indictment of Agile.
"Developers can game it in 2 ways"
So you're not really doing Agile; you're looking for ways to get around it and/or to cohabit with evil, i.e. an Agile process that isn't really an Agile process.
That makes you part of the problem.
Also, ALWAYS mistrust someone who narrows the available options down to two.
If you're having trouble, ask for help. Get better at writing user story, task, and defect descriptions, including objectively verifiable acceptance criteria and more than just the "happy path". Get better at estimation based on these more detailed story, task, and defect descriptions.
"There is no way a developer can win"
Horseshit. Consistently document problems. Propose solutions. Illustrate the cost of a poor process or decision. Bring it up in the Sprint Retrospective ... ahem. Take it up as high in the organization as you can. Do great work despite the poor process, and demonstrate the superior results. In the end, have the courage to leave a dysfunctional organization that shows no real interest in improving.
I've lost count of the number of times I've done this myself. Yes, it's been financially costly. But my soul is still intact.
"There is rarely a day for reading technical stuff, sharing it with the team"
Funny, I do this on my own time or during my day without asking permission or needing to justify it. When I was starting out (before the wealth of "how to" technical information on the Internet), I spent tens of thousands of my own dollars buying and reading expensive books so that I could actually understand how all this stuff works and fits together. I didn't expect my employer to "allow" it or pay for it.
"I am around, and still coding (Probability: 1%)"
Best news I've heard all day. Don't let the front door hit ya where the Good Lord split ya.
Unfollowing.
