How to Run Great Product Team Meetings(andyjohns.co)
andyjohns.co
How to Run Great Product Team Meetings
https://andyjohns.co/why-standups-are-useless-and-how-to-run-great-product-team-meetings/
27 comments
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.
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.
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.
I wanted to point out the same thing around socializing. We set aside 15 minutes for standup. The business part of standup takes 5 minutes and folks get to hear what their colleagues have been up to at work or outside. Its critical for a remote organization in my eyes.
The way the author talked about standup made me think they are a developer/designer/maker. The 15 mins of standup cost way more than 15 mins if its at an inopportune time. This can be where async standups help out. Get the information out without disrupting someones day.
The way the author talked about standup made me think they are a developer/designer/maker. The 15 mins of standup cost way more than 15 mins if its at an inopportune time. This can be where async standups help out. Get the information out without disrupting someones day.
He actually doesn't mean to remove it from the process but suggests a way to adjust to late stages of the sprint. I think main issue roots to need of an extra effort to represent your work all the time (e.g. cold phase of the project) while PMs could do it for you.
I’m a proponent of team socialization, but it generally works out a lot better to do team lunches and the like—a quality hour or so to socialize over food on a Friday perhaps—rather than jamming in 10 minutes of chitchat during the morning or whatever.
In our case, it's not just 10 minutes. It's however long we want. In practice, it's about 30-45 minutes on Mondays, and about 15-20 minutes on other weekdays. We talk until nobody has anything to say, and then break up and go about our day.
Lunches never worked for us because we each prefer a different lunchtime. I was always about 2-3 hours earlier than the latest people.
Oh, did I mention that we set our own schedule? I'm the earliest. And now with someone remote, the latest is 4 hours later.
But I'll freely admit that Friday lunches might work better for many teams.
This company has monthly events that has the whole company close the doors and do something, and also monthly birthday/cupcake events where we just announce any news, birthdays, anniversaries, and eat cupcakes. I think that basically takes the place of the Friday lunch thing that you'd have.
Lunches never worked for us because we each prefer a different lunchtime. I was always about 2-3 hours earlier than the latest people.
Oh, did I mention that we set our own schedule? I'm the earliest. And now with someone remote, the latest is 4 hours later.
But I'll freely admit that Friday lunches might work better for many teams.
This company has monthly events that has the whole company close the doors and do something, and also monthly birthday/cupcake events where we just announce any news, birthdays, anniversaries, and eat cupcakes. I think that basically takes the place of the Friday lunch thing that you'd have.
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.
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.
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.
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.
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.
"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.
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.
If nothing else, standups prevent this.
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.
[deleted]
Standups don't prevent that. You can have people saying things and still not revealing they need help. A weekly meeting could still caught the lack of progress in span of three months.
Plus, if he really "had done nothing 3 months later" then it is not about being ashamed to ask for help. Being ashamed to ask for help would explain unfinished things or technical problems here and there.
Being ashamed is likely an excuse there.
Plus, if he really "had done nothing 3 months later" then it is not about being ashamed to ask for help. Being ashamed to ask for help would explain unfinished things or technical problems here and there.
Being ashamed is likely an excuse there.
This is just a failing of their manager, were they not checking in at all in 3 whole months?
Strong opinions, weak alternatives.
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.
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 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.
The others can get on with their daily tasks.
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.
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.
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. :-)
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. :-)
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
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.
The proposed method doesn't seem to replace any of them though. It is something which every engineering team should already be doing.
This isn’t a how-to, it’s more of a rant against something they personally dis-like and therefore label ‘useless’ (repeatedly).
How to Run Greatly from Product Team Meetings
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.
tldr for those who know Agile.
More groom sessions less standups (skip days) early on. Daily stand ups when getting closer to launch.
More groom sessions less standups (skip days) early on. Daily stand ups when getting closer to launch.
Why <insert argument against common industry practice> are useless. Decent way to generate publicity and web clicks
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.