Enhancing Communication in Distributed Development

Problem

I am managing a development team that was started in San Francisco and soon spread to the East Coast and Canada. From the very beginning, our QA was located in Vietnam, which is a 13 hours time zone difference. But that was not all. Not many people on the QA team spoke good English, which made video chats tiresome. Moreover, not everyone on the QA team felt comfortable speaking, so one or two people were speaking on behalf of the entire team.

Not long after I joined, I found myself staying late nights going over bugs in Excel spreadsheets and discussing with the team how to solve those. I was trying hard not to fall asleep: it would already be too late, and I couldn’t understand half of what they were saying. I was still onboarding myself and didn’t fully understand all the details, so the meetings were anything but efficient. We relied on video chats mainly because no one seemed to use tools like Jira and Confluence or even Slack or any tool that would require written input. As a result, many things that were shared in a meeting would remain undocumented.

Actions taken

I knew from the start that using collaborative tools was critical to improving communication. Therefore, I was all set to make the team use those tools, but I knew I had to simplify the existing processes. For example, people felt that Jira was too complicated to use and hence moved to Excel spreadsheets. That signaled that I have to simplify Jira much more if I wanted them to use it. In a nutshell, all processes had to be simple, straightforward, and easily accessible if people were to adopt them.

Then I decided to centralize the process of collecting and storing information. Too often, different pieces of information were scattered over various documents without sufficient context or regular updates. Links to product requirements and design or relevant development information would frequently be missing, which was impeding communication. I decided to create one collaborative document per feature where all information would be added. This document would be regularly updated throughout the development lifecycle and structured to enhance communication. Once I put in place those documents, I couldn’t care less if developers were in different time zones or were discussing problems in Zoom and Slack. Once the decision was made, they would be required to use the existing template to document relevant information.

My efforts to centralize information didn’t end there. Since we were doing development for iOS and Android while also having some back-end components, all information was scattered across different stories. I would have all those stories collected in that one Confluence page, making it easy to sync up between different platforms. To do that, apart from simplifying the Jira process, I also made sure that linking between Jira and the feature page in Confluence was aligned, which made the navigation easy.

Taking away verbal communication eliminated late-night meetings. We cut down time spent on communication to 10 to 15 percent of what we were spending just months before. Enforcing written communication and encouraging documentation also made everyone more comfortable because people in Vietnam didn’t have a good command of spoken English but communicated well in writing.

Lessons learned

• Simplify communication. Centralize communication. If you manage to make your processes simple and adjust them to your team dynamics, that will directly translate into improved communication.
• While written communication is a must, sometimes you need to hop on a call. If you start your communication on Slack and end up with more than 15 messages, it’s time to jump on a video chat. Also, when a new person joins the discussion, it’s hard to follow extensive Slack communication, so quick video chats that will clarify context sound reasonable.
• Centralization has its own limits. When people try to add comments on a single Jira ticket, something usually gets lost in translation. I would strongly recommend creating a new ticket for any new bug instead of adding a comment to the original one.Keep things simple. For example, submitting five straightforward Jira tickets would be much better than one with 40 comments on it