"Ugh, can we move this along already..."
- Sincerely, everyone in the standup
It has been my experience that many software standup meetings are broken. They go on too long, the attendees are zoned out, and it creates a productivity dead zone before and after. Broken processes are motivation killers, they should be weeded out with a sense of enthusiasm and urgency.
While at Convictional, we landed on a really good thing here. Our standups usually interrupted less than 10 minutes of my day. They ranged from boring to highly engaging, but the less engaged I was, the less interruption I also experienced. This gave our standups a feeling of effectiveness.
The recipe
Do not do standup meetings in person.
Do not do a video call.
Instead, do the meeting in a shared Google Doc. Add a new section to the doc each day, and let each person have a dedicated area to write.
The effect you will see is the whole team writing their updates simultaneously, and they will be able to engage with each other through typing without holding up anyone else. Everyone can leave as soon as they want, or stick around as long as they want.
This is the secret to effective standups, you've got it now. Give it a try 😁! Here's an example of what this doc looks like after one day:
Daily Standup
The purpose of this doc is to share blockers, questions, reminders, and project updates with the team.
July 26 2023
Alice A:
- Adding some custom JSON marshalling for nil maps, found this great article on reflection that helped me get the lay of the land.
- BB: oh cool, thanks for sharing! Btw what's the issue with nil maps?
- AA: Check out this issue, a lot of people have complaints about how it works. Basically doing a workaround for our API clients.
Brian B:
- Continuing work designing the new Address API. I did some research into address validation rules, its more complex than I thought. Any suggestions on 3rd party API for this?
- AA: I've used EasyPost (scroll down to the example) for a side project and worked well, but pricing isn't upfront :S
Template (Copy and replace with date)
Alice A:
- Your update here
Brian B:
- Your update here
My personal observations
What about face time?
My guess is that teams hold on to the face-to-face standup because they want to give the team frequent face time. If so, I think this is well-intentioned but misguided.
True, we want the people on our teams to develop familiarity and trust with each other, i.e. we want them to develop personal connections. But personal connection is not built by listening to your teammates try to summarize tasks you don't care about while trying to prepare your own summary in your head which they probably won't care about. And that's regardless of how closely you stand to each other.
Surprisingly, when using a Google Doc standup I did build personal connections as we typed out our one-on-one side conversations, as we picked shiny emojis to react to each other's wins with, and as we shared more thoughtful updates by taking the time to write without all eyes waiting on us.
Not to mention, face time does still happen if we realize our side conversation is too arduous to type and the two of us will hop into a Google Meet link to continue (hmm, sounds a lot like those post-standup breakout conversations that never seem to happen...).
In general though, my preferred way to increase that personal connection on the team is to go at it intentionally by having a combination of regular one-on-ones, and running weekly book clubs with small groups. In both cases, the point is to engage with each other, not to give a status update 😝!
Neurotypical, anyone?
In the software industry we celebrate our neurodiversity, and my guess is that it's one of the most accessible high-paying careers out there, especially for those with attention-related and sensory-related neurodivergence.
In my junior years I didn't question why after walking out of a 20 minute daily standup I had difficulty recalling a single detail of what was said. I assumed the information must not have been that important and went on with my day.
Moving to the Google Doc standup clued me in that there was an abundance of learning opportunities passing me by every day, simply because my brain struggles to process rapid-fire lists—which is essentially what the entire standup meeting is.
When ideas are written down instead, my visual processing can kick in and suddenly I'm at an advantage. You shared an article? I'm reading it. You noticed a bug? I'm sharing the issue I wrote for it. The team is a fully connected neural network for that brief moment each day.
Of course, we can assume everyone has different strengths in these areas. But I don't think we should be too surprised if having information written down, preserved, and—best of all—hyperlinked turns out to be vastly more helpful to most of us than our "oral traditions of the past" 😉.
"I don't know how to get my team on board!"
I'm going to make up an answer here that I think will help, and then I'll update it as I get your comments so we all learn from each other's success. This advice may sound overengineered (and maybe for your circumstance it is!) but I've learned not to underestimate the difficulty of leading even minor change in an organization.
Even if you are a junior engineer, you probably have more power to make that change on your team than you realize. However, success in this area often relies on a different set of skills than you typically use as an engineer. Hopefully my suggestions below can give you the confidence to take the first step. Pick and choose from them as you see fit.
Aim for the tipping point
Importantly, I believe that once a team tries this out for themselves they won't want to go back to their old ways. That is the tipping point. So your main goal isn't to change your team's process, but just to get buy-in to run a short experiment, say for a week. If all goes well, you'll have many hands helping you after that.
Eliminate moving parts
The less involvement you need for that experiment the better, so if your standups usually include a lot of people from different groups, consider narrowing the experiment down to just one sub-group of people, ideally one having a common supervisor or team lead.
In this case, schedule your "new" standup to happen 10 minutes before the "old" standup. That way you all get your updates written down in time for your team lead to attend the "old" standup on behalf of everyone in that small group. The rest of you can skip out, you've just eliminated your need to attend in person!
To be clear, the Google Doc standup works just fine even with lots of people, but the point here is to reduce any friction so your experiment can take off. You'll undoubtedly need to tweak some things at the beginning, and having fewer brains involved will help with that too.
Rally others to the cause
Pitch the experiment to your teammates first and get their buy-in. Share this article, discuss the merits together. Then go to your manager after for the decision already having the weight of some of your peers backing you.
A good manager will naturally be intrigued by an experiment like this, but could be hesitant to make changes that affect your peers before talking to them, and any time delay at this stage can grind the idea to a halt. Your manager will be grateful to see multiple supporters from the start.
Do the hard work first
When you pitch this idea to your manager show them the Google Doc all ready to go for the next day's standup. Have the date already in there and all your team members names. It's remarkably easy to say yes to an idea that feels like it already has the momentum to carry it to success.
I've seen a few budding initiatives fizzle out on someone's todo list at the "write down a few words and pick a date" stage, maybe your manager has as well. Doing the hard work first shows your manager that you have skin in the game to make this happen.
Thoughtfully address concerns
You've spent so much time with this idea at this point that it may seem like a no-brainer. Your manager will have a different perspective. Be willing to hear it out and reflect on the new information you're given.
If you're not used to pitching your ideas, it can be easy to get defensive or think of this part as a debate. It's not. In a debate both parties are on opposite sides vying for their positions. You want to be on the same side as your manager, coming to a thoughtful agreement about what is best for your team. The more you show this thoughtfulness, the more you will both win together as well as gain trust.
That said, come prepared so you can give this initiative it's fair chance! Your most compelling point is that the experiment has no cost and is entirely reversible. Even if it fails, the team will just continue doing the current process. And since you have your peers' buy-in already the team will likely feel motivated by the effort of having tried something new.
Know the roadmap
Your manager will ask you what still needs to be done to make this experiment happen smoothly, so have that list prepared as well. It will look something like:
- Send an email to the participants to explain the experiment and what they need to do. Include the Google Doc link. Give a reminder of the "why" here and don't hesitate to pump people up!
- Send the recurring standup calendar event to teammates, with helpful event description and have Google Doc link included here as well.
- Schedule a debrief for the end of the experiment with your manager and anyone else interested. The goal can be to discuss how it went, and make a decision on next steps.
Success?
As you can probably tell, I'm weirdly excited about this idea. Once we discovered it, we used it solidly at Convictional for the 4 years I was there. It feels so good to take a process that's working against you and to get it to work for you instead. It becomes fuel for solving other problems.
Please share your standup experiences with me! Have you tried something like this on your teams? How did it go?? So far I've never come across another team doing this, but I'm sure it's out there. Share your even better ideas too! 🙌
Top comments (0)