7 Rules for Holding Highly Effective Standups

If you’re running ineffective daily standups, it can lead to discouraged developers, wasted payroll, and inefficient sprints. But the daily scrum meeting doesn’t have to be a waste of time (as we’ve written about extensively). When done right, standups are a quick and efficient way to make sure everyone is on the same page and blockers are out of the way.

But how do you run effective standup meetings that don’t feel like a waste of everyone’s time? In this post, we’ll answer that and share 7 ways to improve your standup meeting format.

7 Ways to Improve Your Standup Meeting Format

1. Find a Time That Works for Everyone
2. Don’t Solve Problems During the Standup
3. Keep Them Short
4. Keep the Conversation Focused on Blockers
5. Don’t Invite Unnecessary Participants
6. Document What Is Discussed
7. Make Your Standup Remote-Worker Friendly

Note: Sign up for a free 30 day trial of Geekbot to run asynchronous, in-Slack standups that are quicker and less disruptive.

1. Find a Time That Works for Everyone

One of the first challenges of holding an effective standup is scheduling it. Normally, you’d poll your whole team and find the best time for everyone.

But this is a short-term solution that doesn’t fit all teams.

First, distributed teams are going to have a harder time juggling different time zones and work schedules. On remote teams, a developer often needs to accommodate the rest of the team by jumping on the standup call very early or late in their day.

But even with allocated teams, complications arise. Sometimes availability changes. Let’s say you’re about to start your daily standup and then a last-minute problem occurs that needs your attention ASAP. You have to choose between missing the standup completely or attending with a distracted mind.

These are just some of the challenges of running effective standups that led us to switch to asynchronous standups, and we use Geekbot — our asynchronous standup tool that integrates with Slack — to help solve the scheduling problem.

First, you schedule in Geekbot when you want your participants to get a notification that it’s time to fill out the daily standup questions.

Then, standup participants get a ping within Slack when it’s time to answer their questions. From there, they have two choices.

#1: They can answer the questions right away. Once they do this, their answers are sent to a public Slack channel for the entire agile team to see.

#2: Or they can hit snooze on their notification. If a participant is pinged at an inconvenient time (say they just received an important call) they can snooze the standup and Geekbot will remind them to complete their standup answers at a later time via a Slack notification.

2. Don’t Solve Problems During the Standup

While solving problems immediately during a standup may seem productive, it could have the opposite effect, and make your standup ineffective.

This is because solving problems during the standup ruins the format. Suddenly, there’s cross-chatter as developers try to think of the best way to solve a blocker. The entire standup meeting agenda is going off the rails and the Scrum Master has to reign it back in.

Make it a rule that blockers shouldn’t be solved during the standup, and instead team members can say to one another, “I have a solution for you, let’s meet up in 15 minutes and discuss it.”

Also, some agile teams will use a task board to help “bench” future conversations instead of addressing them in the course of a standup. Your Scrum Master can make notes of who is experiencing a roadblock and who will meet up with them post standup to solve the issue.

When we built Geekbot, we directed our attention to this issue of problem-solving mid standup. In the standup update below, Kate mentions she’s experiencing a blocker and needs some information from Brandon about the new landing pages:

Geekbot notifications work like normal Slack notifications. After Brandon gets pinged that Kate tagged him in an update, he can respond via a thread after the standup is complete, and without interrupting everyone else about an issue that only involves the two of them:

3. Keep Them Short

A standup should take fifteen minutes (at the longest). But standups often last too long because…

• Developers engage in side-conversations.
• Developers over-share.
• Developers problem solve during the standup.
• Meetings turn into status updates that are more for impressing upper management rather than for developers.
• And the list goes on…

We noticed lengthy standup meetings became an issue of the past when we switched to asynchronous standups, as we’ve written about in-depth here, and as you can read about in the case studies below:

• Zapier – Why We Replaced Our Standups with a Robot
• Why & How GitHub’s Services Programs Team Runs Asynchronous Standups in Slack

4. Keep the Conversation Focused on Surfacing Blockers

Sometimes standups are too focused on what happened yesterday. Developers can spend the vast majority of their time relaying the issues they had the previous day and how they solved them in unnecessary detail (in order to impress their manager).

But the goal of a standup is to look forward towards what’s going to be done today and what may be in the way (a blocker) instead of spending an overly large amount of time on what’s already happened.  

If you’re running synchronous standups that rely on face-to-face communication, then it’s the Scrum Master’s responsibility to keep their developers on track. This means re-focusing standup participants who are giving more information than needed on the previous day’s task(s).

If you’re running text-based asynchronous standups, this problem is solved for you because folks naturally tend to answer questions more succinctly via text. They have more time to think through things when they’re writing rather than speaking, and don’t provide as much superfluous information.

5. Determine Who Should Actively Participate and Who Should Spectate

 Some agile teams may think, the more people at the standup, the greater the transparency, and the less likely we’ll need meetings throughout the week. And while that’s true, it’s important to make the distinction between who should be spectating and who should be actively participating in the standup.

For example, while each team’s situation is different, one common thing we hear is, “the manager speaks for the majority of the standup”, which leaves less time for developers to participate.

6. Document What Is Discussed

While a standup is a check-in to help keep the coming day on track, the information shared in a standup will be valuable in the future.

For example, you may want to review standup updates when performing your retrospective.

Or, let’s say you’re reviewing today’s daily standup update. You notice one of your developers is struggling with a login screen line of code. This problem reminds of a blocker another developer faced recently. If you have a written document of past standup answers, you can reference them and direct that developer towards whoever may be able to help them solve the problem.

With Geekbot, because standups are posted in Slack, it’s easy to search your standup archives. In addition, you can filter answers by date via our web dashboard, where you can also find unique insights about standup participation percentage, report streaks, and more:  

7. Make Your Standup Remote-Worker Friendly

Running standups with distributed teams is a unique challenge. Mainly, as we talked about above in the section on scheduling standups, there’s the issue of accommodating different time zones and schedules. Plus, many of the issues that come up during in-person standups (i.e. problem solving, oversharing, etc.) are still present.

We used to run standups via video call, and we saw the immediate benefit of switching from synchronous standups to asynchronous standups. Our standups are now a lot faster and less disruptive, among other benefits which we discuss in depth here:

Video Call Downsides & How to Run Better Remote Standups in Slack