Programming

17378 readers

148 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 !webdev@programming.dev

founded 1 year ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

MaungaHikoi@lemmy.nz

409

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

submitted 5 months ago by ylai@lemmy.ml to c/programming@programming.dev

134 comments fedilink hide all child comments

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

[–] Anticorp@lemmy.world 35 points 5 months ago (2 children)

According to the study, putting a specification in place before development begins can result in a 50 percent increase in success, and making sure the requirements are accurate to the real-world problem can lead to a 57 percent increase.

Is this not self-evident to most teams? Of course you will not reach your destination if you don't know where you're going.

[–] iamtherealwalrus@lemmy.world 14 points 5 months ago (4 children)

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.

[–] lysdexic@programming.dev 16 points 5 months ago

On all the agile projects I’ve worked on, the teams have been very reluctant to make a specification in place before starting development.

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.

[–] pivot_root@lemmy.world 11 points 5 months ago (1 children)

For your sake, I hope your employment was agile as well. Those jobs sound like they were dumpster fires waiting to happen.

[–] kippinitreal@lemmy.world 9 points 5 months ago* (last edited 5 months ago)

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!"

[–] Anticorp@lemmy.world 4 points 5 months ago

That's boneheaded.

[–] lemmyvore@feddit.nl 4 points 5 months ago (1 children)

How did they know how to break things down into tasks? How did they know if a task would fit in a sprint? 😄

[–] Kissaki@programming.dev 3 points 5 months ago

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.)

[–] floofloof@lemmy.ca 10 points 5 months ago (1 children)

On the other hand you can just call wherever you end up the destination, and no one can prove you wrong. 100% success rate.

[–] Semi_Hemi_Demigod@lemmy.world 4 points 5 months ago

Congratulations you've just been promoted to product manager