Scrum disempowers developers

Sure.

- When working on a team whose primary outputs are highly specialized research, the necessity to have planning meetings, standups, retrospectives, etc., according to a single fixed schedule causes a lot of problems. A better practice is to allow the length of a sprint to be variable and to be different for different individual team members depending on what they are working on. Elminate overhead that's not helping by discontinuing a fixed-cycle planning meeting (e.g. don't do it every X weeks, rather just arrange planning meetings in an ad hoc way whenever enough items reach a state where a group planning meeting makes sense.) If your team is working on projects that need a longer time to ruminate and develop at the moment, then cancel the retrospective meeting and just do it later after some other milestone. Basically, treat these things like collegial, flexible, malleable tools whose timelines and cadence flexibly changes all the time in response to current projects.

- When working on fundamental research, notions of incremental progress are not useful. You might spend weeks on a problem and have no demonstrable new functionality. You may not even have any research or documentation to share. You might only be able to say, "I worked extremely hard on methods X, Y, and Z, and I appear no closer to know whether they could work or not. Need more time." So in this situation, estimating story points is absurd, and reporting velocity is at best a nuisance but more often harmful because you can count on upper management questioning it with inappropriate comparisons to the way velocity works for iterative software work. Later on, maybe several weeks later, you might have a breakthrough on the tough research project, and now you are at a point where you need to productionize the supporting software that wraps it, and you do get value from estimating time to completion and using iterative cycles of incremental, demonstrable units of functionality. So once again, it should be flexible. Many times, there is no use whatsoever to estimate story points, so don't do it. Don't use a concept like velocity for these case-by-case situations at all. Then later, if you find value in switching back to an estimation-and-velocity approach for productionizing it, then do so.

I could go on, but the general idea is that it should be highly flexible. No fixed set of meetings that must happen every sprint no matter the work context. No enforced policy of always estimating story points or always tracking velocity. That's no flexible, it's rigid because it says you always have to do it that one way, and leaves no room for situations when that one way is not useful, or when it adds costly and time-wasting overhead during periods of work that don't benefit from it.

These things should be left up to the team to decide, based on what type of work the team does, how it varies over time, what feels low-overhead and liberating, what facilitates productivity for that team.

> "You're comparing Scrum to a phantom."

No, I'm not. And I have not been at any point in earlier comments either. Your comments are just needlessly antagonistic while constantly deflecting without dealing with the fundamental problems of Scrum.

> "Otherwise it's just a complaint with no useful contribution."

Complaints are often useful contributions all on their own. It's foolish to claim that complaints have to always be accompanied by candidate solutions to be useful. No. Knowledge of the details of the complaint is useful all on its own. Regardless though, this is still a lazy mischaracterization of anything I have been writing.

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.

Exactly. This is why it's stupid when managers get all hyped up about and decide everything needs to be shaken up based on what they learned at a seminar or heard from some consultant/"coach".

For the most part, those 3 points seem like easily understandable ideas, and have been used in some form by other industries, such as manufacturing, for a long time before they were presented for software development. Replace "PM" or "Scrum Master" with "Foreman" and you can get the picture of what activities are involved with a worker managing other workers and the work that gets produced.

There is so much over-complication with the current system of methodologies and nebulous acronyms that accompany it[0]. There's SAFe, Agile, Scrum, Scrum of Scums (recursive scrum??), RAD, LeSS, etc. It gets confusing and messy very quickly. Instead of focusing on doing the work, it's easy for managers to get swept up in the semantics of these frameworks and end up hurting the work by over-thinking and over-applying the principles on the workers. Scrum methodologies are guidelines that can be tweaked to fit the situation, and don't have to implemented if they don't make sense. Instead of thinking "Does this make sense?", the manager/business side tends to think "Well, it worked for X, so it must work for me!". Scrum is an editable template that should help eliminate wasted effort and mindless work, and if that's not the case then it isn't being done right.

[0]https://en.wikipedia.org/wiki/Scrum_(software_development)

Every time I see a shop with designated Software Architects who hog the architecture work, it's a fucking mess. Because then Software Architects don't get rewarded in their careers for making software. They get rewarded for writing white papers and coming up with "brilliant" architectures and impressing executives who know less than them about technology. Which is mostly inversely correlated with actually making it easier for developers to get real work done.