Programming

17655 readers

303 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

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 [email protected]

founded 2 years ago

MODERATORS

[email protected]

405

Study finds 268% higher failure rates for Agile software projects (www.theregister.com)

submitted 6 months ago by [email protected] to c/[email protected]

136 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] acr515 3 points 6 months ago* (last edited 6 months ago) (1 children)

I could be wrong, but from what I’ve experienced,

Projects where engineers felt they had the freedom to discuss and address problems were 87 percent more likely to succeed.

is not always the norm. I’ve worked in agile environments where we had to work fast because the large corporate stakeholder had such a rapid turnaround that discussing and addressing problems meant slowing the process down, so no one wanted to be the one to say anything.

Agile feels like one of those things that works well on paper and when practiced properly, but when you get the wrong type of stakeholders involved, their lack of understanding rushes everything and makes the process and the final product bad for everyone.

[–] Theharpyeagle 2 points 6 months ago

I definitely agree, but that's true of any system. The particulars of the pitfalls may vary, but a good system can't overpower bad management. We mitigate the stakeholder issue by having BAs that act as the liason between devs and stakeholders, knowing just enough about the dev side to manage expectations while helping to prioritize the things stakeholders want most. Our stakes are also, mercifully, pretty aware that they don't always know what will be complex and what will be trivial, so they accept the effort we assign to items.