I saw this poll on my Instagram this morning.
I think people are focusing on the details of standups and missing the point of them. I think people do this all of the time, whether it's scrummy-related process issues or code architectures.
In my second book, Info-Ops 2, I list a bunch of real-world things you can and should do right now when you code: measure and manage Code Cognitive Load, Code Budgets. Create True Microservices using an Onion Architecture if you want to have an easy time of architecture at scale.
These are not "do these because I say to do so" things. These are natural consequences of learning how to program in ways that are easily maintainable and modifiable.
Humans are extremely good at creating complex structures that they themselves do not understand, as much as they might pretend that they do. In knowledge work, structure is infinitely-divisible. You can keep making as much detail as you'd like, then add in some more. The purpose of Code Budgets was to say "You know, we need to arbitrarily limit structure creation in order to provide a check on our ability to over-complicate things"
Standups are supposed to eliminate meeting culture in organizations. If you can't eliminate most meetings with a 5-min daily check-in, you've got too much overhead. It's code budgets for process.
You can manage a 200-person program with 5-minute daily team standups. I've done it. Or you can spend an hour every morning on a status report death march and call it standups. Seen that too. It was painful.
Markham's rule of big numbers: anything times a big number is a big number. That is, since you can break stuff up infinitely, there's no limit to the amount of detail you can have and want to track in your project, much the same as there's no limit to the amount of code you can have and want to maintain to solve your problem. Code Budgets start us down the path of fixing this. If you don't apply these coding principles to your process, you're eventually going to regret it.