As with many distributed teams our approach to tools at Wildbit is to try to strike a balance between making sure everyone on the team knows what’s going on, and not having hours of meetings every day. We are very serious about the ability to have a lot of time during the day for focused work, so we sometimes err on the side of not enough meetings. For this reason the team hasn’t done formal daily standups for a while, instead opting for a weekly meeting to do a roundtable of what everyone’s been working on, and what the plan is for the week.
There are a couple of problems with this approach. First and foremost, it doesn’t always feel like time well spent—we shouldn’t be spending an hour a week just talking about what we’re doing. That’s why we have planning tools1. Another side effect is that it’s harder to respond quickly when issues come up. If a team member is having a problem, or we didn’t realize before that two projects are related somehow, it could take up to a week to find out what the issues are. So we wanted something better. Something lightweight, useful, and more frequent.
We realized early on that synchronous standups wouldn’t work for us—we just work across too many time zones to find a convenient time, and it also doesn’t make sense to have a standup at the end of someone’s day. We also didn’t want this to be just an update for everyone else, we wanted to make it a useful planning tool for individual work as well.
So we started looking for Standup bots built for Slack, and of course there are tons of them. We ended up signing up for Geekbot because it met our most important criterium: it’s asynchronous. We set up Geekbot to ask each team member (product, design, engineering, and QA—we’re all in this…) a set of questions at 9am in their time zone. This means each team member can use these questions to be thoughtful about their day and what they want to accomplish.
In order to make this more useful for us we also changed the questions a little bit. Usually the first question in a standup is “What did you accomplish yesterday?” This didn’t feel right to us—it felt too much like checking up on each other. Instead, we ask the question this way:
Did you work on what you wanted to yesterday? If not, what happened?
This might seems like a subtle change, but it shifts the focus quite a bit. Instead of listing out the things we did, this question allows us to tell each other if something happened that distracted us from the work we wanted to do, which helps us solve those issues as well. So here’s what our Geekbot setup looks like:
Every time someone answers these 3 questions, Geekbot posts a status in our #pm-standup team room in Slack, where we can all read through it on our own time.
There is, of course, nothing groundbreaking about what we’re doing here. But I wanted to write up our process because I know there are many distributed teams who struggle with this. The issue is always the same: How do we have standups that are useful and that don’t feel like busywork that just takes us away from the jobs we’re supposed to be doing? By using an asynchronous bot and adapting the questions to our needs, we accomplished a few important things:
- Every member on the team takes a few minutes every morning to plan out their day, and troubleshoot anything that might have gone wrong the previous day.
- Instead of weekly meetings of an hour long where we discuss what everyone’s working on, we now have focused 30-minute meetings every Monday where we solve problems and discuss issues that came up during the week (I keep an agenda as we progress through the week).
- I am much more equipped to fulfill my role as Product Manager because our updates are more frequent and the signal to noise ratio is extremely high.
So even if your remote team is against the idea of a standup, I recommend you try something like this. Don’t just do what we did though. Choose your own questions, your own cadence, maybe even your own tool. But do something—start with the question “How can we make frequent checkins useful?” and see what the team comes up with.
I have a whole other post planned about using Jira in small teams… ↩