Overview

Our application framework development is done by a team that is divided between Tokyo and Osaka.
We use many different tools and have refined our communication methods in order to carry out remote development work in these two cities.

These documents provide a brief summary of the helpful information on remote development that we have learned through this development work.

We recommend using these documents if you want to start working remotely on development projects.

Introduction

This document sums up the mindsets that are needed to carry out remote development work smoothly and how to put those mindsets into practice.

Background

With the population of Japan declining and aging, the government is proposing reforms in working practices to achieve the “Dynamic Engagement of All Citizens”. The reforms seek to reduce the long working hours in Japan and achieve diverse working styles.

Companies themselves are also actively working on reforms, and an increasing number of opportunities for remote development are expected in future.

We had already been carrying out remote development between our Tokyo and Osaka locations, and are assisting in the promotion of initiatives like this by creating these documents to provide other companies with a summary of what we know about remote development.

Our remote development

As we mentioned earlier, we carry out remote development between Tokyo and Osaka. While some team members are shuffled around, we keep a team of around 5-10 people for Scrum development.

We created our methods by considering what was needed for remote development based on our experience of developing application frameworks with some team members in Tokyo and others in Osaka.

While these documents are written with multiple offices in mind as they are based on our experience, the same principles are useful for cases where team members are working from home. The majority of our team members worked from home during our teleworking period in 2018, and the work was completed with no major issues.

Benefits of remote development

Remote development frees employees from the constraints of location.

In our case, for example, we can now assign personnel without location constraints.

Working from home also has the following benefits:

  • Time that was previously taken up by commuting can now be spent on housework or leisure activities.
  • It is possible to work together with people in regional locations who cannot commute into an urban center for various reasons.

Difficulties of remote development

Despite these benefits, remote development will not be successful if it is approached in the same way as on-site development.

Difficulties arise when a team is formed from personnel working in multiple locations.

The following things can be done casually in an on-site setting, but cannot be done easily in remote development.

  • Having a brief conversation with the team member next to you
  • Conducting a team meeting with a whiteboard
  • Assigning tasks to members by writing them on sticky notes

The mindsets described in these documents are based on trial and error that we carried out to overcome the difficulties of remote development like above.

Jobs that are suited to and unsuited to remote development

Based on our past successes in remote development, we can say that application framework development is suited to remote development.

Work that is contingent on location is unsuited to remote development. For example, the following types of work are unsuited:

  • Work that involves visiting clients (sales, requirement definitions, etc.)
  • Work that must be done in a specific location, such as accessing the production environment

Mindsets required for remote development

When team members carry out remote development from multiple locations, it is not simply a matter of the locations being divided. The way of working differs in various ways from when all members are in the same location.

These documents explain some of the things that members should keep in mind when doing remote development.
Consciously cultivating the following mindsets enables remote development to be carried out smoothly.

1. Make yourself seen and heard

When everyone is together in one location, you are able to communicate a variety of information to the team members through unconscious elements such as your tone of voice and facial expression.
In remote development, where team members are in different locations, this information is not conveyed, so your team members in remote locations have less of a sense that you exist.

In on-site work, you are seen and heard simply by being present. In remote development, you need to consciously make yourself seen and heard.

2. Digitalize your communication

Analog communication methods such as whiteboards and sticky notes are intuitive and easy to use, but arrangements like this are difficult when your team members are not right near you on site.

Make use of IT to use digital communication for remote development.

3. Record and share information

In remote development, not only are your team members working in different locations, their work hours may differ too.
In cases like these, it is important to record things so that information can be shared despite the differences in location and working time.

There are various styles and methods for recording information—choose the practice that is best suited to the information you need to record.

4. Use the best communication method for each situation

While chatting is the main form of communication used for remote development, there are other methods including email, video conferencing and phone calls. Each form of communication has pros and cons.

Understand the pros and cons of as many different communication methods as possible and use the best communication method for each situation.

5. Do not divide work by location if possible

When team members are working in different locations, there are two ways to divide work: by location or by other factors.
The best way to divide your work depends on the nature and situation of your project, but we believe that the best way to carry out remote development is to have the whole team working on the same tasks.

Work should ideally not be divided by location if possible, but ultimately you need to assess your situation and carry out your work in the most suitable way.

6. Avoid having solo remote workers on your team until everyone becomes used to remote work

If for any reason one team member is working alone at a particular location while the majority of the team work at a different location, the larger group tend to feel like they are the only team as they address their specific situation, and forget about the remote worker.

Make sure that no team members are working alone until the team becomes used to remote development.

Putting the necessary mindsets into practice

This section explains how to put the necessary mindsets into practice with specific actions.

Practices for “1. Make yourself seen and heard”

Use a “monologue” channel in the chat

Each member should have their own “monologue” channel.
These channels should be open so that everyone can read them.

These channels should be used for as-necessary posts about work the team member is about to do, their impressions about the work they have done and any difficult points they are struggling with. Anything the team member deems relevant is acceptable.

This allows each team member to be seen and heard by the others, and speaking up about difficult points enables help to be given by team members who know a solution.

Before we used “monologue” channels, our team members found it difficult to keep up with what their teammates in the other location were doing, and tended to forget that they were working together with the other team members. When we began using “monologue” channels, communication became more active and the team members not only became more aware of their teammates in the other location, they got to know each other.

We also recommend that team members post in the chat when they will be away (needing to attend a meeting for an hour, taking a five-minute break, etc.), so that the team is aware of who is present.

This is similar to the update channels used by the general public, but we have named them “monologue” channels so that team members do not feel too much obligation about these channels.

If single chats are used outside the team (for departments or the company as a whole), do not treat all accounts as their own monologue channel, as this results in too many notifications. Limit monologue channels to those that the team members need to read regularly. For example, this can be configured in the following way in Slack.

  • Members do not receive notifications to channels they are not following, so team members follow each other’s monologue channels and do not follow those of people outside the team.
  • It is possible to individually mute channels you are following, so team members can mute the channels of people outside the team.

Be conscious of the position of the microphone during video conferencing

Unlike when talking to each other on site, team members need to be conscious of their microphone during video conferencing.
If a team member is too far from their microphone or facing away from it, the microphone will not pick up their voice and their teammates will not be able to hear them, and will not have a sense of their presence as a result.

Team members should also make sure their teammates know that they are talking by using body language and turning to the camera when they begin to speak.

When listening, team members should verbally acknowledge what the speaker is saying rather than listening silently. Even simple body language such as nodding will show that team members are listening.

✓Make sure the microphone is not picking up noise

In addition to making themselves seen and heard by positioning their microphone carefully, team members must also make sure that noise is not being heard through their microphones. This noise can be caused by:

  • Typing on a keyboard
  • Turning pages in a notebook
  • Placing a drink on the desk

If activities like this are done too close to the microphone, the microphone picks up the sound, which creates more noise than you would expect.

Take care to prevent this noise: for example, team members who are in charge of minutes should type at a slight distance from the microphone, and drinks should be placed on desks slowly and gently.

✓Do not have multiple conversations at once during video conferencing

Sometimes meeting attendees break into smaller groups and chat.

This is not a concern on site, but in video conferencing, all sound is distributed equally, which means that every team member will hear every conversation, which is unpleasant.

Team members should make sure not to have multiple conversations at once during video conferencing.

Practices for “2. Digitalize your communication”

Make use of web services and software that can be installed on-premises

When digitalizing communication, you need to use tools that are suited to the specific communication being used.
These tools could be services provided online or software that can be installed on-premises.

The table below shows the services and software that we have used and found useful.
“Web service” indicates services provided online and “Software” indicates software that can be installed on-premises.

Role Name Type
Chat Slack Web service
Chat Rocket.Chat Software
Information sharing Knowledge Software
Code reviews Upsource Software
Task management Backlogs plugin for Redmine Software

✓Chat

For chat, we have introduced both a web service and software. We recommend Slack, but if it is difficult to use web services in a way that suits your organization, try the Rocket.Chat software.

We will now tell you about a method we have put in place to use chat effectively. We use a method called planning poker to estimate the working time of our tasks. Details on planning poker can be found in The planning poker object game: An Agile game! (Agile 2011 Conference) (external Japanese website).

We use Slack reactions to play planning poker in a setting where team members are divided between multiple locations. The name of the task is posted on Slack and members post number reactions (:one: :two: :three: :five: :eight:) while calling out responses. These number reactions are used to make moves in planning poker.

✓Information sharing

Knowledge is an information sharing tool that allows you to write and post articles in markdown format.

We post guides to building a development environment, materials on release procedures and the minutes of meetings to Knowledge. Knowledge is also used to post summaries and points that team members want to cover during discussions on chat. The content is posted before the discussion and the team members view it during the discussion.

An example of a document written in Knowledge

✓Code reviews

Upsource is a code review tool developed by JetBrains.

The tool links to IntelliJ IDEA, also developed by JetBrains, so using IntelliJ IDEA enables smooth code reviews.

Upsource can also be used without IntelliJ IDEA as it has web UI.

This is an extremely convenient tool, and we can recommend it with total confidence.

A code review with Upsource

✓Task management

We use Scrum as the development method.

In Scrum, tasks are broken down into fine granularity.The Kanban feature available in the Backlogs plugin of Redmine is convenient when using this method.

When tasks are broken down into small units, they are small enough to be handled easily without stress, enabling team members to take tasks autonomously and carry out the work that is required.



Example of Kanban

Burndown charts can also be viewed

Practices for “3. Record and share information”

Keep short-term records on chat

Chat is a tool for real-time communication similar to a face-to-face conversation, but unlike face-to-face conversations on site, a log of the text data is kept.

As the communication takes place in real time, acknowledgement by other team members is also recorded, and feelings can be expressed by typing only “!” or by using ASCII art, which also appears in the log.

This makes chat an effective method for short-term recording of conversations with evidence of the mood of the conversation.

Create minutes to keep long-term records

While chat can be used for short-term record-keeping, the elements signifying the mood can be noise when looking back later. Additionally, since chat screens move so fast, it is difficult to look for past records.
We found that relying on chat logs made information sharing more difficult, so we began keeping minutes.

Minutes should be used for long-term records, as they enable the main points to be compiled with no noise.
We recommend keeping minutes separate from chat due to the speed at which chat screens move.

We often use Knowledge for recording minutes.

Practices for “4. Use the best communication method for each situation”

Use chat for everyday conversations

Chat is probably best for your main communication method. Chats are easy to read and write and it is easy to look back on the log of recent conversations and share information between team members.

It is also ideal for casual conversation like the weather and leisure activities.

Use the phone to talk over discussion points one on one

While chat can be used for discussions, the phone may be best for talking over a vague idea, as it enables more interactive, real-time communication.

The disadvantage is that you do not have the log that is kept in chat.
After phone calls, team members should record the points that were discussed and the conclusions that were reached in chat or minutes before they forget.

Use video conferencing to talk over discussion points as a group

Where the phone is good for one-on-one conversation, video conferencing should be used when more communication is needed to talk over ideas.

Video conferencing enables team members to see each other’s expressions, so the communication feels similar to on-site discussions.

Like the phone, video conferencing does not enable a log to be kept, so the points that were discussed and the conclusions that were reached should be recorded in chat or minutes after the call.

Use email to contact parties outside the team

When contacting parties outside the team, it is often not possible to use the software and web services that are usually used. In those cases, use email.

While some communication can be done over the phone, team members should follow up by email so that they have a written record of what was discussed over the phone.

Practices for “5. Do not divide work by location if possible”

Do not divide work by location if tasks can be divided into enough small units

If tasks can be broken down to small enough units for multiple people to work on them, team members from all locations should work together on the same subject matter.

Breaking down tasks into these small units makes it easy for team members to take tasks and work on them autonomously.

Divide work by location if it is difficult to break tasks down into small units

If tasks cannot be broken down into small units, broad topics can be assigned by location.

In each location, broad topics should be broken down into tasks of roughly granular units when carrying out work.

Practices for “6. Avoid having solo remote workers on your team until everyone becomes used to remote work”

Do not use remote development involving solo remote work

This is not an issue if many team members have experienced remote development and are used to it, but if none of the team members are used to it, one option is simply not to use remote development.

Another good method is to begin by using tools that are suited to remote development on site.

  • Allow the team to get used to chat
  • Get in the habit of recording minutes in Knowledge
  • Try managing tasks using the Kanban in the Backlogs plugin of Redmine

Once the team gets used to these tools, they will be able to transition smoothly to remote development.

Always be conscious of the fact that you are working on remote development

If one person is in one location and the majority are in another, the majority need to always be conscious of the fact that the team is working on remote development.

  • Points communicated verbally should be recorded in chat or minutes
  • When using video conferencing, make sure the majority are not talking only to each other
  • Make sure no biases occur when assigning tasks or giving instructions

When sharing information, be strongly aware that the people in those different locations are all one team.
If information is shared thoroughly, nobody will be alienated.

This document is provided under the the international Creative Commons Attribution + ShareAlike 4.0 license.