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.