Scrum is mostly defined. The problem with scrum is that while agile (in general, not only software dev) is a methodology (a set of practices and tools) to be applied in a particular context, scrum takes those agile methods, packages into a behemoth with a very particular workflow and sells that instead of typical "consulting" - deployment of tools to control the process.
In practice scrum is extremely unagile, because there is one very particular workflow to be used and actual workflows have to be adapted to suit scrum. Sometimes it leads to increased agility, but more often than not it does not.
Probably the central piece of scrum are sprints. Nothing wrong with sprints in general, but sprints rely on feature sizes being sprint-sized. Sprints only work when you actually finish planned stuff over the course of a sprint. Naturally, feature and especially release sizes vary. By focusing on milestones one can actually plan and schedule work and releases. This is agile - you can shuffle stuff around. Instead scrum tries to sell fixed size sprints to give impression of steady movement forward, but this decouples sprints from milestones and slightly counter-intuitively reduces agility - shuffling milestones around sprints merely gives you a bunch of unfinished milestones, but also a bunch of finished sprints. But variable sized sprints based on milestones sound too much waterfall-y when the selling point is departure from waterfall.
Interestingly this attempt to squeeze features into sprint-sized chunks is one of the reasons for technical debt that you then must somehow manage, simply because squeezing features comes at a cost of technical debt. There are more reasons for technical debt, but it is slightly humorous when a tool aimed at managing/reducing technical debt introduces debts of its own.
A bit tangential to scrum, but Facebook's story of Hack/HHVM is well-known story somewhat indicative of this. When you size features according to wall-clock sized release cadence (instead of sizing release cadence according to feature sizes) you inevitably accumulate technical debt - new features should build on top of past features, but deficiencies in past features prevent new features from being built on. There are more or less 3 ways this plays out: 1. actual feature release cadence drops due to increased development weight; 2. release cadence drops due to fixup "features" being released; 3. release cadence drops due to dedicated to fixing. Do not get me wrong, technical debt accumulates and impacts release cadence any way, but with feature sized sprints this does not come out of nowhere.
Over the years teams (usually informally) understood deficiencies of scrum process and started throwing pieces of the process away, shuffling them around and having weird mess of system. This is not due to scrum not being well defined, but rather scrum being a hammer in search of nails.
Agile methodologies generally came out of manufacturing - process based workflow. Scrum takes those practices and packages them as a project management tooling. The whole point of agility in processes is the ability to adapt in the middle of the process. Project management, on the other hand, needs plannability and progress tracking. There are weird intersections between the two and IMO scrum fails to satisfy both - neither it is good at adapting mid cycle (because scrum checkpoints mid-feature), nor is it good at future plannability (because it focuses on short term goals). I have seen scrum get distorted in two major ways: either "sprints" get stretched into months long waterfalls, or sprints mostly reshuffling priorities in "in progress" pile and checkpointing progress.
Then cite the definition? If you will cite the https://scrumguides.org/ - I have yet to work in any team that uses scrum that follows this even slightly.
In practice scrum is extremely unagile, because there is one very particular workflow to be used and actual workflows have to be adapted to suit scrum. Sometimes it leads to increased agility, but more often than not it does not.
Probably the central piece of scrum are sprints. Nothing wrong with sprints in general, but sprints rely on feature sizes being sprint-sized. Sprints only work when you actually finish planned stuff over the course of a sprint. Naturally, feature and especially release sizes vary. By focusing on milestones one can actually plan and schedule work and releases. This is agile - you can shuffle stuff around. Instead scrum tries to sell fixed size sprints to give impression of steady movement forward, but this decouples sprints from milestones and slightly counter-intuitively reduces agility - shuffling milestones around sprints merely gives you a bunch of unfinished milestones, but also a bunch of finished sprints. But variable sized sprints based on milestones sound too much waterfall-y when the selling point is departure from waterfall.
Interestingly this attempt to squeeze features into sprint-sized chunks is one of the reasons for technical debt that you then must somehow manage, simply because squeezing features comes at a cost of technical debt. There are more reasons for technical debt, but it is slightly humorous when a tool aimed at managing/reducing technical debt introduces debts of its own.
A bit tangential to scrum, but Facebook's story of Hack/HHVM is well-known story somewhat indicative of this. When you size features according to wall-clock sized release cadence (instead of sizing release cadence according to feature sizes) you inevitably accumulate technical debt - new features should build on top of past features, but deficiencies in past features prevent new features from being built on. There are more or less 3 ways this plays out: 1. actual feature release cadence drops due to increased development weight; 2. release cadence drops due to fixup "features" being released; 3. release cadence drops due to dedicated to fixing. Do not get me wrong, technical debt accumulates and impacts release cadence any way, but with feature sized sprints this does not come out of nowhere.
Over the years teams (usually informally) understood deficiencies of scrum process and started throwing pieces of the process away, shuffling them around and having weird mess of system. This is not due to scrum not being well defined, but rather scrum being a hammer in search of nails.
Agile methodologies generally came out of manufacturing - process based workflow. Scrum takes those practices and packages them as a project management tooling. The whole point of agility in processes is the ability to adapt in the middle of the process. Project management, on the other hand, needs plannability and progress tracking. There are weird intersections between the two and IMO scrum fails to satisfy both - neither it is good at adapting mid cycle (because scrum checkpoints mid-feature), nor is it good at future plannability (because it focuses on short term goals). I have seen scrum get distorted in two major ways: either "sprints" get stretched into months long waterfalls, or sprints mostly reshuffling priorities in "in progress" pile and checkpointing progress.