It's a planning tool that is useful in situations where people otherwise have a hard time planning things. This is very common in the industry. Software engineers are poor at estimating their work. Managers in turn tend to have a poor grasp of how hard or easy things are. Scrum is a tool you can use to get some sensible decision making in place.
I'm actually not a huge fan of scrum and the mindless activism around it but it's probably not worse than most alternatives. Including the default herd of cats type situation that lots of people seem to default to, which is definitely not great. I default to vaguely Kanban; regardless of the process of others around me. When in a scrum environment, I just just make sure that my TODOs are aligned and prioritized correctly. When not, same.
My main criticism of scrum is that it leads to consensus based decision making where consensus drowns out expertise. If not managed properly, it promotes a culture of mediocrity. You get people in junior management roles (which is what the PO role typically is) overruling experts around them. Easy things become hard, and hard things become impossible. Sometimes you just need to let the experts to do their thing without micromanaging them.
Another problem is that it drives teams to iterate rather slowly (weeks); which creates issues if you want to be more agile and e.g. practice continuous deployment, which I would argue should be the default these days. This is something that can be managed by a good team but it needs active managing. I tend to completely decouple planning from releases. We release regularly and we only release good stuff. Anything not making the cut goes to the next release. This happens regardless of any sprint plannings and what not.
Yet another problem is that doing scrum in large organizations creates all sorts of process bottlenecks. Orchestrating large amounts of teams is a non trivial problem that scrum does not provide solutions for. Naive versions of this (synchronized sprints, scrum of scrums, etc.) naturally lead to waterfall style development cycles where nothing happens quickly anymore. This too can be managed but I've seen a few places where this became a ritualistic mess that involved lots of wasted time, people in pointless roles without having much impact, etc. You get teams working around each other, doing conflicting things, and worse.
I don't think Google, Meta, MS, Apple, or similarly large software development organizations talk a lot about their internal processes. But my impression is that they mostly don't seem to be doing scrum; or at least they don't talk a lot about doing that. Correct me if I'm wrong. The above might be why.
I'm actually not a huge fan of scrum and the mindless activism around it but it's probably not worse than most alternatives. Including the default herd of cats type situation that lots of people seem to default to, which is definitely not great. I default to vaguely Kanban; regardless of the process of others around me. When in a scrum environment, I just just make sure that my TODOs are aligned and prioritized correctly. When not, same.
My main criticism of scrum is that it leads to consensus based decision making where consensus drowns out expertise. If not managed properly, it promotes a culture of mediocrity. You get people in junior management roles (which is what the PO role typically is) overruling experts around them. Easy things become hard, and hard things become impossible. Sometimes you just need to let the experts to do their thing without micromanaging them.
Another problem is that it drives teams to iterate rather slowly (weeks); which creates issues if you want to be more agile and e.g. practice continuous deployment, which I would argue should be the default these days. This is something that can be managed by a good team but it needs active managing. I tend to completely decouple planning from releases. We release regularly and we only release good stuff. Anything not making the cut goes to the next release. This happens regardless of any sprint plannings and what not.
Yet another problem is that doing scrum in large organizations creates all sorts of process bottlenecks. Orchestrating large amounts of teams is a non trivial problem that scrum does not provide solutions for. Naive versions of this (synchronized sprints, scrum of scrums, etc.) naturally lead to waterfall style development cycles where nothing happens quickly anymore. This too can be managed but I've seen a few places where this became a ritualistic mess that involved lots of wasted time, people in pointless roles without having much impact, etc. You get teams working around each other, doing conflicting things, and worse.
I don't think Google, Meta, MS, Apple, or similarly large software development organizations talk a lot about their internal processes. But my impression is that they mostly don't seem to be doing scrum; or at least they don't talk a lot about doing that. Correct me if I'm wrong. The above might be why.