[nemothekid]

>It serves multiple functions, but the most important is the last bit: "are you blocked by something?". Most of the time, someone else on the team knows how to unblock you

To preface, I'm assuming you are talking about daily standups. How often do you see this actually working for you? In most cases, if someone is blocked, then they would communicate that, either to a manager or a coworker. If someone is blocked for days at a time and doesn't communicate anything, thats a problem in and of itself.

I'd like to get more value from them, but most times the devolve into "status updates" and then all engineers end up blocked by the standup.

[mobjack]

Blockers are not always obvious.

People don't always realize that their tasks is blocking someone else.

Often times when engineers are blocked, they work on a lower priority tasks while they wait. Sometimes that is a good thing but other times they get off track.

Spending 10 minutes every day resolving the communication and prioritization mismatches early helps deliver software faster.

With just weekly meetings, these issues could go unresolved for days.

[nitely]

This assumes people don't communicate when they get blocked, but wait 24hs to announce it in a meeting.

[ansible]

Yes, exactly. A lot of people don't do a good job communicating this sort of thing. It helps to have someone else ask you what's blocking your progress.

[kelnos]

I mean, c'mon. We're not children. We're professional developers. If anyone I worked with waited even a day to raise a blocker on an urgent task, I'd think much less of their abilities.

[ansible]

I don't disagree.

But sometimes you have to do what you have to do to keep the organization moving forward.

[kelnos]

It's another trade off, though: do you annoy your developers for what I believe is just a slight increase in velocity?

While I do know some developers who like (or at least get enough value from to tolerate) standup, I know many more who find them an annoying waste of time. For teams that do standup first thing in the morning, it even makes them want to go to work less. How's that for starting the day on the wrong foot?

[nitely]

Sure, adding meetings that affect the whole team instead of addressing someone's lack of communication is the way to go.

[em-bee]

that meeting is supposed to only take 5 minutes, and it is only to discover the issue, not to address it. addressing the issue happens after the meeting with only the people who are actually involved.

[nitely]

5 minutes or 5 hours, an interruption is an interruption. My ideal day to be fully productive would've no meetings at all. I don't need each day to be an ideal day, just once a week (or more if at all possible). However, when there is an scheduled interruption each day every day, guess what?

Also, anything that feels like micro-management will be considered micro-management. A daily meeting to give a status report looks a lot like that.

[kelnos]

> Often times when engineers are blocked, they work on a lower priority tasks while they wait. Sometimes that is a good thing but other times they get off track.

Not in my experience. Most developers I work with will raise issues in Slack as they come up. That's part of what being an owner of your tasks is about: communicating issues early and often.

[mobjack]

Senior developers can work like that, but junior engineers need more managing.

[kelnos]

In this case I think it's the opposite: most junior developers I know are much quick (sometimes a little too quick) to ask for help when they're stuck, while a senior developer's ego might get in the way of raising a flag.