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
[–] 197 points 2 years ago (3 children)

One standout statistic was that projects with clear requirements documented before development started were 97 percent more likely to succeed.

I'd like to work in that company.

  • permalink
  • fedilink
  • source
  • hideshow 6 child 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
  • [–] 3 points 2 years ago

    No thanks. It's way more fun to be part of the decision process. If a manager can anticipate all of the requirements and quirks of the project before it even starts, it's probably going to be a really boring, vanilla project at which point it's probably just better to but the software.ä somewhere else.

    Creating something new is an art in itself. Why would you not want to be a part of that?

    Also: Isn't it cheating to compare the two approaches when one of them is defined as having all the planning "outside" of the project scope? I would bet that the statistics in this report disregard ll those projects that died in the planning phase, leaving only the almost completed, easy project to succeed at a high rate.

    It would be interesting to also compare the time/resources spent before each project died. My hunch is that for failed agile project, less total investment has been made before killing it off, as compared to front loading all of that project planning before the decision is made not to continue.

    Complementary to this, I also think that Agile can have a tendency to keep alive projects that should have failed on the planning stage. "We do things not because they are easy, but we thought they would be easy". Underestimating happens for all project but for Agile, there should be a higher tendency to keep going because "we're almost done", forever.

  • permalink
  • fedilink
  • source
  • parent