A Note on the Daily Standup
Apparently, (scrum) standup meetings are broken. It seems that way at least, because making suggestions for how to fix them seems to be a seminal favorite topic in programmer blogs; so it must be true. Right? Either way, I'll add my two cents.
I should say up front that I'm completely on board with the agile (scrum) train. I'm drinking the Kool-Aid. But, I get it. There are a lot of organizations out there who are doing this badly, for a lot of reasons. If you feel like your daily standup meeting is a waste of time, then it's probably the case that your organization is one of them. And even if not, it's easy to get lazy and fall into a routine where everyone just gives their update and doesn't really listen to most of what anyone else is reporting.
Where it goes wrong
The daily standup meeting should be quick and informative. It's probably going too far to say that it should be fun, but at a minimum it should be a clear net positive in terms of time spent for value gained. So, the goal then should be to minimize time and maximize useful information. Going around in a circle while everyone just repeats that they're "still working on the foo story" is exactly the wrong way to achieve that goal. It takes a surprisingly long time, and no one learns anything. Of course everyone is still working on their task. Likewise, going down the board and getting updates on each story has the same result: "I'm still working on foo; I'll start bar when I'm done."
Now, there are probably systemic organizational reasons that contribute to standup meetings devolving into that kind of pattern. And the internet is full of suggestions for getting the team to pay more attention. I've done round-robin scrum master (also called popcorn scrum). It sort of works. Most of those suggestions don't really change anything though. The objective of the daily standup according to basic agile best practices is to have each team member answer the Three Questions®. And those are: What did you do since the last standup? What are you doing now? What issues or concerns do you have? But here's the problem: no one asked any questions.
Ask the questions
So there's my suggestion. Actually ask those questions. Or rather, any team member can and should ask any other team member about their tasks. No one is "running" the meeting, taking reports. No one is obligated to volunteer an uninformative progress update (although they should still bring up issues). Instead, the standup meeting goes like this:
Jane: "Bob, how's the foo service coming along?"
Bob: "I'm still exploring the backend API, so I haven't written much code yet."
Jane: "Oh, well I need the controller so I can work on the foo-tastic widget. Can we at least stub that out for now?"
Etc.
All of the other concerns still apply, of course. You still need to keep it short. You still need to move detailed discussion outside the meeting. You still need to limit participation to actual team members. The difference is that the people who really should care about a given task are actually speaking to each other about it. If nothing else, at least those people will be paying attention. And it's important to remember that the product owner and scrum master are part of the team. So if you have one developer off on their own working on something that somehow has no dependencies and no dependents, then those people should ask about the status of that story.
I'll end with a final bit of wisdom. None of the structure or ritual or anything else that goes along with your chosen flavor of agile Kool-Aid is actually required. But you should do it all anyway. At least to begin with. The idea is to grow a more collaborative and communicative team. You're also trying to establish routines so that you can achieve predictable results on predictable timelines. If you can work in some regular improvements along the way, so much the better. The structure and ritual are there to guide the process, but they are not the process itself. As your team matures together, you should absolutely experiment. And occasionally you should revisit the basics.
The minute you get away from fundamentals [...] the bottom can fall out of your game, your schoolwork, your job, whatever you’re doing.