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
Im currently trying to steer a product team to have this kind of process. They are working with an ancient piece of software that is slowly being replaced. However, we need to replace piece by piece while the main app is still being maintained because of law and workflow changes. This is why i want them to set the requirements and designs up front a bit so we can make a good analysis of it before development starts so no technical difficulties or questions arise mid development! However, nothing is set in stone and after each small piece ( aka after each sprint ) we have our review and product owners and stakeholders see what we have made and can chime in, causing us sometimes to pivot what we were making.
Best of both worlds!
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 :)