• EfreetSK@lemmy.world
    link
    fedilink
    arrow-up
    35
    arrow-down
    1
    ·
    4 hours ago

    I don’t know man. For the past 6 months we went with approach “Fuck scrum, let’s just work”. It didn’t go well. We were really disorganized, everyone going their own direction, things being overlooked, …

    When a new colleague joined recently, he suggested taking more structured (scrum-like) approach. Things improved immediately.

    Like I don’t know how you want to call it - scrum, kanban, whatever, I don’t care. But you need some structure in your team and you need some meetings where you talk about status, about looking back at things, about plans for next weeks, …

    • python@lemmy.world
      link
      fedilink
      arrow-up
      2
      ·
      46 minutes ago

      My team has moved to a thing we call “ScrumBan” and it’s worked pretty well. There still are 15-min Dailies, and a Review and a Retrospective each Sprint, but we cut almost all meetings that are about sitting around and “planning” tasks (aka awful 7-hour meetings where everyone just zones out and guesses random story point numbers). Instead, tasks are planned and moved to the board on demand and never in the presence of the entire team. It gives everyone so much more time to just focus on their work.

      • resipsaloquitur@lemmy.world
        link
        fedilink
        arrow-up
        3
        ·
        31 minutes ago

        That’s scrum. One of the defining features of scrum is timeboxing meetings. Daily standups are 15 minutes. A two week review should be two hours. Ditto for retrospectives and sprint planning.

        A seven hour meeting means the scrum master wasn’t doing their job.

    • BingBong@sh.itjust.works
      link
      fedilink
      arrow-up
      5
      ·
      3 hours ago

      I worked with my team and we naturally evolved to a Scrum-lite. Or what scrum consultants might derogatorily call scrum-but. We do sprints, the team plans their own work, we do not do the daily standup since no one wanted it. Just having time blocked focused work has made us very productive without burnout. If your manager locks in too Mich on by the book scrum it becomes a pointless waste of time and ceremony.

    • Unleaded8163@fedia.io
      link
      fedilink
      arrow-up
      13
      ·
      4 hours ago

      My only requirement for team processes is that they be mostly up to the team. Absolutely some type of structure is needed. If something isn’t working for the team, they need to have agency to address that, whether it means adding, removing, or changing something.

      • azertyfun@sh.itjust.works
        link
        fedilink
        arrow-up
        13
        ·
        2 hours ago

        Well, yeah, that’s what Scrum is. From the guide which takes maybe 10 minutes to read

        Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.

        That’s not a throwaway sentence - it is fundamental to how scrum works and that is reinforced throughout the scrum guide.

        Every conversation about Agile and/or Scrum being “the worst”, after some prodding it turns out that their company has refused to read or implement one or several of the fundamental principles, often without even being aware that was an essential requirement. You’re baking a cake and you decided to not use any butter, that’s on you champ, don’t blame the fucking recipe.

        The biggest valid criticism of scrum is that the thing that makes it so great - its structural empowerment of individual teams - is also what makes it structurally incompatible with any traditional top-down management style. The company must fundamentally be (re-)organized to have a flat corporate structure within its R&D department - most are simply incapable of mustering the necessary changes, if only because too many middle managers’ jobs are at stake. So they call their middle managers “POs” or “Scrum Masters” and wonder why their version of Scrum sucks.

      • red_tomato@lemmy.world
        link
        fedilink
        arrow-up
        4
        ·
        3 hours ago

        This is what’s most important. Allow for experimentation!

        What works well for one team might not work well for your team. What worked well for your team 1 year ago might no longer be what you need now.

  • foo@feddit.uk
    link
    fedilink
    arrow-up
    6
    ·
    3 hours ago

    The biggest problems with scrum, in my experience, are when the managers and directors don’t understand it and ruin it. I’ve been a few places that implemented SAFe, but to this day I don’t know what SAFe actually is beyond waterfall with pointless sprints. I’ve worked in a couple of places where the directors kept their noses out and scrum worked really well.

  • jjjalljs@ttrpg.network
    link
    fedilink
    arrow-up
    15
    ·
    4 hours ago

    My job has a “scrum master”. She’s nice, I guess, but as far as I can tell her entire job is sharing her screen so we can look at tickets. Then people tell her what to click on and what text to change. It’s excruciating because it would just be faster for the person talking to change it, instead of being like “remove the second bullet point. No, not that one”

    On top of that they have all these tasks for “unit testing” but they don’t actually do unit testing. Someone just said, in the distant past, we should do testing so it’s there.

    • PodPerson@lemmy.zip
      link
      fedilink
      English
      arrow-up
      1
      ·
      29 minutes ago

      This is just like PMs where I work. They are generic PMs with no background in the work we do, so they end up being spreadsheet updaters and meeting schedulers (which literally everyone can easily do themselves).

    • GreenKnight23@lemmy.world
      link
      fedilink
      arrow-up
      8
      ·
      4 hours ago

      I loved being the scrum master but the responsibilities should be more than presenter.

      I had to deliver project status notes to product shareholders, let them know of any directional changes we had to take due to blockages, drive the team to deliver on time for product launch, manage the backlog workflow to ensure the dod was accomplished, manage the backlog and attribute 15% of it to housecleaning/bug fixes.

      • AliasVortex@lemmy.world
        link
        fedilink
        English
        arrow-up
        5
        ·
        3 hours ago

        This. A scrum master’s job should be first and foremost making sure that the dev team has what it needs to get real actual work done. Ideally, the scrum master should be face tanking face tanking status/ update meeting, coordinating with outside entities, and ensuring that as few distractions make it to the team as possible.

        • foo@feddit.uk
          link
          fedilink
          arrow-up
          2
          ·
          3 hours ago

          Exactly. A good scrum master shields the team from the bureaucracy, facilitates the meetings while keeping them targeted and on-topic, and keeps everything running instead of slowing it down. They also coach the team in self-organisation.

          There are far too many people that call themselves scrum masters that are actually just pressurising ticket managers.

    • djsaskdja@reddthat.com
      link
      fedilink
      English
      arrow-up
      3
      ·
      4 hours ago

      Now that you mention it, I don’t think I’ve ever sent my Dad a meme in my life. He’s kind of a boomer tho. I’m not sure he even knows what they are lol.

  • marcos@lemmy.world
    link
    fedilink
    arrow-up
    15
    arrow-down
    1
    ·
    edit-2
    5 hours ago

    Meetings! Meetings as far as the eyes can see!

    There’s no escape, there’s no rest. Life is only meetings now.

  • melfie@lemy.lol
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    3 hours ago

    Scrum feels like a miniature waterfall. In the worst cases, a sprint is a race to make something that won’t be embarrassing at review and demo on Friday, and then you finish it over the weekend because it’s getting released Monday (with an incident in prod on Tuesday because you had to half-ass some things). Afterwards, the SM is nagging you to enter your actuals in JIRA “so we can track velocity”.

    Kanban is better in my experience since it at least does away with arbitrary deadlines, while still encouraging practices like backlog grooming and breaking down work into small units that can be completed in a week or less and then shipped. If you do a group pointing session and the consensus is that it’s going to take more than a few days, you go back and break it down further. If you run into issues with a work item and it takes a little longer than expected, no biggie, because quality is speed, unlike with Scrum where back-to-back sprints would force you to be working in the next thing because you’re now in a new sprint and last sprint’s work should’ve already been done. Didn’t you already show that in review and demo, so why are you still working on it?