Pretty sure this was meant as a joke, but besides practices like this actually excluding disabled people, most tricks to keep stand ups short won’t work.

Here’s the only thing that in my experience has helped keeping stand ups short:
Better genera work culture.

(Thread) https://twitter.com/silindsoftware/status/1275108857778446339

The times that I’ve been in stand ups that last way way too long it’s been because of one (or several) of the following reasons:

1) Lack of trust.
People ended up explaining everything they were working on in detail, each standup (daily, often repeating themselves!) because it was the only way to show management that they were actually working.

2) Bad meeting culture.
People didn’t get the opportunity to discuss work with coworkers outside of standup, or the meetings/workshops they had were inefficient. So they grabbed the opportunity during standup to discuss.

3) Lack of follow-up.
If you mention during standup you’re blocked, but need to chase people time after time to actually get their help, of course you’ll eventually try to get it solved during standup.

4) Lack of information/communication.
This is one I’m guilty of - the times I “over shared” as a mainly front end engineer in a team of mainly data scientists, it’s because otherwise no one would know what I’m working on.

The reason, for me, that long stand ups are annoying isn’t because they’re long. I think meetings and workshops are very valuable.
Long stand ups become frustrating because they’re often recurring. And what’s being shared is often only useful to one or two people.

So we end up with a daily long meeting (often right before lunch) where everyone is just waiting for their turn to talk, while not receiving much useful information and not being able to do much else.

The issue for me isn’t the time, the issue is the format and the information.

The best stand ups I’ve had were when the scrum master/PM/mediator/team lead was well prepared, led the conversation, and actively followed up.

You were blocked by someone? She’d send them a message afterwards. You didn’t have enough to do? She’d have neither issue ready.

She came prepared to each standup, knowing exactly what people were working on according to Jira, and just needed to know if you were on schedule, ahead of schedule or behind schedule. Then she’d take the right action.

Rarely was there a need to turn standup into a debugging session, because she’d help you schedule a debugging session if you needed one. No one felt the need to “prove” they were actually working, because she proved us that she saw our effort.

Everything else is just a quick temporary fix. We still had our stand ups right before lunch and in a meeting area, which helped keeps things short.

But those tricks only work (again, in my experience), if the rest is in place as well.

As with everything else in tech, the right solution to a problem starts with investigating why the problem happens. The “why” is important. Solve the “why” rather than the effect it has.

(This ended up being a really long thread, but I’m really tired of really long and badly managed stand ups so as soon as you manage the topic I’m gonna go on a rant like this. Sorry not sorry.)