[jukvalim]

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.

[UweSchmidt]

Points for keeping one day meeting-free and batching meetings together. Deep work is the only useful kind of work, so getting one day of that is something! I'd be radical and suggest another of those deep work days to double productivity, but refering to your last point, organizational changes initiated by the team members are rare.

Generally, good changes would require scrum masters and tech leads to work harder, to really get to the bottom of a wide range of issues outside of superficial meetings, to actually understand how developers, testers and devops struggle, and to solve those problems. But it's easier to put the burden of articulating problems through public speaking on generally introvert developers who then risk incriminating themselves in the process.

> 2) In the beginning of the stand-up, I make space for some minutes of casual chatting and joking around.

In a work environment it is extremely hard for people to truly enjoy jokes and chats when everyone, including soft leadership, is present. People are very much concerned with their standing within the organization and if they are good enough to remain, or advance. If that is not an issue, frustrations with many work-related disappointments and sometimes colleagues are main concerns for software people. It would take a truly remarkable individual to lead such a casual time of cracking jokes in everyone's second language in multicultural teams over video call, when their livelihood or sanity is on the line, rather than it being a stressful performative act for half the team.

[jukvalim]

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.

[yrgulation]

> but they don't seem to have quite the interest in tinkering with these things I do

They are probably bored and planning an escape. You have no idea how visible the scripting is, including all the fake joking around step. Engineers are not children, and if they are you hired the wrong people. Let them get on with work, and do a weekly or by weekly standup instead. Be sure to … “empower” them to talk to stakeholders and let them be proactive.

[jukvalim]

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.