How 5 Minutes of Preparation Can Finally Make Standup Meetings Productive

“The daily stand up meeting is not another meeting to waste people’s time. It will replace many other meetings giving a net savings several times its own length” –XP Rules

One of three things happens at every standup:

• Issues are omitted.
• Issues are delayed.
• Issues are glossed over.

It may be because a developer doesn’t want to look bad in front of their peers. Or, perhaps, they’d rather have the satisfaction of working through the challenge on their own. Regardless, all developers are subject to biases that sway their decision on whether and when they share critical problems.

One person in the room, however, is usually too far from the codebase to recognize all the issues that are at risk of derailing the sprint. And that person–whether it’s a manager, a team lead, or a scrum master–is usually the one responsible for making sure the team stays on track.

This creates an undesirable dynamic. Those who are closest to the problems don’t have the time to step back and see the forest for the trees. The manager, who is responsible for keeping the sprint on track, doesn’t have the visibility to uncover roadblocks and bottlenecks.

Developers end up inadvertently serving as gatekeepers to critical issues.

To change this dynamic, the manager needs to do a bit of research. Before stepping foot into stand-up, they need to understand early warning signs of risks to the sprint.

Identify the signals through the noise

The first thing the manager should look at is: how fast is the team moving? Is this pace faster or slower than normal?

Currently, most managers track some version of Planned vs. Completed work. They might look at story points or tickets closed. While these are useful for assessing planning effectiveness, they’re not diagnostic. You can’t tell whether the issue is with capacity or efficiency.

A more accurate reflection of pace is an activity metric, such as a Pushes or Commit Count. When activity is lower than normal, the manager knows that there are obstacles holding back the engineers from coding.

Code Climate’s Velocity shows a burn-up each sprint based on push volume.

If this activity count is low, the manager will want to further investigate where developers might be stuck. They should look out for three red flags:

• Long-running pull requests: Are there pull requests that have been open for more than three business days? If so, who can help get it out the door, or break it up into smaller chunks?
• High review cycles: Is there a pull request that has been passed back and forth between the reviewer and the author several times?
• Large pull requests: Are contributors opening pull requests in small, easy-to-review units? If not, those pull requests are harder to review and at greater risk of causing an issue when they are merged.

Velocity shows work in progress with activity level, age, and health. See at-a-glance the pull requests that are most likely to impede your team.

If pace is slow, yet no pull request is growing unwieldy, you’ll want to pull a list of engineering activities. Check tickets, commits, merges, and reviews to ensure that the team’s work aligns with what was planned and expected.

Velocity’s Activity Log represent every engineering activity with a shape. Hover over to get context on what a team member is working on.

You can surface this information by setting up a Git history statistics tool, like GitStats, and then pull the data before each standup. Or, you can use an Engineering Intelligence platform like Velocity to see all of these risks in one place.

Regardless of how you pull the data, spending fifteen minutes to catch up on all the important work in progress ensures that no time is wasted catching up during actual standup.

Shift the conversation toward action

With more shared context, the conversation shifts from talking about problems to talking about solutions. Here are two scenarios played out side by side:

The opportunity to offer support is much greater when you start the conversation with actual data. It takes the onus off of each developer to ask for help and transforms the meeting into a constructive way to keep the team on pace.

Standup is not roll-call

The value in disrupting developers for face-time is to identify and plan for addressing bottlenecks– not for proving that they’re working.

Once time is re-allocated toward identifying risks and ensuring the team is on track to hit this sprint’s goals, you’ll find that finally, the stand-up is providing more value than a meeting that is several times its length.

All that’s required is a bit of preparation.