it depends on the tone of the standup. For a start they should be quick, and the team needs to be fairly small (about 5-6 seems ideal). and cohesive, mostly wo

it depends on the tone of the standup. For a start they should be quick, and the team needs to be fairly small (about 5-6 seems ideal). and cohesive, mostly working on related or interacting code. Also I assume remote, as that's my experience. The status update part should be extremely quick even perfunctory, unless there's an interesting lesson or important caveat or note-bene etc to share with the team. The reason for the standup is to make sure everything is "joining up" properly, no new obstacles are looming, and possibly to plan meetings/pairing sessions/etc, for later that day, where required. ie like a football scrum where you agree the game-play for the day. It's also chance for a bit of "team bonding" type stuff, eg to ask the whole team "are we all feeling good about this sprint", etc - ie, the kind of stuff that may not obvious from stats If the standup just becomes a forced "status report", that's worse than useless, I agree, and just makes everyone feel "monitored" and under pressure. I would guess they are also less useful (and potentially more stressful) where everyone is physically present, and might be seen as a trick to get everyone to the office on time.