@wakingrufus read through, broadly agree. I might put more emphasis on the tension between "sustainable development" and "continuous release"; definitely seen situations where the result is that devs have a regularly occurring stress point at the end of every sprint.
The section on unions is right, but I don't think I would find it compelling if I didn't already agree. Maybe more of a point on how an actual "autonomous, self-organized" team, cannot, by definition, be one organized by anyone outside of the team; either you make the workers the owners (co-op), or the workers really report to their own organization that will not align with the goals of the owners (a union).
Alienation in particular is tricky. Personally, I heard marxists talking about it a lot as a dev and thought it was a little overwrought: why would I be unhappy that I'm taking home well-above median wage, but don't own the rights to internal company tools I developed? What would I even *do* with order-tracking software?
@wakingrufus it wasn't until later, when I had burned out for the third time, that I really made the connection what I was feeling was alienation. Control over the work was part of it (why the hell am I having to ask permission from non-devs to use branches, do pair programming, write unit tests?). The other big part was alienation from not only end users but the real world; work becomes an abstract stream of JIRA tickets, with no connection to any real problems hypothetical end users may or may not be solving. It's really, really hard to feel good about writing software that you can't imagine anyone using, adding features you can't imagine anyone wanting.
I'm also thinking about a time (tooted about it on this acct ~Mar/Apr 2018, you might have seen it) when, taken literally, Scrum ritual would have required the devs to effectively go on strike until the organization had addressed our concerns. (Scrum says you can't proceed with a sprint w/o confidence you can complete the work.)
@wakingrufus OH OH OH, from a presentation I gave about the broader ideas behind Agile:
Agile activities can be painful. That's by design: Pain is a signal to change. If writing unit tests is painful, that's a clue that your code needs to change. If deploys are painful, deploying every week hurts more than deploying every few quarters. Agile wants you to feel that pain and then to fix your deploys. The drawback is that if you can't change, you just feel the same pain over and over for no benefit. You end up in retrospective meetings talking about the same problems you can't fix week after week. If you adopt these Agile-adjacent activities, but you don't have the power or authority to fix the problems they surface, all you're doing is hurting yourself.
@octopus Thanks so much for the feedback! I think you point out something that I was worried about, in that I do kind of make a leap to discussion of alienation and unions without fully fleshing out how these things manifest in the real world. I'm going to think about this some more... I want to find a way to frame it for people who haven't gotten there the hard way yet. I love the way you describe it.