FWIW I’ve worked at 6 companies that say “agile - but”. Every one of them pollutes and distorts what agile means and not a single one of them actually tried to be really agile. This is something of a “no true Scotsman” response, but I don’t think you can say agile doesn’t work if you don’t actually practice agile.
So send out a BA to get the user stories to redefine failure and open a ticket.
This is the best summary I could come up with:
Even though the research commissioned by consultancy Engprax could be seen as a thinly veiled plug for Impact Engineering methodology, it feeds into the suspicion that the Agile Manifesto might not be all it’s cracked up to be.
One standout statistic was that projects with clear requirements documented before development started were 97 percent more likely to succeed.
“Our research has shown that what matters when it comes to delivering high-quality software on time and within budget is a robust requirements engineering process and having the psychological safety to discuss and solve problems when they emerge, whilst taking steps to prevent developer burnout.”
A neverending stream of patches indicates that quality might not be what it once was, and code turning up in an unfinished or ill-considered state have all been attributed to Agile practices.
One Agile developer criticized the daily stand-up element, describing it to The Register as “a feast of regurgitation.”
In highlighting the need to understand the requirements before development begins, the research charts a path between Agile purists and Waterfall advocates.
The original article contains 501 words, the summary contains 175 words. Saved 65%. I’m a bot and I’m open source!
We have to ask: actual Agile, or micromanagement with made-up numbers?
But the fact we have to ask is not better news.