During this year’s ProductCamp Seattle, I sat in on a great presentation by Dave Manningsmith where he discussed several dysfunctions of the daily standup ceremony (or “ritual” as he referred to it) that so many of us participate in on a daily basis.  And it really made me think a lot about just how badly so many of us actually do in our standups — whether it’s because we’re used to status reporting in authoritarian cultures, because we’re really just teams in name only but still executing as individuals, or (most likely) because the organization has never really taken the time to understand why we do standups, so they don’t even understand that they might be doing them wrong.  Here are some common anti-patterns and resolutions that will help you ensure that you’re at least closer to doing a standup “right” in the future…

When and How Are You Doing Your Standup?

First, I know that I’ve said before that Scrum is just a starting point…but even if it is a starting point, we should start off right.  I’ve seen so many teams decide that their standups should happen in the middle of the day or the end of the day, or that they can just give updates via email, IM, or Slack.  And that’s totally fine, provided that you try to have them at the beginning of the day, live and in person, and in a true “stand-up” fashion.  There are very good reasons why the Standup is supposed to happen at the beginning of the day, in-person, and to be a true “stand-up”:

• The standup should happen at the beginning of the day because it lays out the plan for that day; putting it in the middle of the day loses the immediacy, and putting it at the end of the day makes it a summary, not an opportunity for collaboration.
• The standup should be in-person because over 90% of our communication is found in speaking and tone (even on the phone, you’re missing about 50% of the non-verbal communication cues); when you remove the physical cues of discomfort or happiness, you’re removing distinct opportunities as the scrum master to dig deeper or as a team member to prod for more information.
• The standup should be an actual “stand up” because standing is not something that’s super comfortable to do for long periods of time, thus it’s intended to move the meeting faster and to not allow people to “settle in” physically or mentally for long, deep discussion.

Obviously there are considerations that make one or more of these non-tenable for certain environments, but at the beginning of our Agile journeys, we should always strive to come as close to these fundamentals as we can — and innovate from there.

How Long Does Your Standup Last?

The vast majority of the complaints that I hear from development teams about standups is that they last too long.  And that immediately triggers a suspicion in my mind that they’re simply not doing them right — or that their teams are too big to effectively work in a Scrum-based environment.  A standup should literally last no more than 15 minutes — that’s roughly 2-3 minutes per person on a team of between five and nine people (the recommended min and max for Scrum teams).  Any standup that lasts longer than that isn’t really a standup — it’s a status meeting.  We focus on the three key questions in our standups for a reason — and put any other topics for discussion on a parking lot to deal with after the standup:

• “What did you do yesterday?” is our check to ensure that our scrum board reflects reality, and to open the door for what’s likely to go into code review or need some QA eyes today.
• “What are you doing today?” is our opportunity to let the team know what’s coming up during the day and offer their help or consideration on the work to be done.
• “Do you have any blockers?” is the most important question, as it’s the cue for the Scrum Master to take action and remove blockers, shift the plan, or otherwise manage around the blocking issue.

If you’re talking about anything other than these three questions, it’s no wonder your standup lasts a half hour, and that people are disconnecting ten minutes in.  Take discussions to a “parking lot” and keep only the team members needed to discuss after the standup — let everyone else go.  You’ll be surprised, eventually, that the whole team will stick around and be highly engaged on these topics if you’re doing it right.

Who Are the Team Members Looking At?

One of the key takeaways from Dave’s presentation was that we often focus on the wrong things when we’re assessing how well our standups are performing — we focus on whether we’re answering the three questions, whether we’re going over time, or whether we’re identifying blocking issues before they threaten the sprint commitment.  But Dave posited a far more important measure of whether we’re really having good standups or not — when a team member is giving their update, check to see who they’re looking at.  If the team member is engaging with other members of the team, loooking around and making eye contact with other members who might need information or who could provide assistance, then you’re doing the standup right.  If, however, each team member in turn looks at the scrum master and their notes, and gives a rote recitation of their answers to the “three questions” then there’s a good chance that you’re doing it wrong.  Standups are not about the scrum master collecting updates — that’s a secondary function that naturally falls out from the primary goal.  The primary goal of a standup is that the team members are engaging with each other, creating a supportive and collaborative environment so that they can all meet their team’s sprint commitment.  Scrum teams are not comprised of individuals who all work on their own things and then come together every day for updates — they’re supposed to be collaborative environments where everyone is working together toward the same goal!  If your standup doesn’t represent this view, it’s time to take a second look.

Standups Are an “Invitation to Collaborate!”

All of these points boil down to one simple mantra — standups are not supposed to be rote recitation status reports; we can get those in so many other ways that are far more effective and less intrusive.  Rather, standups should be an “invitation to collaborate” amongst the team members.  If someone is working on a user story that another person knows certain architectural details about, that person should offer to help.  If someone is struggling with a bug that another person thinks is related to work they’ve done before, that person should offer to help.  As a story is nearing completion, QA should offer to sit down with the developer to see if they can proactively find any issues with the code or user behavior.  When we treat standups as just another status update, and solely focus on whether we’re answering the “three questions”, we’re missing the most important component of Scrum as an Agile practice — engagement within the team as they work together to reach their commitment!