Many people have written about daily standups*, and many people have written about the benefits of short meetings**.

I want to talk today about the idea of the 5-minute standup. This is an evolution of the daily standup that is part of the Scrum*** Agile methodology. I’m writing this from a Development perspective, but this could just as easily be applied to many other types of organizations.

The purpose of the daily standup as I see it is twofold:
1) Let everyone know what everyone else is working on
2) Let everyone know when someone is in trouble/blocked, so they can help

Classically, the daily Scrum standup has three questions:
A) What did you do yesterday?
B) What are you planning to do today?
C) What is blocking you right now****?

In my (limited) experience, people are pretty good about the status update part of things (what did you do yesterday?), and the forecasting part (what are you planning to do next?). You may need to explicitly ask the blocking question for a while until your team fully trusts you and the rest of the team to listen to their (often embarrassing) blockers and actually help them.

For me, I’m very much a proponent of short meetings. I love being as concise as possible (Think Ulath*****). I have an acute sensitivity for people who are uncomfortable with a situation or have checked out, and I try to do everything I can to fix that. (This makes me a good host, but it can be very tiring.) If I’m running a meeting, it will have a defined purpose, and it will be only as long as it needs to be.

I’ve found that developers especially will check out of a standup within minutes. Having a meeting of 5 minutes or less was the only way I could find to keep people engaged in a status meeting.

The way we’ve found best to run these meetings is to have the current set of tickets up on the screen, and we go through them in order. People are generally only working on one or two at a time, so it’s effectively the same as going around the circle, but with the added benefit of the visual aid. You can also do all of your ticket status changing at this time, along with asking for code reviews. Anyone who was missed then gives their update, then you break out to whatever after-meeting conversations were deemed necessary during the meeting. This way, only the people who need to be in those conversations are, and everyone else can get back to whatever else they were doing.

Some tips:
– If you find your standups routinely taking longer than 5 minutes (or 1 minute per person, max 10 people in a standup******!), try giving the most ‘detail-oriented’/rules-based person on your team the timer, and telling them to give each person no more than 1 minute to talk. It worked wonders for us. (I often do this myself, by being the most impatient one in the meeting.)
– Announcements should happen very quickly (max 30s), or over email. Discussions can happen after the standup is over.

To Recap:

Pros of the 5-minute daily standup:
– Less time
– No time spent on details, just high level, in depth discussions pushed to smaller groups
– Devs are much less likely to check out
– Not dreaded like interminable meetings
– A good outlet for the detail-oriented member of your team who cares about process, and wants to time things

Cons of the 5-minute daily standup:
– Still takes devs out of the flow, distracting them for much time before and after
– You still have to have all the one-on-one meetings to resolve things afterwards…
– It can make you think you’re having full communication when you’re not

*Interestingly, this is a very old tradition, as the UK privy council only has meetings where all members stand https://en.wikipedia.org/wiki/Privy_Council_of_the_United_Kingdom#Meetings

**Randy Pausch gave an excellent lecture on Time Management https://www.youtube.com/watch?v=oTugjssqOT0 and the benefits of making meetings as short as your scheduling software will allow.

***https://en.wikipedia.org/wiki/Scrum_%28software_development%29

****Many people would say “Is anything blocking you right now? I mostly avoid yes or no questions, as they’re too easy to dodge with a one word answer, and a lot of having effective meetings is getting people to be present and trust you and not dodge.

*****http://davideddings.wikia.com/wiki/Ulath

******If you have more than 10 people on your team, your team is too big. Note that more than 10 people can be listening or watching, if they also want an update, but there should be no more than 10 people talking, at 1 minute each.