I have run more standups than I can count. For a long time, I ran them pretty poorly. Think eyes glazed over, people listing out tasks with no response, constantly re-asking questions because people weren’t paying attention, no one wanted to be there, just an overall tough hang.
I firmly believe that when used correctly, standups help projects stay on track and help identify issues long before they escalate. I’ve spent a long time trying to figure out with others how to make standups valuable and purposeful. I believe the current formula I use works pretty well, so I want to share it with you.
This article covers what I believe is the foundation of a productive standup.
The key to a great standup is touchpoint-spotting.
Standups should focus on one thing and one thing only: Identify any necessary touchpoints in the workflow to drive higher release quality.
By focusing on identifying anything that needs to be discussed to improve the likelihood of a successful release (whether that discussion happens during a standup, in a separate meeting, or asynchronously after a review), the standup becomes a routine checkpoint that enables high-leverage conversations to happen.
What are those touchpoints? Here’s a list of frequent touchpoints I’ve identified during my standups:
Identifying blockers,
Requesting feedback,
Asking others to review progress,
Demo stuff,
Identify the need for and schedule pairing,
Build alignment on something,
Requesting context on something,
Align on a deployment/release approach,
Align on a testing approach,
Align on priorities,
Talk over a timeline and the likelihood of meeting it/the need to adjust it,
Go over testing results.
Asking for help,
Anything else where contact helps improve the likelihood of a successful release.
As you can tell from the above Standups are NOT recitations of what you did. if we don’t have any of the above touchpoints to talk through, then the standup ends then and there. Standups are about necessary touchpoints and necessary touchpoints only, if there’s no necessary touchpoint then there’s no need for the standup.
Standup Mechanics:
Now, there are a lot of touchpoints listed above, but the reality is that covering those touchpoints in standup is pretty simple. I follow a straightforward model built on a loop between touchpoint-spotting and next-step identification.
Touchpoint-spotting mechanics:
I’ll start standup by asking the team if anyone has anything they want to connect on; if they do, we start there (unless I have something I believe is critical). If there’s nothing, I’ll start.
When I start, I’ll often pull up our work board so that everyone can focus on a shared visual document of our current work. I’ll work backward from the work that’s closest to releasing to the work that’s furthest from releasing.
I’ve found this ordering significantly improves a team's release rate. It creates urgency around getting stuff out and establishes an implicit mental priority for work (first what’s close, then what’s next).
Again, if there’s something critical, however, I’ll prioritize that first, or if there’s a meaningful discussion to be had, I'll prioritize that, too.
As I cover the board, others and I call out any work items about which we have questions, concerns, or information that needs sharing with others. Most of the time, this leads to deeper conversations.
We don’t go over everything we’re working on, instead, we deliberately focus on the things that people actually feel the need to talk about. This makes the standup efficient and valuable. Again, if there’s nothing that qualifies then we end the standup early.
Next step identification mechanics:
Often, as we identify these touchpoints, long discussions ensue. The key to a time-effective standup is identifying the things that should discussed fully during the standup from the things that need additional time outside of it.
When starting these discussions, it’s okay to let things breathe a bit if people are making progress and the progress is valuable and relevant to everyone. Also, letting topics breathe gives you the ability to identify whether we should fully discuss something or if it’s something to be covered later. This decision is mostly subjective, and it’s your job to figure out consistently what should be closed during that time slot and what should be moved.
If you realize you’re running out of time or if there’s no clear end in sight, politely let people know that this item might just need a follow-up as we’re running out of time to cover everything.
Note: Keep your average to 15 minutes:
You can sometimes run over, but you don’t want standups to become planning meetings, as people will start losing their appetite and endurance for them. You want them to primarily serve as ways to identify touchpoints, resolve the ones that can be quickly addressed in the standup, and schedule and align on any touchpoints that need their own space.
Standups should take an average of 15 minutes. If they’re consistently under or over 15 minutes, the team either isn’t surfacing enough items, or you’re not effectively identifying and scheduling follow-ups to items that surfaced and are instead just handling them within the meeting. Some days will be light, and some days will be heavy, but in the aggregate, your team should be spending about 15 minutes a day on touchpoint identification and assessment.
Closing Notes:
Everyone hates meetings, and rightly so; meetings can often devolve into a weird kind of theatre where everyone pretends that what’s being talked about matters while everyone knows it doesn’t.
Standups are not performative, they are not an exercise in bureaucracy, and they are not needed if they’re not needed. If there is nothing to talk about, then at best, standups are just a way to see everyone each morning. If there’s a reason a touchpoint can help make things flow smoothly then it’s a place where you can have that conversation.
Standups, like other process tools, can be effective when used correctly and detrimental when not. To make a standup valuable, focus on creating a meeting built around identifying needed touchpoints. By doing this, you may find that the standup can aid flow, create a forum for team members where they can be vocal about projects, and, most importantly, have a tool that can be used to identify if projects are starting to get off track.