Sunday, January 13, 2019

I was asked how I reconcile a couple of precepts this weekend.

I was asked how I reconcile a couple of precepts this weekend. I don't think I did a very good job in person, so here's a better attempt.

Claim 1: Employees should do as little as possible while extracting as much wealth from the capital class as possible.
Claim 2: Agile (and scrum in particular) enable peak productivity.

I think both of these are true.
(1) is about survival; the capitalistic class acts as a leech on the labor class, and the only tool the labor class has to defend itself is to withhold it's labor. By definition, labor as a class produces more wealth than is returned to it by the capital class.

(2) is really about treating employees like adults; when we practice scrum, we ensure it is the employees who define the current scope of work accepted by labor. If employees are pushed to accept more than is actually attainable, they'll burn out. We can also, generally, expect employees to want to take on more due to, in essence, brainwashing.

Really, (2) is about the dumbness of other management styles, in particular top-down hierarchical management where employees are told how much and what to do; this generally leads to disaster.

Which is hard for us to see: we're broken things filled with stockholm syndrome; the capital class keeps us in bondage for there own benefit, with management working to extract that labor.

That's an extreme end of the position; the truth is less violent, but comes from the same place: labor is extracted from the majority of us for the benefit of a few.

So, that's how. I think.

6 comments:

  1. So long as management is measured by arbitrarily assigned goals, they will always act illogically in their action with workers.

    While on the surface, it appears that Agile is a way to maximize the worker's output (for the benefit of the owners) and to force managers to become facilitators for that maximized output; it can also be viewed as a way to placate the workers into thinking they have some measure of control over their effort and therefore creates less resistance to demands for results.

    The "just another management style" and it very similar to flat management that was vogue a few decades ago, with similar pros and cons. It's not the finish line... there can't be one. Something better will eventually come, but it's not bad from the worker's perspective although it can be hell on people who are secondarily supportive to groups in ways that can't be measured.

    Also, a minor issue I have with agile: the rogue scholar archetype that helps everyone in their workgroup do better; because they always have an answer, know where to find solutions, have "seen this problem before", and they make everyone else look good. After a few reviews, they get fired because their velocity sucks and the whole team's velocity suffers after because there's no way to measure their contribution until you remove them.

    ReplyDelete
  2. I essentially agree with all of that, and have bee absolutely fighting allowing velocity to apply to individuals. That's bullshirt.

    Basically: It's one step in the revolution.

    ReplyDelete
  3. Reading the whole thing over, "rogue scholar" is a new one for me, and it's me, and I'm in an intensely individual-velocity system. Demands extremely careful tracking of personal metrics and routinely focusing on individually-attributable stuff (and a lot of effort to track outcomes of "saved unit X hours", "saved service Y dollars"), and goodness only knows what I could accomplish if I didn't have that requirement.

    ReplyDelete
  4. Posit: Agile allows the "capital classes" to leverage labour to police itself inside a simulacrum of control, reducing the vertical demand on management.

    Also opinion: no, not peak productivity, that's group dynamic dependant. Also not peak reliability.

    ReplyDelete
  5. Josh McGraw I make teams work really well by identifying who has which skills and basically being a social lubricant for getting anti-social types to integrate and work as a team. I love paired programming. I've seen all these problems before. I can actually be accurate when I estimate how long something will take.

    And if management is looking at individual velocity it really seems like I'm not pulling my weight. That's when I first noticed the paradox in scrum for using velocity as a metric.

    Now if you want interchangeable cogs, it's a great metric... but real scrum isn't about that. It's about team synergy. No one realizes that my team was the first to ever hit all their targets, they just notice that I wasn't one of "rockstars" whose velocity was really high. But the reason other people's velocity was high was because I was helping them to make sure we hit our targets and juggling tasks to the right people while hand holding those who were struggling.

    So I left.

    ReplyDelete
  6. You have made some decent points there. I looked on the internet for more information about the issue and found most people will go along with your views on this web site. Call Center Management

    ReplyDelete