1. 17
  1. 9

    I enjoyed this article, but this anecdote stood out to me:

    Wischweh himself encountered a turning point while describing a standup meeting to an aunt, a lawyer. She was incredulous. The notion that a competent professional would need to justify his work every day, in tiny units, was absurd to her.

    I can’t think of a profession more committed to the billable hour than the legal field (apart from – maybe – agencies).

    1. 5

      There’s a difference, though, between tracking and justifying. My wife is a lawyer and she absolutely keeps track of all her time, billable and non, but is never called into a meeting where the minutiae of her billing is examined.

      I feel that this has something to do with professionalization, but I’m not entirely sure what, yet.

      1. 2

        Yes that stood out to me too! It is common for lawyers I work with to keep track of time in 6 minute units (ie 1/10th hour) and bill based on that. There are whole expensive specialised software packages for law firms to help them keep track of all their employees 6 minute blocks of work…

        1. 1

          And in Defense, this is the norm for all engineers too.

      2. 6

        This article starts with 40 paragraphs of fascinating software methodology history. It ends with this:

        Agile tricks people into thinking they have ownership over their work, but from a labor perspective, they literally do not have ownership, unless they have, like, significant stock options or whatever.

        Some people I talked to pointed out that Agile has the potential to foster solidarity among workers. If teams truly self-organize, share concerns, and speak openly, perhaps Agile could actually lend itself to worker organization.

        That, comrades, is where this article goes off topic.

        1. 4

          The problem isn’t just with surveillance, but with the way the points calcify into a timeline. John Burns, an engineer at a platform company, recalled a former workplace that simply multiplied story points by a common coefficient, in order to get a rough estimate of how long a project would take. Despite the points’ avowed status as an informal, internal measure, managers used them as a planning device.

          I’ve spent a fair amount of time on the management side as well as the engineering side, going back and forth between those roles during my career. I have gradually come to the theory that sprint points are generally pointless bullshit and I’ve stopped using them.

          The thing that people, teams, and organisations actually have is time and money. They don’t have points. A quarter isn’t 360 points, it’s around 13 weeks. Software teams are the only ones I know that refuse to talk about effort in a way that’s meaningful to other people. When I had my floor laid they told me it would take about 2 days, not 4 points.

          And given that points will always be converted into time somewhere because no-one outside the eng team understands points then we should just do everyone a favour and stop using them. My team now estimates in days, using a semi-fibonacci scale. 0.5, 1, 2, 3, 5, 8, etc…

          We still estimate high, and our estimates carry more error as they get larger. We still communicate when things are unclear and we still push back on changing requirements unless we can change the estimates, too. We just stopped with the points BS.

          1. 2

            what’s with the fibonacci worship in sprint pointing? while i’ve got no problems with math, i do wonder if it’s just an explicit nerd-ism from the uncle bob world.

            1. 2

              It allows you to build in extra buffer in a reasonable way as your plans have more unknowns.

              1. 1

                good point too: farther out, bigger error bars in the guesstimation…thanks, as i’d not thought of it that way

              2. 2

                Oh it’s not any math nerdiness on my part, I just think the spacing is pretty good for showing how confidence and accuracy decreases as the size of work increases. Any other spacing that captures that is fine, too. Doubling would be just as good, and I’ve used that before too: 0.5, 1, 2, 4, 8, 16. A fixed factor doesn’t work well, and a limited number of options means you don’t waste time thinking about whether it should be 14 or 15.

                1. 1

                  good point about it preventing wasting time pondering an infinite continuum rather than discrete choices!

            2. 4

              I think we are suffering from the sudden industrialization of our field that accelerated in the last decade. Projects have become like factories. Software Engineers think themselves as “artisans”, when in reality they are the new factory workers. Agile Methodologies are a “humane” way of organising a factory, so even if we get some freedoms or theoretical promises of freedoms, we are still part of the assembly line.