How our remote team runs standups

The daily standup meeting is not a new phenomenon. Almost everyone is familiar with them, has heard the term somewhere, or knows someone who does them in their place of work. At Codelitt, we do our standups every morning at 11am EST, but it wasn’t always that way. Being an almost fully distributed team makes communication hard, and once we reached a certain size we had to change things up a bit to keep rocking at what we do. Here's what worked when we were small, when it stopped working, and what we did to fix it.

Back in the beginning of 2014 our communications efforts were all done via email. Yes. Email. We had long chains of emails under one subject line, discussing when would it be an appropriate time for everyone to get together to discuss progress on our current work, onboard team members, etc. Needless to say, this was an absolute nightmare. Codelitt is a mostly remote team, so coordinating efforts with people in different timezones by email was anything but fun. We wasted lots of time trying to coordinate ourselves, worked in silos, and had no sense of team identification. We were an unopened email in a stranger’s inbox.

5 people. 3 timezones. All the frustrations.



Soon thereafter we moved our email conversations to Hipchat, and later to Slack. Processes started to gain a little bit of structure, and every day we would post our progress on the general chatroom. We followed the standup meeting formula closely and would answer these 3 basic questions:

1. What did you do yesterday?

2. What will you be working on today?

3. Is there anything blocking you?

This was a big step for us in terms of visibility of progress and accountability. Everyone had to show their progress every day, and was committed to what they’d be working on going forward. However, different timezones meant that updates would come at different times in the day and would easily get lost in the daily communications.

As the team grew and we incorporated more time zones, we started doing mandatory daily catch ups on Google Hangouts at the same time every day. We call them Daily Standups, even though I’m pretty sure no one is ever standing up. Following the scrum formula of 3 basic questions, our team structure started to evolve.

Standups are usually in the morning, but due to the fact that we have people in Europe and the US West Coast, we needed to find some middle ground.


By doing this, team members get visibility on projects they're not directly involved in. Codelitt strives for transparency (you can find most of our processes in our github repos) and this platform provides the perfect space to do it in. We use standups to talk about projects in our pipeline, so we can get designers and developers involved in the project early on, rather than just dropping user stories on their desk. We all know what to expect, who our partners are, and where the company is headed. No team member will ever wake up one day and find they need to start work on a project they never heard of before.

Our daily standup also provides us with a chance to feel like a cohesive unit and identify as a team, even when disseminated across the world. It’s very important for a remote team to have some sort of psychological identification with the group who will be pursuing the same goals and break silos.

And also to discuss the possibility of team members being the lost links in the evolutionary chain


Our daily standup sessions are the place where we share our problems that are slowing down our work. We found that productivity was increased when we shared these issues with our teammates, rather than trying to solve them in our own little silos.

From a management perspective, doing a standardized daily meeting gives us the perfect means to coordinate efforts. Teams need to be coordinated, and as teams and projects grow, the efforts to reach milestones need to be coordinated as well.

When our team hit the double digits, we broke away from the 3 question scrum formula as our daily gatherings started to creep up closer to the hour mark. To regain efficiency and speed, we now do our standups by project rather than by team member. It basically goes like this:

1. We go down the project list: a senior PM leads the standup session, and calls out each project alphabetically. When steps 2-5 are completed for a project, we move to the next one.

2. When a project gets called out, the corresponding PM takes the lead and outlines what milestones were met the day before, and what is in line for his/her team for the day (partner meetings, deadlines, internal calls).

3. The lead engineer briefs the broader team with their progress, and mentions any blocks they might have. This is followed by the other developers in the team who do the same.

4. The designer in the project gives an overview of what was done the day before, and any other updates regarding asset building.

5. If there are any blocks we take a minute to try and resolve it there. If the conversation spans more than 5 minutes we try and move on to the next project to keep the conversation flowing and move that discussion offline on the dedicated Slack channel for that specific project.

An example of this would be the following:

Tom [Senior PM]: Hey everyone, let’s start with Project A.

Andy [PM]: Right, Project A had a partner call yesterday afternoon where new mockups were presented and we discussed a new feature they would like to incorporate in the admin panel. We should coordinate to have an internal call today to start speccing it out.

Bruno [Engineer]: Alright. Yesterday we started the refactoring of our code, so the team can probably continue on that while design mocks up the new feature.

Vicky [Designer]: Andy and Bruno let’s meet up after this and talk about that feature. As for design, the mockups were approved in the meeting yesterday, so going forward we’ll start working on User Stories for this new feature.

Tom [Senior PM]: Great guys, let’s move forward to Project B.

Not only did we gain speed and efficiency by doing our daily standup session per project rather than per team member, but we also increased involvement and participation. When using our previous per-team member formula, because we are a remote team, it was very easy to mute oneself and be distracted when one’s standup was done and not really listen to the other team members. Because our team members are involved in several different projects, they have to stay on top of what’s being said, not only to provide their contribution but also to help their teams move forward.

The last couple of minutes in our daily gatherings are usually spent on personal announcements, HR updates and 20% project time coordination.

Codelitt functions like a well oiled machine because we have these daily gatherings. They have improved our efficiency, speed, accountability and visibility across the board. They are the only time when the entire team is together, discussing projects and setting new milestones.

And making fun of the fact that our CTO shares a name with our CEO’s constantly barking dog. Bad Bruno.

Download our Incubator Resources

 

WANT MORE?

We’re known for sharing everything!

HANDBOOK

Save more time, get more done!

FREE HANDBOOK

Innovate from the inside

Written by
Vicky Jaime 13 Mar 2017

Creative Director, ocassional artist & space nut

YOU MIGHT ALSO LIKE

comments powered by Disqus