477
Study finds 268% higher failure rates for Agile software projects (www.theregister.com)
submitted 2 years ago by to c/technology@lemmy.world
115 comments fedilink hide all child comments
 

We all knew it

you are viewing a single comment's thread
view the rest of the comments
[–] 83 points 2 years ago (1 child)

Try medical software and devices. The requirements and specs are mandatory before doing anything. It’s actually very fun and I have less burnout thanks to this.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 63 points 2 years ago (2 children)

    I couldn’t disagree more.

    In medical I would end up being apart of endless retirement gathering meetings, then draft up the SOW doc only to have stakeholders change requirements when they were reviewing the doc. Then months later once the doc was finally finished and I could do the development, when UAT time finally came, they’d say the build wasn’t what they wanted (though it matched the written requirements).

    Most of the projects I saw executed in the last 4 years either got scrapped altogether or got bogged down in political bs for months trying to get the requirements “just right”.

    It was a nightmare. You could blame me, or the company, or bad processes all you want, but I’ve never had fun on a waterfall project, especially not in medical. (Though, in my opinion, we are severely understaffed and need like 4 more BAs.)

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 20 points 2 years ago (1 child)

    Do you think the problem is that the person driving the requirements doesn't know what they actually want?

    I think a good BA is critical to the process because lots of end users have no idea how to put their ideas onto paper.

    I also think an MVP helps a lot because people can see and touch it which helps focus their needs.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 16 points 2 years ago

    I would say yes, the problem is stakeholders not having thought critically about what they really wanted from the project.

    The motivation for projects were usually “regulatory told us we need to have this new metric for federal reporting”, or “so-and-so’s company can do this, why can’t ours” rather than, “we’d like to increase retention by 6% and here’s the approach we’ve researched to make that happen”.

    I ended up experiencing that people in the highest positions weren’t experts in their field, but just people who had a strong intuition. This meant they would zero-in on what they wanted by trial and error rather than logic. Likewise, it meant they were socially adept enough so their higher-ups would never get mad at them when we finished “late and over budget”. People lower on the totem received that blame.

    I think humans are just really bad at estimating and keeping their commitments, which is why I enjoy working with agile more. It’s a forgiving framework (imo).

  • permalink
  • fedilink
  • source
  • parent