[dragonwriter]

> Scrum is not a process it’s process design framework

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.

[richliss]

Part of the reason for the Scrum Patterns movement which is helmed by Jeff Sutherland and Jim Coplien is that the Scrum Guide isn't all that great or clear. There's politics behind that and also attached to how it's changed/updated too.

"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".

[mindcrime]

Scrum as defined in The Scrums Guide is a very specifically defined process with a few degrees of freedom, not a process design framework.

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.

[dragonwriter]

> Nearly every other aspect of how work gets done is unspecified

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.

[JoeAltmaier]

They are certainly part of Scrum-master training. They're a widespread practice. At this point, they can be grouped as 'part of Scrum' with fair confidence, in any implementation you can point to.

Resorting to definitions is not helpful, when you work in a dysfunctional organization, and instituting Scrum was the root of the disfunction.

[mindcrime]

They are certainly part of Scrum-master training.

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."

[JoeAltmaier]

Or, not do Scrum. Do another process, like having an experienced team that respects the other team members to plan their time and prioritize tasks, with good communications between members of the team.

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.

[mindcrime]

Or, not do Scrum. Do another process, like having an experienced team that respects the other team members to plan their time and prioritize tasks, with good communications between members of the team.

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.

If nobody is doing Scrum right, we're right on the edge of a No True Scotsman argument.

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".