It’s clear that this work style has become more and more popular with no signs of slowing down. But it begs the question:
Since you won’t bump into each other at the office when working remotely, one thing you’ll want to do upfront is plan how you’ll communicate and how often you need to meet during the duration of the project. Some agile teams run short stand-up meetings daily, some two times a week, and some once a week. While there’s no set requirement, what’s important is that meeting intervals are sufficient enough to smoothly execute the project.
In my experience, it’s harder to execute daily stand-up meetings with a distributed team across time zones. Rather, we meet two to three times a week to give members who are joining quite early in the morning or late in the evening a bit of a break. We also have established a stand-up channel where at any time, we can discuss daily tasks and blockers.
Having a clear and well-defined scoping document is helpful for mitigating risk. I highly recommend you ask your team members to go through it at least once, and you’re aware of the overall milestones and deadlines so that there are no surprises.
Technology is our friend. The only reason we can do distributed work is thanks to technology. The days of conference calls, long email threads, and choppy video calls are coming to an end. Technology allows us to communicate so efficiently and effectively that it’s easy to forget we’re working with someone over five thousand miles away.
In the past year and a half, I really can’t think of a time that a work video call dropped or was cutting in and out. This reliability has helped make distributed work easier. And with screen-sharing, this is almost better than meeting in person for software projects with a strong design focus.
If you or a team member are in a place where the internet just isn’t good enough, you have a few backup options, such as your Slack channel. You can even comment directly on your issue tracking board, which requires lower bandwidth. And for those times when showing is easier than telling, it’s easy to take a screenshot or screen recording from your smartphone or PC and upload it from there.
Gigster has established a general tech stack to help PMs and their teams succeed at working globally. From Git repo to dev environments, cloud storage, team messaging, and issue tracking, a lot of this is already set up for you to get off the ground quickly.
When working with a distributed team, you’ll find that keeping a flexible mindset is essential. We’re naturally predisposed to wanting to create and keep a routine to some degree because it feels more comfortable. But one of the main reasons you need to be open when working in a distributed team is that team members that are spread across the world don’t have their 9-to-5 work hours at the same time you do.
People in different countries and from different cultures will also have different holidays that should be taken into account, and one activity that remote workers like to do is travel, which is natural since remote workers aren’t tied to a desk.
At Gigster, there are no specific restrictions from traveling during a project as long as you can maintain your level of output. This means that time zones can vary and conditions may change. Someone might want to take the early morning to snowboard in the Pacific Northwest or the afternoon to snorkel in Maui. These are actual examples from a previous project.
Rather than complain and push back about changing meeting times, when someone requests to reschedule with suggested times, we focus on the optimal time we can all adjust to. I just ask team members that when requesting a schedule change that it be done 48 hours in advance as to not make things too last minute.
Working in a distributed team doesn’t have to be scary. Taking the above into account will help smoothen your transition, and you’ll be pleasantly surprised what you and your team can accomplish from around the world.