[JohnFen]

Standups could make sense in a team that isn't operating well, but in a well-functioning team, everyone is having these sorts of discussions with each other during the natural course of each workday anyway. Standups are unnecessary then.

My experience with standups is that they're almost entirely worthless. They're rote and performative and rarely, if ever, provide anything that was missing.

[MajimasEyepatch]

It's still valuable to share information about progress and impediments with the whole team. Alice and Bob may have some blocker that they've been communicating about, but Chris wasn't a part of those one-on-one conversations, so the standup gives him some valuable context about what's going on with the rest of the team. Maybe his work depends on something Bob was supposed to complete today that's going to take a few more days, or maybe he's encountered a similar problem before and has some advice, or maybe he'll remember the issue when something similar pops up later on. Alice and Bob would have resolved the blocker themselves, but this helps make sure the information is shared across the team in a way that simply moving cards on a kanban board wouldn't communicate.

[leetrout]

If you need a designated meeting for communicating with your teammate you already failed the qualification of highly functioning team.

[MajimasEyepatch]

The point is that it's a teammate who wouldn't ordinarily be involved in resolving the issue. There's still value in them learning about it.

[gunapologist99]

Sometimes, but most of the time it's probably going to waste their time (times ten).

[convolvatron]

I've begun to believe that all of this ceremony is driven from an unspoken belief that well functioning software teams are a myth.

sure it would be great if people raised issues themselves instead of skulking. were proactive, took pride in their work, engaged joyfully with their collaborators, and developed real consensus and velocity.

but that's just a fairy tale. developers are generally useless, stubborn, lazy, petty, and fundamentally disorganized. lets not shoot for the moon and try to get them to work together. lets just dumb the whole thing down to try to get _something_ out of them.

[kstrauser]

I disagree. Especially with remote teams, standups are how I find out that other people on the opposite end of my team are blocked on something I can easily help them with, or that they're doing something that has implications on my own work. I communicate with some people continually. There are others I'd hardly see if it weren't for standups.

[JohnFen]

> There are others I'd hardly see if it weren't for standups.

If that's a problem, it's a sign that the team is not functioning well. Standups can be a band-aid for the issue while a real solution is being developed, but it isn't a long-term solution in and of itself.

[leetrout]

This is exactly what the parent is calling out. Using a standup as a bandaid for fundamental team behavior.

[prepend]

> but in a well-functioning team

I think the routine maintenance is key for staying well-functioning. The problem is that once things are not functioning well it may be too far along to fix.

So it’s like saying why should married couples have routine date nights because if they were well functioning, they wouldn’t need to schedule. The point is to function well and it’s a useful technique.

[JohnFen]

But since in a well-functioning team everyone knows where everyone else is already, there is nothing that can be said in a standup that isn't already on everyone's radar.

Maybe I'm just unusually fortunate to have mostly worked on well-functioning teams.

[prepend]

Part of the way they achieve that knowledge is through the standup though.

Maybe you are super fortunate. Standups are just one method too. It’s not like it’s dogma and must be followed.

But it’s a useful technique. So saying it’s unnecessary seems odd. At least generally speaking.

[rkuodys]

I think that there is separation between intentional knowledge transfer and accidental. It's great as an opportunity for accidental knowledge transfer, where one developer didn't know she could ask for help by another developer. Or that task can be picked up because it hasnt changes the status yet( not released) but other can start working if needed.