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.