I orignally wrote this on RemoteBase. You can now read it here because RemoteBase is not live.

Can a remote team stay agile, despite the the fact that team members are not co-located? Justin Roberts might be a good person to ask, because he works remotely as a product manager and lead designer at a Santa Monica startup.

After transitioning from co-located company, Justin now works as a remote product manager and a lead UX designer at PatientPop. Based in a beautiful suburban town in Australia, he works with a team of more than 15 engineers and 170 total staff members located across the Pacific Ocean in Santa Monica, California.

Thousands of miles away from his team, Justin’s challenge is to keep his team agile in a fast-paced startup environment.

This article explores some different techniques he has used to keep his process and team agile, despite the added challenges in working across three continents.

The Team

PatientPop has a team of around 15 engineers and 3 product managers. Most of the product and engineering team are working from the headquarters in Silicon Beach, Santa Monica.

The team works from three vastly different timezones. As well as Justin being remote in Sydney, Australia, PatientPop’s VP of Engineering is also remote and based out of Paris, France. This in combination with the head office and rest of the team being in Santa Monica comes with it’s challenges.

A team meeting
A team meeting spanning three timezones

The team at PatinetPop is very well practiced as involving it’s remote members and does a great job to maintain communication and alignment. If a meeting or conversation can not be had in person, someone always takes notes and shares on a Slack channel so people can catch up later.

Greatest Challenge - Alignment

According to Justin, the biggest issue that distributed teams face is a lack of alignment. The team members can often become misaligned on where the team is heading and the product vision. Nuances in conversation are often lost in virtual communication, which can result in team members not understanding what they are working on and how it fits into the vision.

Misalignment like this within a remote team can affect the teams agility and potentially the organization in many ways. A team cannot stay agile when there is uncertainty around the vision and problem being solved.

In particular, Justin sees that the following factors of ‘being agile’ might be affected in a distributed team due to issues relating to communication:

  • Information becomes a one way flow and spontaneous communication breaks down. The whole team needs to make a effort to avoid this happening by making the time for more structured meetings dedicated to a certain topic.
  • Backlog prioritisation decisions become harder due to the product owner/manager not having all the information.
  • More documentation is needed due to ongoing communication not happening naturally. There is always a temptation for people to result back to a waterfall way of working.
  • Communicating Risks, Assumptions, Issues and Dependencies (RAID) to the people that need to hear it becomes challenging due to a lack of availability on people schedules and having to always book in a formal meeting for discussions.

Gaining Alignment

Justin admits that there is no substitute for having people in the same space working together to solve a problem. The advancement of collaboration and communication tools might never fully compensate for the lack of face-to-face interaction.

However he believes that the issues of misalignment can be mitigated to a certain degree with the right kind of tools and practices.

Using Slack

Justin mainly uses Slack to communicate with the team. Although not a perfect replacement for a real human interaction, it is particularly useful for quick conversations to share spontaneous ideas and keep conversation threads topical.

There is a Slack channel for every project or feature. This way, it is clear to all the team members and stakeholders where to go to discuss certain topics. Also such arrangement helps conversations stay contextual, preventing details from getting lost.

Sharing Early

Sharing ideas and work in progress early and often with teammates is critical to a remote agile teams success. It takes more effort to facilitate this but not doing so will result in a waterfall way of working where a designer or PM simply gives ‘specifications’ or ‘requirements’ to the dev team without the necessary team input.

For instance, Justin uses Google Docs to share feature summaries, also known as ‘requirements’, with the team. Google Docs allows him to share the feature summaries even before they are complete.

Anybody in the team can give feedback and ask questions on the summaries as they are being developed. This way, the whole team is able to give early feedback, and take charge in the evolution of the ideas. Everyone in the engineering team can be properly aligned with what’s expected.

To a similar end, Justin avoids Hi-Fi mockups as much as possible. Doing so makes his team more agile, because Hi-Fi mockups are often unnecessarily time consuming, and also cause issues later in the process.

A video call with whiteboard projected
Discussing some whiteboard scratchings

To him, all mockups, prototypes, and wireframes are there to aid the communication between team members. They are only a means to the end, not the end itself.

Personal Level Challenges

Distributed teams also face challenges other than those of alignment. On a personal level, Justin’s biggest challenge of working remotely and keeping the team agile is the very fact that he is remote.

As a product manager, he needs to make sure the team is focused on the most important problems to solve now. Doing so requires a great deal of communication, but being remote can make it difficult to communicate with the right people at the right time.

To mitigate such issue, Justin tries to have some face-to-face time with his team. Every quarter, he makes a trip from Sydney to Los Angeles for a general catchup. The catchup puts him in a good spot for the coming months.

Can a Remote Team Be Agile?

Justin believes the core notions of being agile are ‘communication,’ and ‘alignment.’ If the team always communicates about where they are, and is constantly aligned on where they are going, agility becomes natural.

Unfortunately, communication and alignment easily break down in a remote work environment. In this light, remote teams do have more challenges when it comes to being agile.

The best strategy for remote teams to be agile is to have design the work process around these two key notions of being agile, namely, communication, and alignment.

For instance, PatientPop’s engineering team at the headquarters is always mindful of those working remotely. They always include remote members to the happenstances of work, and keep them up-to-date using communication tools such as Slack, Trello, Google Docs.

A picture showing a video conference
Catching up with the headquarter

Having worked in many teams, both co-located and remote, Justin sees that “reaching a higher level of agility is definitely easier in a co-located team.” He has consulted other teams on becoming more agile in his career, and normally recommends that teams try to stay co-located if possible.

Yet for many reasons and benefits, an increasing number of teams are becoming distributed across different locations. The fact that the team is distributed should not justify settling on a suboptimal level of agility.

“Remote teams,” Justin said, “just need to work a little harder at it.”

You can reach Justin at @JustinRob. His personal website is www.justinrob.com.