> "State which specific practices work better than Scrum in specific situations."
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.