The remote matchmaking cheat sheet
By Sunit Parekh, Technical Director of ThoughtWorks India
Distributed Software Teams bring together developers from around the world. This impacts everything from an organization’s global footprint to cultural aspects like making communication a priority or trusting team members to function independently in order to value collaboration over relationship. traditionally desired skill sets.
The current global Covid-19 pandemic has propelled the distributed model to the fore, with remote working becoming the norm. And, while video conferencing tools like Zoom and Webex are still available for teams, the challenge lies in how to best use them in the new way of working.
Just as important as an efficient pairing setup in the office, which includes a large monitor and an additional pair of keyboard and mouse, is the right setup for remote pairing.
We start by choosing our tool carefully – efficiency is everything. Available options include Zoom Breakout Rooms, Visual Code Live Share, Tuple, and more. The bottom line is that screen sharing alone is not the criteria, both developers need to be able to control the keyboard and mouse for a productive pairing.
I have found Visual Code Live Share to be extremely competent, especially with the following plugins –
â Live Share expansion pack by Microsoft
â Live audio sharing by Microsoft
â Chat shared live by Microsoft
I have also found Live Sync to be extremely responsive, even with low bandwidths. What I like most about this app is that both developers can take advantage of their own IDE preferences – themes, shortcuts, and navigation without disrupting each other. You can even share your terminal from VSCode with local zsh settings.
Make sure that the chosen tool is collectively accepted by the team and also approved by your organization. We also recommend that you check your chosen tool sets for detecting security vulnerabilities, such as the need to upload your code to remote repositories (similar to the man-in-the-middle), which could put your data and your code (and client) in danger.
When pairing, one can organize discussions and look for quick meetings with team members to make some decisions. The whiteboard is appropriate for such discussions. And, in remote mode, you can have your choice of viewing tools like Zoom Whiteboard, Microsoft OneNote, Google JamBoard, or Google Drawing and Mural. Personally, I have found the simpler tool to be the most effective – Mac’s Notepad or Mind Map, both of which are great for capturing points during chats.
Another tip for those with an iPad and a pencil – pair the setup with the screen mirroring feature on Zoom screen sharing for optimal interactivity.
You can choose between ping pong and pilot and browser pairing styles. My personal preference is the driver-navigator approach as it doesn’t require switching controls from person to person like ping pong does.
Here are a few things I suggest you get used to when pairing remotely:
– Interact with your pair. It could be a “Yes” or a “Very good”, or “Perfect” to make your presence and your participation felt. Avoid ghost mode in meetings.
– Avoid monopolizing the control of the hardware during pairing. This is a very common occurrence when pairing remotely, especially if your pair is a less experienced developer or new to the team.
Some other useful tips for remote pairing –
– Use wireless headsets. They allow you to talk and engage as comfortably and naturally as possible.
– Don’t forget to take breaks.
– Take advantage of the Pomodoro technique.
– When pairing using independent meeting IDs, posting the pairing matrix with the respective meeting IDs will help people connect at all times.
– For cutting edge stories (like research, proof of concept), switch to individual mode for a short time. Then resume with the match or a group of developers if necessary to share your thoughts before concluding the stories.
– It is easy to call on ad hoc development groups when the team is collocated. In a remote setup, predefine a time for development meetings or organize the mechanisms to call for a more impulsive development meeting.
– In case of low bandwidth issues, I highly recommend using VS Code Live Share or Zoom without audio. Use your cell phone for clearer sound, which also saves bandwidth.
– In extreme cases such as a complete internet outage, it is best to agree on different tasks in separate code bases, for the same story. For example, frontend and API development can take place individually with periodic synchronizations at predefined time slots.
Anti-patterns to avoid when pairing remotely –
– Going into the match without a trial period with tools and timetables – solving the basic logistical issues of the match will make the process more collaborative rather than difficult.
– Opt for shiny new tools that are the trend – weigh the value (or benefits) of the tool against the effort required to change the whole team.
– Make decisions in silos without sharing comments and have efficient and timely interactions with the team – disseminate the decisions taken while matching and leveraging the information shared on discussion groups like Slack, Teams.
After these few weeks of forced teleworking, I would say yes, remote twinning works in tandem with the right tools and the right mindset. However, just like with a regular pairing, it takes time and commitment to be comfortable and productive. More details on this can be found at MartinFowler.com. I would definitely recommend a read!
– Screen (https://screen.so/#/home) looks promising by the founder of ScreenHero.
– Learn more about pair programming:
– Master Class in Pair Programming – A series of podcasts by some of my ThinkWorker colleagues
– VS Code Live Share security details https://docs.microsoft.com/en-us/visualstudio/liveshare/reference/security
If you have an interesting article / experience / case study to share, please contact us at [emailÂ protected]