It's not especially constructive to to reply to a detailed article on "X is bad" with simply "you're doing X wrong", without offering additional advice on what the author has missed or how to do it right.
It's almost a tautology: "My time machine doesn't work." "Well, maybe you didn't build your time machine right!"
What do the effective teams you've worked with do differently and better than the author's? How do they avoid the pitfalls, or why are the problems not problems that the author outlines in "three general arguments" against it? What kind of variation in teams should the author account for?
Standups do provide a useful habit of synchronizing regularly. More mature teams can probably do this without a scheduled meeting.
In an Extreme Programming team provide a good opportunity to swap around pair-programming partners.
It's also a good opportunity to decide how many tasks the team has capacity to take on today, which isn't entirely straightforward. There may be someone off sick which means we can run fewer pairs. There might be an urgent production issue from overnight which requires a pair's attention. It might be that one of the next tasks needs some research and doesn't warrant a pair. It might be that one of the next tasks is a bit challenging/contentious and could benefit from mob-programming[0].
They are also useful to update team members who have been away or stuck in meetings, and for them to update the rest of the team. Not everyone can be in all conversations all the time.
As with most agile practices the mantra of "If it hurts, do it more often" applies well to standups. Synchronization is useful when working in this way but it shouldn't need to be long and painful. Having multiple focused sub-5 minute standups is better than one that drags on.
e.g. break along functional lines. Limit morning chat to what are we doing today, who is working with whom?. Have separate sessions for updates on progress, discussing impediments, or product planning updates.
Informal "huddles" work quite well too. Convene everyone ad-hoc when there's a decision to be made or as soon as an impediment arises.
When mob-programming most of the reasons for standups disappear. The whole team stays synchronized all the time.
Here are a couple things we tried for our scrum teams.
We let them choose the time of the day for the daily stand-up. One team agreed on 11am. Another on 5pm. Some people see this 15 minute stand-up serves as a major interruption. I see it as a way to consolidate some of the tiny interruptions throughout the day into one.
Also teams have individuals of varying experience so we consider the stories to be a team goal. This makes the more experienced individual more willing to help those still learning since they are no longer making a trade-off for their own stories vs somebody else.
Lastly, I've worked on projects from 1-20 people and beyond a certain size, daily meetings are just mandatory or things fall apart. In a previous project, I ran these big daily status meetings and they tended to run long. Everyone hated it so I dropped it for a few days but then the code started breaking due to lack of communications. We decided to split the meeting into smaller groups and they ran quicker and there were less complaints. However we were still able to keep the code quality.
But I think the most important things is "one size doesn't fit all." If something is not working, have an open discussion within the team and suggest some alternatives. If there is no avenue to give feedback, that is the fundamental problem.
> We let them choose the time of the day for the daily stand-up.
Small anecdote about choosing stand-up time: We previously had stand-up at 9:15am, but management wasn't happy that we would all immediately after go for coffee (taking around 10-20 minutes). So standups were moved to 9:45 on the condition that we would get coffee 'before work'. Instead what happened was that people wouldn't get into work until 9:43am and everyone still went for coffee after standup.
Interesting language. "We let them" sets of an alarm for me. Why do they need to be allowed to the choose time of day? Are they not self-organizing? Or is this organization still in the midst of transformation?
Yes we are in the midst of a transformation and most people are new to this. And those with previous experience with scrum teams had lots of bad experiences elsewhere (hour long stand-up meetings and inconvenient times, etc.)
It's almost a tautology: "My time machine doesn't work." "Well, maybe you didn't build your time machine right!"
What do the effective teams you've worked with do differently and better than the author's? How do they avoid the pitfalls, or why are the problems not problems that the author outlines in "three general arguments" against it? What kind of variation in teams should the author account for?