Scene: Surprise meeting with the project owner 0-3 days before the go-live date

“Hey team, the business and I have decided to postpone the project release by n=1-3 months because [they aren’t ready for it / it isn’t finished /regulatory reasons]. And since we have some extra time now, we can tie up all the loose ends on this project (i.e., ‘we’ve added n+1 months worth of backlog items to the MVP’).”

I’m still a greenish dev, so maybe this is normal, but I’ve had the same story going on for over a year now, and it’s really starting to burn me out. In the beginning, I was optimistic. Now I just hope for the project to fail, or me to get off somehow, but this thing just won’t die.

Anyone with experience on similar projects able to share words of advice? Do they ever end up working out? Seems there’s a death spiral, since we are always rushing to a deadline, forgoing tests and quality but never cleaning up our mess because we’re already behind. Yet I somehow feel like I’m the crazy one for thinking this 6-month “quick” side project turned 2+ year half-rewrite will have trouble meeting it’s Nth deadline.

  • MajorHavoc@programming.dev
    7·
    10 months ago

    It’s said that 80%-95% of software projects fail.

    Of course, that was before we slapped the word “AGILE” on our planning document and kept doing the importany things exactly the same way.

    So now the success rate is much better.™

    Narrator: It was not.

    What people miss is that the actual realized rate of project failure, in an average software team, is much worse than 95%.

    A typical team isn’t releasing 1/20 successes. They’re doing much worse than that. (Edit: As GoodEye8 points out - most of this is due to how these teams are mismanaged. The same developers thrive in better run teams.)

    Well structured teams with healthy habits consistently deliver dramatically better results.

    So it’s eye-opening to realize that the 5% of projects that succeed are, on average, being delivered by the exact same 5% of software teams, over and over again.

    The reason this matters to you is: you should change teams. The next project very probably won’t be better, in that team.

    • GoodEye8@lemm.eeEnglish
      5·
      10 months ago

      My experience has been that it’s often not the team that’s the problem, it’s the management. I’ve seen a team full of talented developers who know how to successfully launch, only to barely get anything done because management keeps reprioritizing everything. It seems in OPs case the org itself might be the issue. Even if they move to a team where the PO actually does their job instead of letting the MVP balloon the team keeps fighting business just to deliver something.

      If I was OP I’d probably look for a job in a different company.

      • MajorHavoc@programming.dev
        2·
        10 months ago

        My experience has been that it’s often not the team that’s the problem, it’s the management.

        Absolutely. Most developers are fine. It’s the management style of the organization that causes the continuous stream of project failures.