Scrum as defined in The Scrums Guide is a very specifically defined process with a few degrees of freedom, not a process design framework.
Now, if your approach was actually Agile (unlike the many groups that do Scrum, either as defined in the Guide or some variation they've cobbled together from other sources and still call “Scrum”, and think that by doing so they are therefore Agile), any canned process will be at most a starting point and input into what works for your team. But that is very much not Scrum as it has been propounded from the beginning, including by it's creators.
> Kanban is also not a process but a system for continuous improvement
Kanban is a very specific process element related to flow visibility and management.
"Scrum is a framework" immediately follows the "What is Scrum?" heading on https://www.scrumguides.org/ also Jim Coplien directly told me the point of the Scrum framework is to design your own process.
Regarding Kanban - I'm talking about the Kanban used in software development as defined by David J. Anderson and not the token used in manufacturing by Toyota and DJA himself previously wrote "Kanban is not a software development lifecycle methodology or an approach to project management. It requires that some process is already in place so that Kanban can be applied to incrementally change the underlying process." and "Kanban is a change-management technique that requires making alterations to an existing process".
Scrum as defined in the Scrum Guide prescribes very little. It's not much more than "Have a development team, a scrum master, and a product owner, have a product backlog, have developers plan their work, and work in time-boxed increments." Nearly every other aspect of how work gets done is unspecified and can (and should) be evolved by the team based on empirical observation.
My observation is that people have a tendency to adopt a version of scrum that is based on certain "default settings" that everybody sort of assumes are required, when they aren't actually. Two week increments, for example. I've heard so many people complain about scrum mandating two week increments, when it doesn't actually.
Or people complain about "velocity", and "story points" which are likewise not part of scrum at all.
No, it's not, the whole classic litany of scrum rituals (“scrume events” in the guide’s language) is prescribed in the Guide.
> Two week increments, for example. I've heard so many people complain about scrum mandating two week increments, when it doesn't actually.
That’s strictly true, but somewhat misleading, as while it doesn't mandate two-week sprints specifically, the guide does specify that sprints are not more than one month. (And that they have “consistent duration throughout a development effort”, which is probably a more problematic command. But the most problematic is using synchronized iterations rather than flow for dev work, and locking the time cycle for product iterations to the time cycle for process improvement.)
> Or people complain about "velocity", and "story points" which are likewise not part of scrum at all
Yeah, they are an attempt (and, used as designed, probable the best attempt yet) to deal with a well-documented hard problem un software development which Scrum just assumes is, and requires to be, solved without really commenting on directly. I have far less complaints about them (except that people cargo cult them badly) than Scrum, which, while also subject to bad cargo-culting, has a lot of it's problems baked into the fundamental spec.
Resorting to definitions is not helpful, when you work in a dysfunctional organization, and instituting Scrum was the root of the disfunction.
I am certified as a Professional Scrummaster, and none of those things were taught as part of any training I went through, nor were they mentioned on the certification test.
Referring to definitions is useful, when many people are misunderstanding the definition. If anything, we should be screaming from the hilltops "For the love of FSM, go read the Scrum Guide, and the Agile Manifesto, and show your managers and shitty Scrummasters what they're doing wrong." If we, as developers, are not willing to draw a line in the sand and take a stand sometimes, then what right do we have to complain? And if management won't listen to us on this, they aren't going to listen to us on anything else and we're back to "toxic management is the problem, not scrum."
Looking at 'scrum master certification test questions' online I don't see anything about technical debt, variable-length time boxes, re-prioritizing work during a sprint etc.
A real and reasonable criticism of Scrum or Agile is, the structure is not helpful to the actual work. Sure, making a list of tasks is quite useful. But the time-boxing and task atomizing can dissect the work to the point of dysfunction.
If nobody is doing Scrum right, we're right on the edge of a No True Scotsman argument.
That seems orthogonal to the question of how desirable (or not) scrum is. You can have scrum (or not), and/or have "an experienced team that respects the other team members to plan their time and prioritize tasks" and shitty management is still going to wreck things.
A real and reasonable criticism of Scrum or Agile is, the structure is not helpful to the actual work.
I 100% agree that there are times when the structure imposed on a team in the name of Scrum (whether it's actually prescribed by Scrum or not) is harmful. Don't mistake what I'm saying here as a massive endorsement of Scrum. It's not actually my preferred methodology. But I do think Scrum can be useful to very many teams in very many situations, and I feel like a lot of the criticisms directed at scrum are somewhat misplaced.
I think I get what you mean by that, and I probably agree to a point. But I don't think it's quite "No True Scotsman", as Scrum has an actual definition, to an extent that "true Scotsman" does not. But I'll buy the suggestion that "if everybody is doing it wrong, then there's something fundamentally wrong with the whole situation".