Thing is, Scrum isn't supposed to be something you do for long.
As you no doubt know, Agile is ultimately about eliminating managers from the picture, thinking that software is better developed when developers work with each other and the customer themselves without middlemen. Which, in hindsight, sounds a lot like my previous comment, funnily enough, although I didn't have Agile in mind when I wrote it.
Except in the real world, one day up and deciding no more managers on a whim would lead to chaos, so Scrum offered a "training wheels" method to facilitate the transition, defining practices that push developers into doing things they normally wouldn't have to do with a manager behind them. Once developers are comfortable and into a routine with the new normal Scrum intends for you to move away from it.
The problem: What manager wants to give up their job? So there has always been an ongoing battle to try and bastardize it such that the manager retains relevance. The good news, if you can call it that, is that we as a community have finally wisened up to it and now most pretty well recognize it for what it is instead of allowing misappropriation of the "Agile" label. The bad news is that, while we're getting better at naming it, we're not getting better at dealing with it.
I don’t think people invested in Scrum believe it’s “temporary” or ever marketed it as such.
And agile teams are supposed to be self-managed but there’s nothing saying there should be no engineering managers. It sounds counter intuitive, but agile is about autonomy and lack of micro-management, not lack of leadership.
If anything, the one thing those two things reject are “product managers” in lieu of “product owners”.
> I don’t think people invested in Scrum believe it’s “temporary” or ever marketed it as such.
It is officially marketed as such, but in the real world it is always the managers who introduce it into an organization to get ahead of the curve, allowing them to sour everyone on it before there is a natural movement to push managers out, so everyone's exposure to it is always in the bastardized form. Developers and reading the documentation don't exactly mix, so nobody ever goes back to read what it really says.
> And agile teams are supposed to be self-managed but there’s nothing saying there should be no engineering managers.
The Agile Manifesto is quite vague, I'll give you that, but the 12 Principles makes it quite clear that they were thinking about partnerships. Management, of any kind, is at odds with that. It does not explicitly say "no engineering managers", but having engineering managers would violate the spirit of it.
> not lack of leadership.
Leadership and management are not the same thing. The nature of social dynamic does mean that leadership will emerge, but that does not imply some kind of defined role. The leader is not necessarily even the same person from one day to the next.
But that is the problem. One even recognized by the 12 Principles. Which is that you have to hire motivated developers to make that work. Many, perhaps even most, developers are not motivated. This is what that misguided ticketing scheme we spoke of earlier is trying to solve for, thinking that you can get away with hiring only one or two motivated people if they shove tickets down all the other unmotivated developers' throats, keeping on them until they are complete.
It is an interesting theory, but one I maintain is fundamentally flawed.
As you no doubt know, Agile is ultimately about eliminating managers from the picture, thinking that software is better developed when developers work with each other and the customer themselves without middlemen. Which, in hindsight, sounds a lot like my previous comment, funnily enough, although I didn't have Agile in mind when I wrote it.
Except in the real world, one day up and deciding no more managers on a whim would lead to chaos, so Scrum offered a "training wheels" method to facilitate the transition, defining practices that push developers into doing things they normally wouldn't have to do with a manager behind them. Once developers are comfortable and into a routine with the new normal Scrum intends for you to move away from it.
The problem: What manager wants to give up their job? So there has always been an ongoing battle to try and bastardize it such that the manager retains relevance. The good news, if you can call it that, is that we as a community have finally wisened up to it and now most pretty well recognize it for what it is instead of allowing misappropriation of the "Agile" label. The bad news is that, while we're getting better at naming it, we're not getting better at dealing with it.