473
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 06 Jun 2024
473 points (89.2% liked)
Technology
59454 readers
1801 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
Rewrites are great. You have a specification that is so defined it is literally code.
When it's blue sky, it's harder. Plans will be wrong. The users don't understand really what they need or want. It all ends up evolving. Anything with a GUI is worse because users/customers need (want) things moved about, re-themed, with no regard to what's below. Best to nail them to mock up designs they signed off on. Same with API interfaces. If they signed off on the design, you can then point out "spec change" and get more time/money. It's more about ass covering than using the outcome or process.
Agreed. Depending in what branch or situation youre in you need handle appropriately and cover your arse but also make it work. If i was to work on a timed project, and the project is set to not make the deadline due to spec changes i will report that ahead of tine to cover the teams arses, but at least we can pivot and deliver something that will be useful and up to spec depending on the feedback :)
I don't think there is a way that always works.
It's not always possible to get a clear spec and do big design up front in R&D. The whole point can be to work out what can be done and how.
Correct! Hence why i said it all depends on the product, the team, the time, money, project, ...
Many factors that decide on how to tackle things and the problems :)