A well run standup is a minute per person, max. It ensures everyone pulls their head up out of their work long enough to highlight obstacles that might effect delivery, or that someone else on the team might be able to help with, while also ensuring there aren't constant interruptions throughout the day.
I have been in good standups and bad standups, sometimes at the same company.
A bad week-after-week standup was one that dragged on and on, and started at 8AM because that was evening time for our off-shore team which the US team knew was going to be canned in a few weeks. Each person would go on and on, on a bad connection in a thick accent about what they were working on. Between the connection, and accent, and knowledge they were all junior and working on minor tickets and flubbing them and all soon to be getting axed, I did not pay attention when that off-shore team was talking. It was all a waste of time for me.
On the other hand, I have had standups where the scrum master (or product manager in the scrum master's absence) would keep the standups to 15 minutes, and if anyone went on too long or some conversation went on too long he said they should continue what they were saying after the standup, and anyone who needed to hear it could stay. Standups were brief, and sometimes productive if I heard something I needed to know, or was blocked on something and was offered help. And if I or someone else was still just plugging away on something, we would say "I worked on X, still working on X, no blockers" and the meeting moved on.
Insofar as chat, some people get to the standup a minute or two early, and after the hour for the first minute people would still be joining the standup, and people would sometimes chat then.
I hope I never have to work the managers who allowed this to go on. Treating this way the people who potentially didn't feel empowered to push back, is an indication of how they would treat others in a similar situation.
In that 30 mins we also handle bug reports and assign blah blah blah.
Those 30 mins are 100% focused to stuff people are working on, except for an initial 5 mins or so of chit chat. It's massively efficient and massively productive. So whatever the writer of this article was doing, it certainly wasn't a standup. I'm not big on prescriptive process, but a well organised standup is unbeatable.
If you wouldn't feel comfortable standing with a coffee for the duration of the standup then it's too long.
30 minutes is far too long and is well into conventional status-meeting territory. Aim for 10.
Flip the premise of the meeting from "who's working on what" to "who's blocked by what". If there's no problem, say nothing. Not only does that save time, it is also more empowering for those with problems because they're not "swimming against the current" of those who are reporting their successes.
If everything is going well, it's five minutes spent.
If anything -isn't-, it's five minutes spent highlighting where additional interaction needs to take place.
Even if everything is going well, a status update can be "I'm working on X, no blockers", and someone else can still say "Oh! I've done X! Let me know if you need help", setting the team up for avoiding future obstacles.
Without it, you'll have people hammering at the same problem for days without raising it up because they don't realize anyone else can help them. Or reinventing the wheel because they don't realize someone else has already done it.
Etc. Done right, it's an excellent way to spend 5 minutes. Done wrong, it's a waste of an hour.
Giving people time to express that they are being blocked or that they need help with something increases the chances that they will feel empowered to ask for help or to be unblocked. It also aids in accountability and ensuring that people are getting their work done on time and as agreed with stakeholders, as well as giving other team members an opportunity to mitigate any such issue.
On the other end, formalizing that it is short prevents it from turning into an unexpected retro or venting session or long-winded technical discussion better left for some other forum. Everyone should be able to give a quick update before any member of the team loses interest.
There are reasons behind all of these things, and as aware as I am that not everyone agrees with every tenet of every leadership strategy, the "standup" as commonly formalized is actually really solid and I would expect a good reason not to employ it in the way that it typically is.
Additionally, it may highlight that the team underestimated the size of a story or perhaps that the story should have been broken down further.
There was never any resistance there, and I've never encountered friction in that vein anywhere. No cto or vpe above me has ever wanted to get in the way of someone productive getting into a multi-day flow state anywhere I've bothered to work that hard. Peers or underlings however, the competition that is, it's a different story I mostly ignored.
Having said that, I found standups to be a very obnoxious, passive-aggressive tool management used for dealing with folks unable to maintain a relevant and correctly prioritized todo list, and stay on task day-to-day. It's a group I've dabbled in being part of at some employers, and found quite unfulfilling and frustrating because management is way more meddlesome in that mode and individual leverage is practically nonexistent without playing the politics game well. YMMV
No kidding. Seeing this failure mode is unfortunate because it's not an immediate killer but it's a lethal one once it sinks its teeth in un-opposed.
> what if people are working on something for a bit longer than one day and got no news to tell or talk about?
They can just say that they are busy on it. But now the team can coordinate.
Maybe that feature is taking too long, and you should instead spend time on something more important.
Maybe Jerry says "hey, I'm finishing up on issue XYZ. Now I can go help you with that long task."
Maybe you are working on that long task, but hear that another team member has a problem which you know a lot about.
Maybe someone in the team is thinking of starting a new issue which is related to your long task, in which case some coordination may be needed.
Maybe someone thinks your long task is shouldn't be taking that long and they can afterwards help you out. It is easy to get stuff in a bog and not know it.
Scrum is meant to be a team sport where members are helping and supporting each other.