There's several assumptions I read from your comment:
- A guess with a high level of confidence at mindset of people you don't know, and their mindset in situations you're not in.
- Assumption that joking that may happen is fake, again with people you don't know.
- Assumption that a weekly or biweekly standup is ideal for a team you know nothing about - which implies that it's ideal for all teams, of all experience levels, in all projects, in all fields, in all organizations.
Consider that you may not, in fact, be able to justifiably draw these conclusions from the text you just read. Also consider that whatever the personal experience that informs your conclusions is, it's probably not applicable everywhere.
It's interesting how people bring their own context and culture into things - which is where I assume your comment comes from. Also another reason why one size fits all processes or methods are not a good idea.
My team is a monocultural one, in a Nordic country. We're remote by choice, and because some of us live in other cities. Nordic countries have the lowest power distances in the world, which is relevant to how social interactions work out. Also, in my experience, software developers here don't typically worry that much about their standing in the organization, or about advancing in the organization, or being kicked out. Of course some do, but I don't think it's a cultural focus here like it might be in some other places. If you look at the discussion forums for devs here, those concerns hardly ever come up. Talking about raising salary by switching companies is way more common topic.
We have plenty of time for deep work on other days too. It just that in earlier phases of the project there were more meetings, so we set up the deep work day to make sure one day can be totally uninterrupted.
When it comes to articulating problems, I feel our people are vocal enough. Not all the time, but if there's something annoying or frustrating during a sprint, I feel that it comes out during a retro. It's the process improvement ideas where I feel like I'm the most active one - which is fair enough, since it's an area of interest not all people have.
Stand-ups and other Scrum rituals are for a team kind of like routines and habits of a person's life; tinkering with them until they help you and make you happy is well worth the trouble. They can also serve more than one purpose.
I'm the SM/tech lead of our team. Here's how we do stand-ups. It's mostly a result of me suggesting things (I'm also soliciting ideas from others, but they don't seem to have quite the interest in tinkering with these things I do), trying it out with the team, seeing the results, getting feedback and iterating.
1) Before the stand-up, we all write a few sentences on team chat about what we've been working on, what we plan on doing today, and problems/things to discuss. This means we avoid "the round" and the problems associated with it, gives a broad picture of the situation to team members and provides a nice log for later if needed.
2) In the beginning of the stand-up, I make space for some minutes of casual chatting and joking around. This is on purpose, which I haven't told the others. It's not like it's a secret, it just hasn't come up. It's to make the team comfortable with each other and provide light social interaction, which is important in a remote team. Also to make the whole thing a bit more fun, which is a shared interest of everybody. I try to make everyone feel included here.
3) At the beginning I usually go quickly through what is overall situation, based on the chat messages. I note problems and things to discuss that are written there. Then we go over them together relatively quickly; if they don't need to involve the whole team and take more than a few minutes to discuss, they're usually tabled off for the relevant people to discuss after the daily. Before moving on, I also ask if there's any other issues to talk about, and we treat those the same as issues written out beforehand. Once we run out of things to talk about with the whole team, we end the daily. Usually it's pretty short, less than 15 mins, but if it takes longer, it will not be because of boilerplate; it will be because there's things we need to discuss as a team, and since we're already together, might as well do it immediately.
4) After the daily, we often continue interacting, just not everybody together; after all, it's a break in coding flow/focus anyway, so might as well batch the "meetingy" things together. One common thing we do after daily is a live code review over video chat, if anybody happens to have a PR ready. It has different pros and cons than an asynchronous code review; we mix and match both.
We also don't do the daily on Wednesdays and avoid scheduling other meetings on that day - it's our "deep work day".
This way of doing things works for us; the daily stand-up provides cadence to our work, allows us to coordinate and share information and to interact as people. But if one of us has an idea on how to do things better, we can try it out and keep it if works. This works for us; for another team and situation, something completely different may be in order.
Complaining about stand-ups is a common topic among developers, but I wonder how many try to change the way their team does them? Scrum provides the sprint retrospective as an opportunity for all to improve the team's ways of working; that's what it's for. Maybe your team is incapable of change due to authoritarianism or top-down process thinking, but that's a conclusion you reach after you've tried and failed to change things using your social and political skills. These skills include expressing your concerns clearly and avoiding blame, listing the potential benefits of the new way of doing things, listening and understanding different interests people have and balancing them, and framing new ways as experiments that the team can change back if they don't work.
You don't necessarily get better at <thing> by just routinely doing the <thing>. If you drive mostly the same route every day for ten years, you'll hardly become any better driver. If you keep adding similar boilerplate bulk code by routine in your work, you'll hardly become any better programmer. You don't become more socially skilled through social interaction if you just do the routine things to get by.
To learn things well, you need feedback loops. To learn from your social interactions you need to
a) get the feedback. Not smelling bad is a basic social skill. Yet many people smell bad because nobody tells them that they smell bad. What are the ways you could get more feedback? Is there somebody you could ask to tell you what to do better?
b) interpret the feedback and care about the feedback. Some people are better than others in interpreting subtle social cues (nuances of words and expressions, etc); they will naturally get better in social skills faster. Some people are more open to feedback and willing to improve than others (e.g. Not going "she doesn't like the way I smell, huh? Oh well, I'll forget about it"). Fortunately, these meta-skills can be improved; just accepting that they are important is a good first step.
- A guess with a high level of confidence at mindset of people you don't know, and their mindset in situations you're not in.
- Assumption that joking that may happen is fake, again with people you don't know.
- Assumption that a weekly or biweekly standup is ideal for a team you know nothing about - which implies that it's ideal for all teams, of all experience levels, in all projects, in all fields, in all organizations.
Consider that you may not, in fact, be able to justifiably draw these conclusions from the text you just read. Also consider that whatever the personal experience that informs your conclusions is, it's probably not applicable everywhere.