As more companies become remote friendly, what do teams need to be aware of that may improve or hinder their performance? I’d like to share the framework we used to consider the challenges and opportunities working with teams in South Africa and Taiwan.
After our company acquired a business in Taiwan, I changed roles from Software Developer and Scrum Master to remote-Manager of the app development team overseas. I was tasked with aligning our development efforts and growing our app’s capabilities and revenue.
At the time, there was very limited interaction between the Cape Town and Taipei offices. The “offshoot” team was treated more as a friendly partner than another development team. Getting support around company-specific domain knowledge was slow and ineffective - not ideal to achieve our goals.
The issues we experienced with this cross-continental arrangement were:
- Different time zones: Taipei is 6 hours ahead of Cape Town so there’s a lot of time spent waiting for replies.
- Different cultures: This didn’t just apply to the dynamic with our Taiwanese colleagues. The diverse mix of cultures, even within the Cape Town office, sometimes caused friction during collaborations.
- Different languages: Our team’s mother languages varied between English, Chinese, Afrikaans, Telugu, Spanish, Dutch and Xhosa. Misunderstandings happened regularly.
- Limited infrastructure: Having to rely on consistent digital experiences across tools was difficult considering both countries’ questionable internet stability and sometimes even electrical stability (thanks Eskom).
- Missing trust: Most of us come from some type of hierarchical organisational structure where autonomy and working from home was limited or even discouraged entirely. In the beginning, we as a company definitely struggled trusting that our remote team members were doing what they said they were doing.
In the two and a bit years since then, we’ve integrated our development teams into cross-functional teams consisting of members from both offices. Even local team members now work regularly from home. How we got here?
My general approach to things is to just do them and then see what the effect is. I've been told by my manager as well as other colleagues that this is a bit radical. I've also learned that, in order to be a bit more pragmatic in my approaches, it’s important to at least measure the impact changes have in some way. That’s why a colleague introduced me to a framework helped us to visualise our problems so that we could more easily track our progress.
Visually representing the problems
In 2005, Agerfalk et. al. released a literary analysis of the opportunities and threats of Distributed Software Development (DD). The resulting framework is based on the three fundamental processes of software development and the three measures of distance that affect them with DD.
The fundamental DD processes are defined as:
- Communication:  An essential part of software development, communication becomes even more crucial in distributed teams. Not only in the way we communicate (away from the face-to-face ideal), but also in what tools we use to communicate requirements, concerns and information.
- Coordination:  Even if all software was developed by one individual coder, there would need to be some coordination with other professionals in teams like marketing, finance or business development. This process becomes even more difficult when dealing with a distributed team.
- Control: Any software development exists to fulfill a certain goal, outcome or customer need. Control relates to the overall management and reporting mechanisms that ensure the development takes place according to specific metrics of success.
The measures of distance affecting these processes are defined as:
- Temporal distance: This is a measure of the dislocation in time between two people who need to interact. Time zone differences and time-shifting are the two most common examples of this.
- Geographical distance: This is a measure of the effort required for one team member to visit another. It’s best measured in ease of relocation rather than just the physical distance. This takes into account factors such as transport between locations that may be easier to commute to and from, but are physically further apart than locations with less convenient modes of transportation. Here we should also consider ease of booking transport, getting visas and time of travel.
- Socio-cultural distance: This is the measure of one team member’s understanding of another’s values and normative practices. It’s an extremely complex dimension involving things like language, national culture, organisational culture and politics. At the very least, it’s important that team members acknowledge and accept that other team members might differ from their own frame of reference.
Gathering Qualitative Data
Using these dimensions in a matrix where each cell represents the impact of one dimension on one process, we could now visually represent the issues we experienced. We started by listing our problems in each cell definition, such as: “What problems did we experience with our communication if we considered the temporal distance?”
We ended up with something along the lines of the following table:
I know this is looking a little daunting but having this type of transparency into issues meant that we could focus on specific problems with contextual examples. More importantly, it let us know when we had resolved actual problems experienced.
For you to test this: You can use the template I created on Google Docs by making a copy of it. I’ve also left an example of the types of issues that we experienced ourselves. To gather more data, you can also collaborate with some (or all) of your remote colleagues to fill in more examples of problems faced in each cell.
Tackling the problems
Resolving all these issues may seem intimidating at first. Before we get started, here are two guidelines that helped me address them effectively.
Limit your work in progress
By limiting our work in progress (WIP) and focussing on resolving individual issues, we were able to solve almost all of the above mentioned problems. Focussing on all the issues at once is exhausting and you’re more likely to give up when seeing progress slowly. Another side effect is the risk of not seeing new problems that arise because you are juggling too many things at once.
Work within your sphere of influence
If we focus only on the issues we have little or no control over, we will soon become frustrated about our lack of progress. There are some issues that may be beyond the level of influence you, your team or even your department have. Most problems have at least one action that can either be controlled (do it yourself) or influenced (ask someone else to do it). If you can do neither, then it’s best to explicitly leave those.
Solving our communication issues
Whether it’s a discussion on what framework to use, what tests to write, what colour the button should be or what the weekend was like, communication is critical to how we build software. How we communicate is often taken for granted. I’ve found that a strong foundation built on effective communication is critical for high performing software development teams. When face-to-face communication is not available, we need to make sure we have made deliberate decisions on how communication happens.
Some of the challenges we experienced in our company’s communication were:
- Delayed feedback loops because of the reduced amount of synchronous communication (temporal)
- Increased cost and logistics efforts to set up face-to-face meetings (geographical) and
- Higher risk of misunderstandings and alienating individuals (socio-cultural)
The greatest communication challenge of all, however, was the complete lack thereof. When I started looking at our issues, I quickly realised that only a limited number of our Cape Town based developers knew the names of at least one Taipei team member. When a Taipei team member needed assistance, their requests would be routed via the old manager and from here onto the Cape Town manager who would forward it to a team member, then all the way back. This was exactly as efficient as you can imagine: not at all. When direct communication did happen, each team was using a different tool which lead to missing information and misunderstandings. This was compounded by the diverse number of team members who did not have English as a first language.
The things that had the greatest positive impact on addressing our challenges were:
Get-togethers
In retrospect this might sound like a no-brainer but having the two teams meet face-to-face was not always feasible. Nevertheless, getting everybody together in the same room turned out to be the best way to bridge the gap between in-office and remote team workers. We did this a few times by bringing over a few Taipei devs at a time to work and socialise with the Cape Town team.
If this isn’t financially viable, a simple introduction of the team over video also works wonders!
We used a simple ice breaker in which each team member introduced another colleague after having a brief discussion with them. The task was to share their name, their current role and experience level, know what they enjoy about working at the company and what their hidden super power is. When new team members start, we also share a picture and a basic bio with the entire company so everyone knows about them.
This helped break down barriers that would increase the risk of miscommunications. Once team members felt more comfortable communicating with each other, remote team members were less isolated.
Using proper tools
The reliance on tooling increases significantly with remote work. As communication may be asynchronous, it’s important that we can share information effectively. While some tools may come at a cost that your friendly neighbourhood CFO would reject, there are many free alternatives that have worked great for us:
- Zoom: If face-to-face communication is first prize for co-located teams, then video conferencing would take that honour for remote teams. It has proved indispensable on both the free and the paid tiers. Zoom is especially useful when local internet quality is questionable. We also use Hangouts frequently because of its great Slack integration.
- Jira: Jira is a great place to store contextual information for work to be done, visualizing flow in a single place across any distance. There should be a single place where work-specific, asynchronous communication can be viewed, replied on and archived. A free alternative would be something like Redmine or Trello.
- Slack: Slack is a great central place to communicate and has many integrations to existing development tools. Having a decent text-based communication tool is great for both synchronous and asynchronous communication.
- Google Docs/Confluence: Having a tool for sharing knowledge that does not relate to specific work tasks is useful for training, onboarding or general reference. We have used both Docs, and Confluence with great success. We lean more towards Confluence these days as it is so easy to link back to specific Jira tasks when documentation is written (or needed) to provide more context to the task.
Choosing tools and defining when they should be used, and in what situation, really helped us reduce miscommunication that would happen when discussions were spread across multiple tools. By using tools for specific functions, we also cut costs by getting rid of tools we were paying for, but not using effectively. These costs were not only for the tool, but also for the time spent (wasted) trying to use them effectively.
Solving our collaboration challenges
Coordination in software development is extremely important. Even if you’re the only developer, there’s generally a requirement for you to coordinate with another member of the company. At any scale, coordination efforts need to become a lot more deliberate with remote work.
Because our Taipei and Cape Town offices were initially run as two separate companies, coordination between the two development teams was virtually non-existent. In addition, both the Taipei team’s Product Owner and their new Manager, me, were based in Cape Town. That’s why our coordination efforts needed to cater for more asynchronous communication.
Some of the challenges we experienced for collaboration across the dimensions were:
- Increased coordination costs (temporal)
- Reduced casual communication that led to a lack of cross-team/domain task awareness (geographical) and
- Inconsistency in work practices that led to reduced cooperation through misunderstandings (socio-cultural)
We were heavily affected by the differing timezones: The 6-hour time difference caused a lot of idle time. Any questions that arose for our Taiwanese team in the morning needed to wait until Cape Town “came online” between 1-2pm (7-8am in ZA). For us in Cape Town, questions that arose in our afternoons, would only be answered the following morning. If any problem occured for our customers, who are mostly based in South Africa, we’d have to call in our Taipei devs’ assistance at very unfortunate times at night.
The change that made the single biggest impact on this situation was:
Creating a working agreement
When I first met the team in Taiwan, I made sure to share my own expectations for them. I then asked each of the devs to share their expectations of me as well. This became the basis of our first Working Agreement on how we would best communicate and collaborate. This included a shared understanding of when team members would be available, any expectations on response times and what would happen if these agreements were broken.
While this in itself won’t get rid of some of the delays and synchronicity-issues, it will and did manage people’s expectations. Our team started working a lot better with the explicitly known and stated delays. In addition, having this agreement allowed us to create a better system.
For example, for teams with colleagues in Taiwan, all meetings happen before midday in Cape Town (6pm in Taiwan) to make sure that all team members are available at a respectable time. Another example of this is when working from home. Teams generally set some reasonable time to respond like “I will respond textually on Slack within 30 minutes and be available for a call within 40 minutes”.
A well-formed working agreement - that grows as the team learns more about each other - helped immensely to create a semblance of consistency in work practices. Having generic practices, such as code reviews, put in a working agreement, means we can share the understanding of what is expected across all locations. Within each smaller team, they can also increase casual communication by setting aside how and when they can have casual chats. Having each team own their own way of working means you cut the time (cost) needed for some manager or head of department trying to coordinate this.
Solving our issues with control
As a manager of a small team, this was easy to do in isolation. However, as we scaled and integrated teams more, it became important to focus on the control aspect of problems. Traditionally, metrics such as “time spent” or “hours worked” were used as indications of performance. These are not great metrics for autonomous teams. With Distributed Development, these metrics generally cause even more distrust and anxiety.
Some of the challenges we ran into were:
- Delays in the traditional project flow (temporal)
- Difficulty in conveying vision and strategy (geographical)
- Different understandings of process, authority and hierarchy which can lead to problems. For example, being used to a certain level of hierarchy means you're also used to a lack of autonomy. When given autonomy, many don't know what to do with it, and either do too much (burnout) or too little (hide behind others)..
In order to address these, we’ve found the most useful measure to be:
Deciding what performance looks like
Setting a clear understanding on what performance is allowed all our teams, regardless of location, to have a shared understanding on what they need to do to succeed.
Autonomy can flourish when teams know where they are going and they are empowered to decide how they get there.
For us, lean metrics like Cycle and Lead Time meant that we could set goals around improving our overall flow efficiency. Trusting teams to improve this allowed them to define their own way of working towards the goals with their remote colleagues. If you’re using Jira, this is quite easy to do as it has a built-in report called Control Chart. It allows you to track Cycle Time per flow state such as "In Progress" or "In Testing" for even deeper optimization. If you don’t use Jira, you can of course, track the same things manually.
Either way, the idea is to focus more on measuring an improved process flow than on the number of tasks per developer per week.
Numerical metrics are great for context and the highlighting of possible areas of improvement. They do however come short in providing a truly accurate depiction of performance. In order to make our performance-view more holistic, we also make sure that the teams give regular feedback on their colleagues' performance in our 360 Reviews. That way, we want to encourage positive and constructive feedback amongst our peers.
In my experience, you never have the full picture as a manager. Having the team fill in the blanks on culture, interpersonal communication, contribution, work habits, performance and general interaction within the team has proven invaluable.
Wrapping up
As long as Distributed Development continues to rise in popularity, companies, teams and individuals will need to adapt to this change. If we can better understand our problems, it will make it easier to solve the ones that affect us most.
Even though the framework introduced was initially developed to highlight pros and cons of Distributed Development, it quite easily adapts to be used as a tool to create a measure of success allowing you to keep track of qualitative data into any problems that arise.
While the total list you generate may seem quite intimidating, many of these issues are related and will most likely be resolved by a few simple changes.
Resources
Tools
- Zoom: great video conference tool, works well over slow or interrupted connections
- Hangouts & Slack integration: decent video conferencing tool with a nice integration on to Slack on the free tier
- Jira: cloud based issue tracking solution. Expensive but well worth the money if used as simply as possible.
- Redmine: free, hosted issue tracking solution. Not great looking, but highly customizable
- Trello: free, super basic productivity app. Great as a simple task management solution.
- Slack
- Google Docs
- Confluence: great documentation platform, really shines when you use it with Jira
Bevan has been an IT professional since 2009 and is currently the Agile Coach at Travelstart. He has previously worked as a Software Engineer, Scrum Master and Manager for a team of developers in Taipei. His passion is coaching, enabling and leading people to do their best work & focussing on personal, career and organizational growth.
