
How to Run Great Product Team Meetings - marconey
https://andyjohns.co/why-standups-are-useless-and-how-to-run-great-product-team-meetings/
======
wccrawford
Here's why they aren't "useless":

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.

~~~
richliss
Pretty much every Agile practice is a victim of Semantic Diffusion.

The Daily Stand-up isn't a status update.

It's purpose is to be a micro re-planning session.

The team has a sprint goal agreed by the Product Owner and them at the start
of the sprint and they're supposed to achieve it by the end of the sprint.

The daily stand-up following the 3-question pattern is to validate what they
have done yesterday towards the sprint goal, what they are doing today towards
the sprint goal, any impediments that are impacting them and most importantly
"are we still going to meet the sprint goal?". If the answer to the "are we
still going to meet the sprint goal" is "no" then the team re-plans and may
need to bring in the Product Owner to confirm the Sprint Goal can still be
satisfied with any suggested changes.

If your team's daily stand-up doesn't reflect that then you're not doing a
daily stand-up as it is supposed to be done and of course in that case YMMV.
Yours may even be better or more appropriate for your team but it kind of
ceases to be "the daily stand-up" and comparable to others.

~~~
jkingsbery
Agreed. As the original article said, stand-ups are useful in a run-up to a
release. If you're releasing every week or two, a release should never be far
out.

------
flr03
Oh here is our weekly "stand ups are useless" on the front page of Hacker
News.

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.

------
irjustin
I would argue what the author is commenting on is a problem of poor
implementation. The author admits people describing what the person did over
the weekend.

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.

------
brazzy
Clickbait article that make a huge load of completely unfounded, sweeping
assertions.

"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.

------
petjuh
I was told a horror story about a dev who was given a project to complete only
to turn out he had done nothing 3 months later. He was too ashamed to ask for
help. They weren't doing standups at that time, or anything Agile.

If nothing else, standups prevent this.

~~~
Phenix88be
You can prevent this by being human and check if everything is good for your
teammate. Let a dev working 3 month without showing you anything is going to
be a disaster.

------
cushychicken
Strong opinions, weak alternatives.

------
TheFuntastic
This starts off as another "let's bash standups" article, but after I read
further down I found myself nodding more and more.

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.

~~~
theshrike79
Standups are where the blockers are surfaced, after the standup the relevant
people can gather around a whiteboard or someone's desk and figure out how to
solve the issue.

The others can get on with their daily tasks.

------
sklivvz1971
The OP probably doesn't understand agile, yet they will tell us their
seemingly quite uninformed opinion based on limited non-agile experience.

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.

------
jkingsbery
I think a more useful article would have mentioned different stand-up anti-
patterns. Here's a short list off the top of my head.

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. :-)

------
mangatmodi
When people write - why X is useless, I have this impulse to not read.
Especially when X is proven to be good. No offence to the content, but the
title is quite clickbaity

------
mangatmodi
The standup criticized in the post is the one prevalent in the scrum
methodology, where everyone focus on what they have done and will be doing.
Standups can be much more different, for e.g. in Kanban standups a team
discusses the progress on each ticket.

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

------
donohoe
This isn’t a how-to, it’s more of a rant against something they personally
dis-like and therefore label ‘useless’ (repeatedly).

------
grewil2
How to Run Greatly from Product Team Meetings

------
funcDropShadow
Well, just another blog extrapolating personal anecdotes to general
statements. There are more than enough posts of that kind on the internet.
What we need are more substantiated claims.

------
jaimex2
tldr for those who know Agile.

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

------
corporateslave5
Why <insert argument against common industry practice> are useless. Decent way
to generate publicity and web clicks

