Quite the opposite. Standup take no longer than 15 minutes, we frequently address issues which otherwise would have led to lots of rework. You need some discipline to do it right however.
Lot's of engineers are afraid to ask for help, or too proud. The standup helps people get help sooner. It also often shows where two people are actually doing the same thing, take a wrong path, help prioritize etc. I can't imagine a software project without a standup anymore.
It's funny, if I would pick out the two single most valuable things out of agile I would say standup and peer review.
I've never seen what you describe actually happen (although I know that this is the theory behind it).
TBH I haven't really noticed much difference in the accomplishments of scrum and non-scrum teams.
As a former manager I had enormous fun tweaking and tuning the morning stand up to actually get it into a useful state. As with anything involving people there are complex dynamics, there are people who talk too much, talk too little, go off on tangents, only talk about what they want to do, don't mention blocks, insist on asking questions, Some talk too much- but only if they're the first to talk, some will always talk as much as the person before them.
It is very very difficult to get a group of engineers to have a productive stand up meeting.
Most likely because it's such an artificial construct. There are some people who will only talk when forced to. Others just won't shut up. Others try to embellish because they may not have "enough" to report at that time and don't want to look bad.
Ultimately, my experience has been that stand-up meetings slowly devolve over time into status reports, people don't listen during meetings, and if someone needs to know something, you pull them aside later talk with them (because it's almost certainly going to take longer than your stand-up allotment).
I just can't see any actual benefit to this process that was invented out of whole cloth (not to say that trying new things is bad - even invented things; rather, they should be tested and measured). What can't be measured can't be invalidated.
The key is being intentional about your process, no matter what that process is. If you can put in place strategies to solve all the problems standups are meant to solve, that's great, but the standups weren't originally designed by middle management, they were designed by engineers for a purpose.
I have found your problem.
If different people start at different times (the norm in tech), then there's no such thing as "first thing in the morning". You must interrupt people, which means that you should make sure it's more beneficial than the cost of interrupted flow.
This is not a reasonable argument.
lol. too true.
The most common sin is the standup, where each person talks for 5 minutes about something while everyone else tunes out. It's a complete waste of 30 minutes a day, made worse because you're tired of standing and just want to get back to doing things or meeting with people you actually need to meet with. I understand the theory behind it, but I haven't seen that actually happen in my entire 25 year career.
Next up is the sprint, which I've actually seen work somewhat in some companies. Generally, when they're doing it right, they'll have a "next up" lane for things that someone is serious about, in priority order, and actively maintained by the stakeholders (with an arbiter). And then the "backlog" is a black hole where things go to die (which isn't a bad thing). People grab from the "next up" lane the things they think they can get done in a sprint (keeping in mind the priorities), and off they go. That's the best case. More commonly, it's a morass of crap nobody cares about anymore, complete with questionable tasks, top-down requests (with no pipeline to discuss), or not broken down into manageable chunks.
Generally, when companies adopt "agile", there's a lot of paperwork, meetings and activity, but very little communication and accomplishment. The only worse thing I can think of is peer reviews.