5 Tips on How to Work with Remote Teams
At Jackrabbit we’ve come to work with a lot of distributed teams. Whether it is someone working from home or from another country, we have made a point to structure our workflow to allow for this sort of locational independence. On one of our recent projects we had team members in 4 completely different time zones!
Here are a few things I’ve found have worked well for my team when working remotely.
1. Stagger development, code review and testing.
This way progress can always be made while one team sleeps. This has worked particularly well for us when working with teams in different countries.
At the end of the working day, we make pull requests for finished features to the main development branch. Then, while the feature’s main developer sleeps, another person on the team will review the code and give feedback. We’ll have our daily scrum and, by the next morning, the feature is often ready to merge.
The same goes for last minute finds. Lets say we discover a bug at the very end of our working day, or a client requests something urgent. All we have to do is update our project management software (I am partial to Trello and Pivotal Tracker), and by scrum time the next morning we can already show the fix to the client.
This gives the impression to outsiders that work is constantly being done – and in a way, it is!
As long as everything is well documented with screenshots, arrows, and explicit steps to reproducing bugs, working in different time zones can really help speed things up.
2. Use video and screen share a lot.
Our main tool for meetings is Google Hangout, but we also use UberConference and Skype. All three are free and let you share your screen.
During our daily standups, we have each person screenshare and walk the team quickly through what they’ve been working on. Sometimes that means a designer taking the team through some ideas for refining the UX, or a developer demoing a partially done feature.
Having a visual helps get everyone on the same page, and does wonders to remove communication gaps, especially if team members have different native languages.
3. Keep at least 3 working hours that overlap.
This is good for ad-hoc communication, collaboration, and team problem solving.
We make a habit to have our daily standup at the beginning of the working day for the ones doing the work, and aim for 3-4 overlapping work hours following our standup.
It’s also good for joking around, team building, and making sure everyone working on a project feels part of the team.
4. Make feature planning a top priority.
We use scrum to run the majority of our projects. Before each sprint, we gather the team on Google Hangout to walk through the prioritized backlog where UI wireframes or mockups have been added prior to the meeting. Since your team isn’t sitting beside you to just lean over and ask when you need clarification, it’s paramount to make sure everyone on the team understands the exact functionality you’re hoping to achieve at the very beginning of your sprint.
This meeting usually takes 1-2 hours, depending on the length of the sprint we’re planning for. By getting everyone on the same page at the beginning of the sprint and writing down decisions as well as acceptance criteria of each feature, we minimize back and forth over the course of the sprint.
Though a 1-2 hour meeting might seem crazy long, it liberates the entire team from needing to have any other meetings for the course of the sprint, aside from our 15 minute daily standups. No more ad-hoc discussions on what the feature should actually do, or debating what your client is expecting.
One big advantage we’ve found as a remote team is that we aren’t around the office to distract each other. Any inefficient communication is exposed right away.
5. Develop stories in unique branches and standardize your gitflow.
When more than one developer is working on overlapping features at the same time, sometimes we’ll have merge conflicts – especially when working with storyboards. Having staggered work hours helps us avoid this, since the chance of two branches needing to be merged at the same time is significantly lower.
We also make a point that each feature is developed in its own feature branch, which makes testing any change easy for anyone on the team at any time.
Though these 5 things are some of the most important things that come to mind, there are tons of tricks to making your team gel remotely and be productive.
Feel free to reach out to me on Twitter if you have any tricks of your own for working with remote teams.
Older posts