421
Study finds 268% higher failure rates for Agile software projects
(www.theregister.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 05 Jun 2024
421 points (94.5% liked)
Programming
17351 readers
267 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
On all the agile projects I've worked on, the teams have been very reluctant to make a specification in place before starting development. Often claiming that we can't know the requirements up-front, because we're agile.
I don't think this is an Agile thing, at all. I mean, look at what Agile's main trait: multiple iterations with acceptance testing and product&design reviews. At each iteration there is planning. At each planning session you review/create tickets tracking goals and tasks. This makes it abundantly clear that Agile is based in your ability to plan for the long term but break/adapt progress into multiple short-term plans.
For your sake, I hope your employment was agile as well. Those jobs sound like they were dumpster fires waiting to happen.
Also seems like a shitty get-outta-jail-free card. With no design in place, timelines and acceptance criteria can't be enforced. "Of course we're done now, we just decided that we're done!"
That's boneheaded.
How did they know how to break things down into tasks? How did they know if a task would fit in a sprint? 😄
We're so agile the sprint became a time-block framework rather than a lock-down of tickets that we certainly will finish. (In part because stuff comes up within sprint.)