How to stop your standups from turning into status updates.
If you’ve been working in a product development team following some version of scrum, you’re probably used to daily standups.
Folks come together, often in the morning, and sequentially share :
What did I do yesterday
What will I do today
Where I’m blocked or need help
But these 15 minute standing meetings, meant to help the team move forward, can turn into long-winding problem discussion, venting sessions, or status updates for product managers. What can you do to ensure standups stay effective?
Get the basics down.
You can’t tackle any of the problems that make standups stink, if you don’t start with a solid foundation, which includes a set of tried and true.
a) Start at a consistent time. Habits take time to build. Pick a consistent time that works for everyone, which means everyone agrees upon it. This doesn’t mean your standup has to be in the morning, as a signal to start work. From my experience, it’s actually better to schedule it at least 15-20 minutes after everyone shows up.
b) Don’t wait for stragglers. Once you’ve agreed upon a time, don’t wait for stragglers or people who are late. Because standard standup is meant to be 15 minutes or less, waiting 5 minutes for one person either extends or cuts into what is already a short meeting. If someone is late for one standup, it isn’t a big deal. If the individual is consistently late, you should re-evaluate your standup starting time or evaluate if this individual is the right individual on your team.
c) Set a time limit, use a timer if you must. Standard guidelines suggest standup is limited to 15 minutes. But I’ve learn, the duration is highly dependent on the size of your standup team. The 15 minutes is great for teams < 8 individuals. Increase to 20 minutes if your team size is between 8 - 12. If you need more than 20 minutes, your team is either > 12, which means you should separate into separate standup teams, or people are going into too much detail problem solving.
d) Focus on what you’re going to do, not on what you did. It’s much easier for someone to try to recall and state, what they did/accomplished yesterday. While that might be helpful information, this can quickly cause standups to turn into a 15 minute status updates. Thus, charge each person to state what they’ll try to do today and if there’s anything blocking them from accomplishing that goal
e) When someone states they are blocked and need help, the person has to request someone by name to help them. Naming someone to help is key to ensuring people take ownership. Otherwise, standups can quickly turn into a meeting “run” by a product manager, delivery manager, or scrum master, who with good intentions, asks all the questions, helps solve each blocker, and shepherds everything along the way. Each person on the team needs to become comfortable asking for help by name. If someone says they aren’t certain who can best help, just ask them to pick someone, even at random.
f) Have a signal for the end. It can often feel awkward, when standup ends. Have the team agree upon a signal. I’ve seen teams all clap or snap together on 3, have a cheer, do a push up, say a phrase. It doesn’t have to be serious, but it ends the meeting on a positive note that isn’t necessarily decided by the de facto leader.
Moving beyond basics
If you already have the foundations, congratulations. Give yourself and everyone on the team, a big cookie. Being able to consistently follow the above, day-in and day-out, is no easy feat. You’re ready to tackle more difficult problems.
a) What if people are remote, not co-located?
COVID-19 has recently forced many co-located teams to work remotely. As a result, the physical aspect of standup, where you literally stand up, is difficult to implement. So, what do you do if your team is remote?
Now, not all remote teams = globally, distributed teams. If your team is remote, but located in the same time zone, everything in the foundation still applies. You’re now using video instead of in-person. You don’t stand, but can show-off your favorite cup as a signal that standup’s ending. So, continue onward.
However, if your team is globally distributed or even distributed between U.S. East Coast and West Coast, you’ll need to re-think your standup format. Examples include:
Break apart teams so individuals that are located in the same or close by time-zone can join a standup together.
If you can’t break down teams further, recognize that your work is asynchronous and schedule shift meetings in addition to standups per team. How does this work?
Group A comprises 3 people working in US, Canada, and Brazil together: 1 product manager, 1 designer, 1 engineer. Group B comprises 7 people working in India, Russian: 1 product marketing, 6 engineers. Group A and B are on different time zones, but work together as one product team. Thus each group holds their one standup that’s best for them. Separately, the two teams hold either video or Google Doc shift change meetings. You can think of this as scrum-of-scrum, where the two teams or representatives of the two teams share information and notes with each other on accomplishments and blockers. These don’t even have to be actual video meetings, but could be agreed upon shift meetings notes that are written by Group A, shared with Group B, and vice versa.
b) Someone specific or people keep going long.
Maybe someone is verbose. Maybe someone goes into problem-solving mode and uses a majority of the time. Maybe some people like to chit-chat. Only one way to solve this problem. Set a timer and allocate the same amount of time per person. Say you have 15 minutes and 8 people? That’s 1.5 minutes/per person max.
Yes, its initially frustrating, especially for the verbose individual. That’s because it’s an adjustment for him or her. But I recommend implementing a set time / person, before trying to mitigate. This is because standup is about the team, not the individual.
However, if you are set on mitigating, one way is to have everyone finish and if there’s any remaining time because some people used less than their allotted time, to allow that person to give time back to the person who didn’t finish.
c) Standups run for the benefit of product manager or product manager has to lead all standups for it to occur
Unfortunately, this is a signal you don’t help have a self-forming team. That’s okay and some possible simple solutions.
First, point out this observation. Just because you noticed it doesn’t mean everyone else does.
Second, rotate who is responsible for starting standup on a weekly basis. This person doesn’t have to do anything more, than be the first person to speak up during standup. It’s a subtle, but simple change in authority, reducing the need for everyone to wait for a “leader” before speaking.
Third, force everyone in standup to talk about what they are going to do, rather than what they’ve accomplished. You can even skip focusing on blockers or what happened, because naturally, people will start talking about blockers if they can’t accomplish what they want to accomplish.
d) Team members aren’t bringing up blockers during standups
Often, the biggest reason I see teams stop bringing up blockers is because the issues are taking too long or can’t be resolved. For example, I’ve had engineers state they are blocked on a piece of work because of another team or lack of approval to proceed. Such blockers can sometimes take days or even weeks to resolve. Over time, the daily standup blockers are issues that the team itself can’t resolve and people stop bringing up issues because they are demoralized. Why keep harping on an issue, with no clear resolution? Smart people don’t do this.
So, ask yourself, are the blockers able to be solved within the team, in a reasonable timeframe? If the answer is no, especially in larger organizations where product teams can’t operate independently, my first suggestion is to see if you can enable your team to operate more independently. Note the key word: more.
How can you do this?
Take action, then ask for forgiveness. Yes, it can be risky, but sometimes it’s necessary.
Bring explicit authority back into the team by talking to managers.
Given people outside your team, that is blocking you, an explicit deadline to solve your problem.
Unfortunately, the push to operate more independently is often not possible. As companies grow sometimes decisions and systems become more centralized to improve efficiency by reducing multiple people solving the same problem or prevent errors by a few individuals from taking down the entire system. In this case, I suggest a controversial idea: reduce your standups to 3x or 2x a week. Yes, this is painful for scrum purists, but working in such large, inter-dependent teams isn’t fast. Scrum and standups are meant to quickly address issues by the end of the day. If you can’t do that, enforcing a daily standup with little change only causes frustration that can’t be solved. This may signal that your team may not work well and need to adjust it’s development cadence.
Sources that helped me:
Effective Daily Stand-ups by George Theka
Scrum Guide by Ken Schwaber and Jeff Sutherland
It's Not Just Standing Up: Patterns for Daily Standup Meetings by Jason Yip
Daily Meetings with Remote Teams (Stand-ups Don’t Work, But Daily Cafes Do) by Jurgen Appelo