studies show a clear trend – output is up (more code, more commits, bigger diffs), but outcomes don’t reflect that trend. If anything, the average team is taking longer to ship worse software

    • jtrek@startrek.website
      link
      fedilink
      arrow-up
      46
      ·
      2 months ago

      Has management known that?

      A lot of problems seem to be downstream from “management are idiots and assholes”

        • jtrek@startrek.website
          link
          fedilink
          arrow-up
          7
          ·
          2 months ago

          My team assigns both hours and points to tasks. I’ve never seen the points used for anything but they still spend time on it.

        • Dejected Warp Core@lemmy.world
          link
          fedilink
          arrow-up
          2
          ·
          2 months ago

          That battle is perpetual. Lazy management sees a number that resembles a statistic, and try to use it as an easy metric for stuff it doesn’t represent. Points do aggregate into velocity, which is worth measuring. But on their own, points are a proxy for estimation in $SPRINT_LENGTH days. The way to manage up is to keep making it clear that the smallest unit of estimation in Agile is the sprint length; points are used to subdivide that but only to ensure that the sprint itself is not overloaded and thus an accurate estimate.

      • dreamkeeper@literature.cafe
        link
        fedilink
        arrow-up
        3
        ·
        2 months ago

        At any minimally competent company they are aware.

        However my company mostly has former engineers as engineering managers.