How to run the perfect standup
By eleith
Five years ago, faced with a new role (team lead) on a new team (team pineapple), I decided to run the perfect stand up. The task felt daunting and I did what all engineers do when faced with a challenge:
I used google (hoping to find an answer on stackoverflow or wikipedia).
Resisting the temptation on google’s autocomplete suggestion to learn how to run a “perfect lemonade stand” or “a perfect stand up comedy”, I did eventually find a few suggestions on a set of questions to guide the stand up:
- what did you do yesterday
- what are you doing today
- any blockers?
These first few stand ups came and went. I’m pretty sure they weren’t perfect. I didn’t even know what perfect meant in this context. Five years later, I am confident I have yet to run a perfect stand up.
Recently, I decided to revisit the question. Around me at Coursera, there are many teams running stand ups everyday that I could learn from.
I interviewed a number of team leads about their stand ups and I came to a few conclusions:
- Each team runs their own variation of a stand up
- We’ve got pretty solid teams, knocking out great work each quarter
- There is no such thing as a perfect stand up
As you might have guessed from my last blog post, I think it’s worth asking a different question if you really want to improve your stand up:
What should I optimize for when running a stand up?
At Coursera, while there may not be a perfect stand up, there are a few key insights worth learning from.
When running a stand up, your first decision requires deciding what method you will employ. Below are a few examples from my survey at Coursera. While not an exhaustive list, the examples can help you understand how the method of your stand up intimately defines what your team is optimizing for.
The async stand up
A few teams at Coursera (for example, the platform team led by Nick Dellamaggiore) run through the basic questions all in Slack. Other teams, take it a step farther and automate the process using a one of many available slack bots.
While this method sacrifices daily face to face time, it is also honest in what it is optimizing for; a lightweight and transparent way to keep the team lead informed on the overall team progress.
The engineers on these teams tend to work on mostly independent projects. These engineers don’t need to interact with designers, PMs or cross functional team members on a daily basis. They are able to plan and map out their work for long chunks of time, they tend to work in small and independent groups of 2–3 people, and their work is mostly defined by their execution and clean code.
However, you do lose daily face time and empathy building for your other team members. Not surprisingly, these teams tend to make up for what their stand up doesn’t provide: they have regular lunches or offsites to give them space to increase team morale and empathy.
I find the team lunches on the platform team super fascinating. After one lunch, I found myself thinking too deeply about space elevators and spending too much time reading a comic strip about a bus stop.
In the end, your stand up method of choice not only defines what you are optimizing for, but also what you will need to make up for elsewhere. A great stand up does not make a great team, but it can serve as an important ingredient to one.
The high energy standup
A couple of product teams at Coursera employ what I can only think to call the “high energy stand up”.
These stand ups give way to laughter, booing, cheering or clapping. (Yes, clapping. Lately, at Coursera around 10:30am, you’ll hear one big thunder clap signifying the end to one team’s version of a high energy stand up.)
These teams tend to work closely with a designer (or two!), a product manager and a handful of engineers. They have multiple projects going on at any one time with a lot of cross dependencies.
This method asks the same questions as the async method along with a visual tracking element. These visuals end up on a wall or whiteboard that represents individuals on a team and their previous and current answers to the stand up questions.
When these standups started at Coursera, the tracking started out with simple tally marks. Today, they have evolved to reflect some team appropriate theme. A team of many gamers tracked their tally marks as pellets, ghosts and pacmans. During the pokemon go craze, our mobile learner experience team, led by Mustafa Furniturewala, used pokeballs and pikachus as their tallies. Our assessment team, led by Priyank Chodesetti used to track their tallies as autobot pieces that would somehow transform into the full team logo. I’ve seen many other themes throughout the years including baked goods, solar systems, fruits, hearts and emojis.
The Partnership Experience team, led by Colleen Lee, plays stand up poker for their version of a high energy stand up. Each sprint starts a new game and completed tasks get rewarded with a card pulled from the deck. Once you hit five cards, you can replace a card. The best hand at the end of the sprint wins a medal to display on your desk to the ire of your teammates. Be warned though, last quarter an intern on the team swept all the poker hands, leaving the full timers in awe and without a medal to show for their hard work.
In the end, these standups optimize for creating space each day where a team has face-to-face interaction. These social gatherings get the team on track as a singular entity, easing the way for coordination and team empathy.
However, this method lacks building a deep understanding of team velocity and team purpose. Thus, these teams need to address this through detailed sprint meetings, project kickoffs and more. A few teams take this a step farther and write out their team’s goals each sprint next to their stand up tallies.
The battle plan standup
A third stand up method at Coursera stands out from the rest. These standups are organized, efficient and involve low level tracking using post it notes, agile boards or kanbans.
The teams that employ this approach work on one big project that have looming deadline without a lot of wiggle room. The team’s success depends on unearthing blockers and maintaining a healthy velocity.
Again, all stand up methods use a similar base of short questions. However, the answers end up moving tasks along the board in a way that helps visualize the current state of the entire project. Our enterprise team, lead by Roshan Sumbaly, employs a method like this.
Just as with the async method, social interactions and team bonding must be explored and strengthened in other avenues. With the enterprise team, I occasionally catch them playing an unforgiving game of Blokus during our weekly happy hour.
Once you start honing in on what you want to optimize for, you’ll open up other interesting questions to define how you run your stand up.
Questions to ask
At Coursera we’ve taken our small set of questions and apply it to many different stand up methods. However, they also tend to be general and thus they apply broadly to any team wanting to run a stand up. If you were optimizing for sales calls or writing unit tests, you may want a more specific set of questions.
I would advise you to keep the question and answer period short. If it takes more than 60+ seconds to answer the questions, you are moving away from stand up territory and into meeting territory. This is worth avoiding at all costs.
Our mobile team uses a light ball that darkens after 30 seconds to keep everyone on schedule. No one wants to be the teammate holding the dark ball.
Staying flexible
Your team consists of individuals with their own preferences and needs. By customizing the stand up to your team, you’ll see positive returns in levels of engagement.
Some teams at Coursera live in SF and choose to work from home on wednesdays (our officially sanctioned “no meeting” day!). These teams show flexibility by switching their stand up method to the async method or cancelling the stand up on Wednesday.
Two years ago, I had a team that preferred to work uninterrupted in the morning and we decided to move our stand up from 10:30am to 11:45am to acknowledge the value of avoiding disruption (and being first in line to lunch!).
Iteration
Lastly, as your team changes or evolves over time, spend time considering how to iterate on team practices. What works one quarter may not work the next quarter.
Priya Gupta polls her team each quarter about what they like about their stand up and what they would like to see improved. These results push her to drive changes in step as the team evolves.
At Coursera, we run a lot of stand ups. None of them are perfect, but the intention and the small time investment (less than 15 minutes!) keep us aligned, motivated and pushing each other to be better each day. We are always looking for great engineers, so if you have stand up ideas of your own or just want to join one of ours, apply today!
Originally published at building.coursera.org on February 21, 2017.
