Anakin Padme meme:

Anakin: I will use agile to plan my project
Padme: 2-3 sprints ahead right?
Anakin:
Padme: 2-3 sprints ahead right?

    • Mak'@pawb.social
      link
      fedilink
      arrow-up
      10
      ·
      5 months ago

      This year’s? We can’t even make it through this sprint’s roadmap without a deviation.

      Bonus points if it’s C-suite crashing the sprint.

    • soloner@lemmy.world
      link
      fedilink
      arrow-up
      25
      ·
      5 months ago

      Nah. It doesn’t say not to plan. It says to prefer responding to change over planning. Which means both happen but responding to change is more crucial. Or put another way don’t let your plan get in the way of responding to change.

      I’m sure you were being sarcastic, but I get kind of tired of the Agile strawman and people shitting on it. It’s not a complex philosophy yet people extrapolate so much (too much) and then get annoyed when their assumptions don’t pan out well. even performing sprints is an extrapolation, so this meme gets it wrong too.

    • dandi8@fedia.io
      link
      fedilink
      arrow-up
      21
      ·
      edit-2
      5 months ago

      As a dev, I think agile works best when there’s an ongoing conversation with the users, and I usually have to fight with management to get to speak to those actual users.

    • Zahtu@feddit.de
      link
      fedilink
      arrow-up
      12
      ·
      5 months ago

      Tru dat. Agile product management is not the same as agile project management. Agile Project Management is about the ability to figure and changes things along the lines of the predetermined cost and time path (e.g. figuring out features required along the way), not about the agility to prolong/shorten product value proposition time to market.

    • marcos@lemmy.world
      link
      fedilink
      arrow-up
      3
      ·
      5 months ago

      Do your scrum-using organization put users at the development process?!? I don’t think I’ve seen any Agile¹ organization doing that.

      1 - The one with capital “A”, that is an antonym of the one with lower cap “a”.

  • sunbeam60@lemmy.one
    link
    fedilink
    arrow-up
    15
    ·
    5 months ago

    The challenge is, in a real org of some size, you’ll suddenly get marketing or customer success asking you for commitments that are very far out, because ad slots have to be booked or a very large customer renewal is coming up.

    And some of the normal coping mechanism (beta-branch that spins off stable feature to the general release branch) don’t work for all those requests.

    Try as you might, you are going to get far off deadlines that you have to work towards. Not for everything but for more than you’d like.

    • MajorHavoc@programming.dev
      link
      fedilink
      arrow-up
      4
      arrow-down
      2
      ·
      5 months ago

      The stupidly easy solution is to just give them stuff that has already been successfully delivered to production to market, 9 months from now. There’s invariably a huge backlog of years worth of successes that marketing wasn’t even aware of.

      • foofiepie@lemmy.world
        link
        fedilink
        arrow-up
        7
        ·
        edit-2
        5 months ago

        Feature flags baby. This is how we do it.

        Make it live but disabled, have an env prior to prod with them on, for any regressions.

        Launching your already comprehensively tested and actually live feature? An easy deployment.

        Can someone please tell me how to do this for the BE. Ta.

      • sunbeam60@lemmy.one
        link
        fedilink
        arrow-up
        5
        ·
        5 months ago

        Yeah, I agree that might work if the marketing team isn’t that connected to the product. I’ve not worked with a marketing team where that would work, but maybe it will for some. It doesn’t change the “massive customer will only renew if” scenario, though.

        • MajorHavoc@programming.dev
          link
          fedilink
          arrow-up
          2
          ·
          5 months ago

          I’ve not worked with a marketing team where that would work, but maybe it will for some.

          I’ve never been anywhere that I thought it would work, but it ultimately did, almost everywhere.

          I’ve found it takes a few iterations, but the marketing folks in on it love being the ones who actually can reliably deliver on their promises.

          It doesn’t work for the marketers that promise whatever they please without talking to dev, but I don’t find them to be worthwhile professional allies, so I don’t sweat it.

          It doesn’t change the “massive customer will only renew if” scenario, though.

          Very true. It doesn’t help with that case, and that one does happen. I’ve had the best luck saying “we don’t do that, but we’re scrambling to add it” in that situation.

  • rimjob_rainer@discuss.tchncs.de
    link
    fedilink
    arrow-up
    11
    ·
    edit-2
    5 months ago

    We work in sprints but plan on roadmaps based on quarters one year into the future. So basically we just combine the worst of both worlds.

    “Oh we have bugs from feature XY from last sprint? Never mind we need to follow the roadmap, we can fix it next quarter”

    Fuck, I hate it so much

      • frezik@midwest.social
        link
        fedilink
        arrow-up
        3
        arrow-down
        1
        ·
        edit-2
        5 months ago

        Not sure about GP, but that’s basically what we did under “SAFe” (Scaled Agile Framework). PI planning means taking most of a sprint to plan everything for the next quarter or so. It’s like a whole week of ticket refinement meetings. Or perhaps 3 days, but when you’ve had 3 days of ticket refinement meetings, it might as well be the whole work week for as much a stuff as you’re going to get done otherwise.

        It’s as horrible as you’re thinking, and after a lot of agitating, we stopped doing that shit.

        • The Cuuuuube@beehaw.org
          link
          fedilink
          English
          arrow-up
          2
          arrow-down
          1
          ·
          5 months ago

          SAFe SCRUM is a fucking scam. Anyone who proposes it as a solution to a problem is out of touch and doesn’t recognize a waterfall when they see one

  • HubertManne@moist.catsweat.com
    link
    fedilink
    arrow-up
    10
    ·
    5 months ago

    ugh. we plan user stories by quarters and everything after sprint1 is just generic garbage because it generally depends on the results of sprint1.

  • Korthrun@lemmy.sdf.org
    link
    fedilink
    arrow-up
    12
    arrow-down
    2
    ·
    5 months ago

    2-3 sprints?! Y’all really flying by the seat of your pants out here huh?

    My teammates and I have no trouble planning multiple quarters in advance. If something crops up like some company wide security initiative, or an impactful bug needing fixed, etc then the related work is planned and then gets inserted ahead of some of the previously planned things and that’s fine because we’re “agile”.

    I delivered a thing at the end of Q3 when we planned to deliver at the start of Q3? Nobody is surprised because when the interruptions came leadership had to choose which things get pushed back.

    I love it. I get clear expectations set in regards to both the “when” and the “what”, and every delay/reprioritization that isn’t just someone slacking was chosen by management.

    • EleventhHour@lemmy.world
      link
      fedilink
      arrow-up
      15
      ·
      5 months ago

      I think this may be less about Agile and more that you have a great management team that sets clear priorities and goals. Not every Agile environment is like that.

      • Korthrun@lemmy.sdf.org
        link
        fedilink
        arrow-up
        14
        ·
        5 months ago

        I do greatly appreciate my management and general company tech culture, they’re great.

        I agree with your stance here, because it’s part of my point. I tend to see more people bitching about Agile itself and not management or their particular implementation.

        The jobs where I was only given enough info to plan 2 - 4 weeks out were so stressful because I frequently felt like I was guessing at which work was important or even actually relevant. Hated it.

        Turns out it’s a skill issue ;p (on the management level to be clear). Folks, don’t let your lazy managers ruin you on a system that can be perfectly fine if done right.

    • PeriodicallyPedantic@lemmy.ca
      link
      fedilink
      arrow-up
      9
      arrow-down
      1
      ·
      5 months ago

      That’s not agile.

      It’s not bad, it’s just not agile. Agile exists for projects where that simply isn’t possible. Its sacrificing a bit of potential best-case productivity to ensure you don’t get worst-case productivity.

  • shadowbroker@lemm.ee
    link
    fedilink
    arrow-up
    8
    ·
    edit-2
    5 months ago

    I can’t pinpoint the exact problem, but corporate agile destroyed software development for me. I completely lost the fun developing software as an employee. I had the most fun on my first project, which was a waterfall one.

    • PeriodicallyPedantic@lemmy.ca
      link
      fedilink
      arrow-up
      11
      ·
      5 months ago

      The problem is that people realized that they could sell agile training to middle management if they changed it to be about making middle managers feel empowered and giving progress visibility to upper management.

    • AwkwardLookMonkeyPuppet@lemmy.world
      link
      fedilink
      English
      arrow-up
      5
      ·
      edit-2
      5 months ago

      Agile has some good principles, but too often projects are delayed to support the process, when the process exists to support the projects. When a team is more focused on stand-ups and burn down charts than they are on shipping software, then they’re no longer agile. Unfortunately that is what happens to a lot of teams that decide to use Agile.

  • Bosht@lemmy.world
    link
    fedilink
    English
    arrow-up
    7
    ·
    5 months ago

    I have experience with our PM and BAs throwing draft stories in mid sprint that required PO follow up. So basically a complete waste of time.

  • SatouKazuma@programming.dev
    link
    fedilink
    arrow-up
    7
    ·
    5 months ago

    Lol imagine having management that give a shit about anything but firing as many workers as possible to make themselves look better. Deloitte can suck my fat fucking balls.