This is pretty typical elsewhere too (midwest US as a data point).
Its popular because managers can implement it. Agile- the manifesto version- was intended as a way to re-introduce the notion of discipline that newer generations of programmers had lost (where previously they were engineers and scientists who wrote code, now people who code exclusively eithout other backgrounds).
It feels like we have come full circle to where the new generations of programmers have delegated (or lost) all discipline to managers' Scrum plannings.
Managers and "product owners" aren't engineers or programmers. They shouldn't be expected to "manage" a developer's day-to-day, and yet them presiding over sit-down-stand-up meetings and demanding points and determining deadlines and features is precisely what it has come to. We are right back where we were when the manifesto was drafted.
The irony is, when I first saw Agile/Scrum, I thought of it mostly as a tool to provide discipline further up the chain rather than down.
User stories? Oh, a neat way to keep requirements general and open-ended so we can properly address how we're actually going to solve a user's problem. Surely it'll prevent PMs from over-specifying requirements that lose sense of true objectives.
2 week Sprints? Cool, estimates are hard, and now I never have to estimate more than 10 business days worth of labor.
Retrospectives? Great idea, we can finally do proper post-mortems and knowledge-sharing!
Scrum Masters? Wonderful, there's someone whose dedicated to running the process and making sure we have everything we need!
What I wasn't anticipating:
User Stories? But what about critical requirements that need to be prioritized that don't fit into "As an X I need Y"
2 Week Sprints? I now have so much technical debt a repo man is confiscating my laptop.
Retrospectives? This is always going to be 100% about how we didn't estimate correctly and not about far more important matters like: how these features didn't help our users, technical knowledge-sharing, and ticking-out technical debt.
My favorite team experience was scrum done "right". Standups were run by a scrum master who was the most experienced engineer on the team- programming longer than I've been alive type of guy.
Probject managers and product owners were kept at arms length in the sense that they didn't dictate how, what or when we did what we did. They translated the business requirements and timelines into something we could understand and react to.
Somehow, all of that turned into two week sprints that felt sustainable... At least until the company bought out another company, and everything went downhill. That, however, is a story for another time.
The most salient truth about power is that it cannot be disciplined, except by greater power.
Here's the thing: I have been lucky enough to work with engineer-founders as my bosses for most of my career. You know what the downsides are? None. It's just pure awesome.
It's getting to the point that they're the only people I want to work for.
Its popular because managers can implement it. Agile- the manifesto version- was intended as a way to re-introduce the notion of discipline that newer generations of programmers had lost (where previously they were engineers and scientists who wrote code, now people who code exclusively eithout other backgrounds).
It feels like we have come full circle to where the new generations of programmers have delegated (or lost) all discipline to managers' Scrum plannings.
Managers and "product owners" aren't engineers or programmers. They shouldn't be expected to "manage" a developer's day-to-day, and yet them presiding over sit-down-stand-up meetings and demanding points and determining deadlines and features is precisely what it has come to. We are right back where we were when the manifesto was drafted.