I apologise if this hits too hard.

    • Valmond@lemmy.mindoki.com
      link
      fedilink
      arrow-up
      2
      ·
      6 个月前

      I prefer V-cycle for when you have a software with known specs & Kanban for when you don’t really know what the client needs/wants. I mean those magic clients you hear about but never sees…

    • Dave@lemmy.nz
      link
      fedilink
      arrow-up
      17
      ·
      6 个月前

      And I think this video is talking about scrum implemented poorly. But admittedly that’s the only way I’ve seen it done 😐

    • bluGill@kbin.run
      link
      fedilink
      arrow-up
      14
      ·
      6 个月前

      I’m able to get the good parts of scrum without all the overhead with kanban. Sprints are worthless, work doesn’t align on a 2 week cadence anyway.

      • setVeryLoud(true);@lemmy.ca
        link
        fedilink
        arrow-up
        10
        ·
        6 个月前

        Sprints aren’t for you, it’s for the higher ups to have a digestible view of what’s going on in the team by presenting work done over 2-3 weeks, calibrating budgets, etc.

        As a dev, yeah, sprints feel restrictive and artificial as fuck lol

        • RecallMadness@lemmy.nz
          link
          fedilink
          arrow-up
          3
          ·
          6 个月前

          If you still do the sizing (it’s not entirely wasted as it’s a reasonably effective tool to gauge understanding across the team), This can still be done without the artificial time boxing.

          “How much work have we done in the last two weeks?” Just look at all the stories closed in the last two weeks. Easy.

          “When will X be delivered?” Look at X and all its dependencies, add up all the points, and guesstimate the time equivalence.

          Kanban isn’t a free for all, you still need structure and some planning. But you take most of that away from the do-ers and let them do what they do best… do.