Use "remote native" processes and approaches
As the pandemic stretches on it seems that highly distributed teams will be the "new normal," at least for the time being. Over the past six months we've learnt a lot about effective remote working. On the positive side, good visual work-management and collaboration tools have made it easier than ever to collaborate remotely with colleagues. Developers, for example, can count on Visual Studio Live Share and GitHub Codespaces to facilitate teamwork and increase productivity. The biggest downside to remote work might be burnout: far too many people are scheduled for back-to-back video calls all day long, and this has begun to take its toll. While online visual tools make it easier to collaborate, it's also possible to build complex giant diagrams that end up being very hard to use, and the security aspects of tool proliferation also need to be carefully managed. Our advice is to remember to take a step back, talk to your teams, evaluate what's working and what's not and change processes and tools as needed.
Distributed teams come in many shapes and setups; delivery teams in a 100% single-site co-located setup, however, have become the exception for us. Most of our teams are either multisite teams or have at least some team members working off-site. Therefore, using "remote native" processes and approaches by default can help significantly with the overall team flow and effectiveness. This starts with making sure that everybody has access to the necessary remote systems. Moreover, using tools such as Visual Studio Live Share, MURAL or Jamboard turn online workshops and remote pairing into routines instead of ineffective exceptions. But "remote native" goes beyond a lift-and-shift of co-location practices to the digital world: Embracing more asynchronous communication, even more discipline around decision documentation, and "everybody always remote" meetings are other approaches our teams practice by default to optimize for location fluidity.