> "Not sure what this has to do with Scrum or the low complexity of Scrum, which fully can be explained in a small book or a week of training."

Earlier you made a disingenuous comparison of the relative bloat of RUP and Agile RUP in comparison to Scrum. The relative overhead costs of Scrum compared to those other methods don't matter. Only the overhead of Scrum compared to low-overhead and low-formalism methods that deliver the same business outcomes.

> "Basic knowledge: a NLP developer is not a front end developer. Yes, you can add and remove people from teams during the runtime of a project."

Scrum, despite not explicitly saying it in any formal documents, facilitates managers in avoiding adding or removing of the right specialized people, by creating an expectation that every engineer ought to be trained as a full-stack engineer, and using language that makes it sound like every team ought to cover every possible domain.

> "If your management is too dumb or you are too easily fooled by management, don't blame Scrum."

How is this relevant? No one mentioned dumb management nor workers who are fooled by management. We are talking about how Scrum encourages and facilitates this kind of behavior, even among earnest management and fully-aware teams. It seems like more of the same No True Scotsman fallacy for you to presume it can only be caused by "too dumb" management or teams being "fooled". Yet again, in your description, the bad stuff cannot happen in a "real" Scrum setup, only in a "bad" one where people are either dumb or foolish. Defining away your problem.

> "True. But that has nothing to do with Scrum."

False, Scrum explicitly holds it as a principle that teams should always be cross-functional. Scrum doesn't allow the possibility that e.g. front-end work for a wide variety of products should be separated into a single front-end team, and corresponding backend work separated into different backend-specific teams. It advocates that all teams working on projects with front-end and backend needs should be both front-end and backend teams. This is very much a direct problem with Scrum itself.

> "Scrum does not impose an unilateral model for all projects."

This is one of the defining properties of Scrum. A unilateral choice for sprint length, format and frequency of planning meeting, details of required story point estimation, daily stand ups, required retrospective, etc. Scrum doesn't allow omitting these things when they are not useful. There is a tiny amount of customization allowed (e.g. t-shirt sizes instead of story points, or 3-week sprints instead of 2-week), but it's meaningless in terms of what a team actually needs to customize (which is stuff like dropping estimation all together, and e.g. only hold occasional retro meetings scheduled in an ad hoc way at the team's convenience, not enforced every X weeks as part of a sprint).

> "It's just more likely to succeed with Scrum in situations like small team (10 people), product development, changing requirements, responsive customer, etc. etc."

My experience is the opposite... that adding Scrum in exactly those situations just means we have to do extra boilerplate work to get the same end product finished on time, and that Scrum is not more likely to succeed than other methods.