How to Run Great Product Team Meetings

They force people to think about what they're doing, talk about any problems they're having (so the group can help), and keep everyone apprised of what else is going on.

It's literally what the 3 questions are for, and it does it admirably. In a previous company, we followed the "Agile" rules for "standups" very strictly, and it worked for us.

And here's why a truly "agile" (not "Agile") version of standups is great: Our company uses it to socialize as well. We get the business part of the "standup" (we don't stand) out of the way and then spend some time socializing for a while.

We were already doing this for a couple years, but now that one of our team is 100% remote from across the country, it's our best chance to socialize with them and keep the team close-knit.

And it's working.

Every team has to figure this out. I understand that people don't like them, I'm sure they have valid points. In my team this works great.

There is this trend of thinking "it gets in the way of people actually doing something productive" [sic]. I find it very reductive. How do you define productivity first of all ? Is work only about producing value ? How do you evaluate it ? Especially, as a reminder, in a field where estimating the complexity of a task is extremely difficult.

Work is sometimes a bit more than being in the zone from 9 to 8.

There is no place for that or discussion in Standup. Each person should take no more than 30 seconds except on the rare blockers. Ideally for a team of 6-8 we're speaking 3-4 minutes.

Yesterday? Today? Blocking?

We require every member to have their item list pulled up already and ready to talk without hemming or hawing.

I could easily agree that Yesterday/Today could be removed. As a team lead, it's a very nice way of getting a daily rundown in a structured, fast way. Also, if something shows up too often, it's a sign it's time to dive in, but, again, if there's too much resistance, it goes.

Blockers are a must. What's blocking you? X. Once you've said X, many times it's immediately known who can help. If the PM cannot immediately prescribe helpers, the standup slows to hear what the gist of the problem is and volunteers/leads are asked for to step up to carve out time at 2... 3... after lunch, whenever - the key is an agreed upon time to tackle the issue.

In the end, I think I'm saying the same thing as the author, but I don't think it's necessary to speak so poorly about Standup.

Unblocking is everything.

"The practical reality is that you only care about what another team member worked on yesterday if it enables you to do your job (i.e. it unblocks you). Anything shared that does not explicitly unblock you is meaningless noise."

Except when it helps you avoid merge conflicts when the other team member announces they're going to refactor a component that you've just started implementing a new feature in. Or when it gives you a cue to add an important insight into their task.

The truth is, Standup meetings are very often badly run, people go into way too much detail about their tasks and start in-depth discussions that should be done one-on-one, and neglect the "what's blocking me" part, which is far more important than the "status update" parts.

Standups need someone to act as moderator who prevents them from running off course, or they can become terribly unproductive - exactly the same as any other kind of meeting.

If nothing else, standups prevent this.

It put into words something I've seen first hand - how blockers are actually unmade decisions. And then gives useful guidance on how facilitate this from a project management point of view.

I've often seen how three people around a white board can make more progress than months of discussion and decision paralysis. Also the article states how standups can be useful towards the end of a product lifecycle when most decisions have already been taken. This was a new way to think about for it me, but I have to agree.

There seems to be lots of pragmatic real world earned wisdom in the article, unfortunately it's hidden behind a clickbait opening.

Standups are incredibly useful if one wants to have a team self organize to deliver something. If they have a bunch of singleton actors working in silos, and they are OK with this, then they don't need standups. Standups degenerate into status reports and are useless, which is likely what the OP thinks they are meant to be. They are also evidently not doing agile.

On the other hand, my teams do agile, I need to break silos to let teams self-organize, and standups are necessary to let teammates know how and when to help each other, especially in remote teams.

1. Team members sharing about things that aren't sprint goals.

2. Team members getting into more detail than is needed

3. Team members checking their phone

4. Stand-ups scheduled in the middle of a chunk of time (Scheduling at the beginning of the day or before/after everyone goes to lunch anyway means the lost productivity is minimal).

5. Team members each have isolated, individual projects, and don't reprioritize what to work on based on what the team is trying to achieve.

6. Stories aren't sufficiently broken down, so that each day the "update" from someone on the team is "Yesterday I was working on X, today I'm going to keep working on X."

7. The amount of work remaining never gets re-estimated (e.g., it's a good thing if you say "We thought in sprint planning that this was going to take 3 days, but then I discovered this new task, so even after spending 1 day on it, it will take 5 more days").

8. Trying to solve everything in stand-up. It's better to treat stand-up as a sort of "triage" session for the team's daily issues, and then let people have conversations after to actually talk through solutions.

9. The Stand-up Is For the Manager. When the stand-up is just for the manager, it tends to feel update-y. When I've been on teams where the stand-up is for the team, team members use it as a way to ensure their own accountability with their peers, understand at a high level what their peers are doing and if they're struggling (in a broadcast manner, so every team member doesn't have to meet with every team member 1-1), and the team still finds it valuable to do even with the manager is on vacation or has a conflict.

10. The Stand-up doesn't address progress toward sprint goals, what things are at risk of not happening by sprints end, etc., because it is entirely focused on what tasks people are doing.

If your standup is doing things, then (1) I understand why you think they're a waste of time, and (2) stop doing these things. :-)

The proposed method doesn't seem to replace any of them though. It is something which every engineering team should already be doing.

More groom sessions less standups (skip days) early on. Daily stand ups when getting closer to launch.