All it does is let leadership not define what they actually want, and make changes on the fly, which leads to longer dev times and worse code. Fuck agile, bring back waterfall.

  • Blamemeta@lemmy.worldOP
    link
    fedilink
    arrow-up
    2
    arrow-down
    10
    ·
    1 year ago

    No I haven’t, but its better than finding out that you were supposed to make a mobile app on go-live day, instead of a website. Same basic functionality, but completely different front end.

    • yesterdayshero@lemmy.world
      link
      fedilink
      arrow-up
      10
      ·
      1 year ago

      That totally sucks. But has nothing to do with agile. That could have happened with waterfall because you would have sat there and developed things in isolation only to find out at the end it wasn’t what was expected.

      • Blamemeta@lemmy.worldOP
        link
        fedilink
        arrow-up
        3
        arrow-down
        3
        ·
        1 year ago

        I guess thats true, but at least we would be able to point at a requirements doc instead of a mess of emails and messages.

        • yesterdayshero@lemmy.world
          link
          fedilink
          arrow-up
          5
          ·
          1 year ago

          That’s the biggest problem with waterfall to be honest. You can sit there and point at requirements, but requirements can be interpreted differently. And that’s a bigger issue with waterfall because you’re handed a list of requirements with little context on what the purpose is of what you’re doing because you weren’t in any of the conversations earlier on in the process.

          Agile doesn’t mean you don’t have requirements. What happened really sucks. But you aren’t working in agile. You’re just being screwed.

          • Blamemeta@lemmy.worldOP
            link
            fedilink
            arrow-up
            5
            arrow-down
            1
            ·
            1 year ago

            Yeah, maybe you’re right. Just wish my lead pushed back more, and was a technical person. Probably would’ve stopped this train wreck before it began.

    • fkn@lemmy.world
      link
      fedilink
      arrow-up
      10
      ·
      1 year ago

      That’s… Not agiles fault… This is a systematic failure of project management.

      Besides, if you were doing agile and the business you were working with participated you would have ended up with a version in their hands they should have said was the wrong thing 2/3rds of your development time ago…

      • KevonLooney@lemm.ee
        link
        fedilink
        arrow-up
        7
        ·
        1 year ago

        Yeah, a lot of “meeting fatigue” is just bad management too. I have been on teams with great meetings where they stop when they run out of things to say (or cancel the meeting altogether!). I have also seen meetings where they go on and on about “virtual meeting fatigue” for 15 minutes. What do you think is causing the fatigue? This extra 15 minutes!

    • fkn@lemmy.world
      link
      fedilink
      arrow-up
      3
      ·
      1 year ago

      I have to say though… This sucks. I’m sorry you are dealing with this.

      • Blamemeta@lemmy.worldOP
        link
        fedilink
        arrow-up
        4
        ·
        1 year ago

        Yeah, we basically decided to just ship it, and have people do it through their browser. Only saving grace is its an internal app, and “So long as it works on a phone” which thankfully it does. Lots of bickering and finger pointing today though.

    • Mic_Check_One_Two@reddthat.com
      link
      fedilink
      arrow-up
      3
      ·
      edit-2
      1 year ago

      That sounds like a problem with project scope, not with agile or waterfall.

      The issue is that people read “agile” and assume that means the entire project scope can be quickly changed. You still need a proper scope, even when using agile.

    • jochem@lemmy.ml
      link
      fedilink
      arrow-up
      3
      ·
      1 year ago

      This is literally the critique on waterfall (project goes and makes what they believe the customer want, comes back months or years later, turns out they made the wrong thing and wasted so much time) and what agile aims to solve (have regular check in moments to see if the project is still on the right track and adjust when needed).

      In my experience it helps to define a roadmap and stick with that direction. Figure out the details when you start working on a roadmap item. Adjust the roadmap every 6 months or so, only deviate earlier when the situation calls for it. This requires sometimes being able to say ‘no’ to your customer and them accepting it.