Software development processes are your foundations

Process is usually not a top-priority when a team is co-located. Teams that reside in one office, often get by with little to no process or standardized workflows or structured communications. If co-located teams take-on remote team members, and do not develop good processes, they will experience many frustrations and loss of performance. This alone may cause them to consider the collaboration a failure.

Therefore, one of the most important planning initiatives for organizations preparing to work with remote teams is designing robust processes, workflows, and structured communications – all of which I refer to as “process”.

Process is simply put a structure for working. When team members are dispersed, using a common process is essential to knowing how to work together: expectations of team members, when to perform key activities, and overall how to achieve good team performance.

Fostering good team collaboration begins with designing processes and workflows that encourage collaboration. Especially in a distributed team model, good collaboration needs to be “engineered” into the engineering process, and the day-to-day workflows of the team.

Software engineering and testing teams have significant advantages with distributed members, because for decades engineering teams became accustomed to process as a means of facilitating good software engineering. Today many teams use Scrum, a framework for managing agile processes. Scrum has gained so much favor in the software development world, that most engineers today have either worked in a Scrum process or can freely explain the key elements to Scrum.

The main advantages of Scrum from the perspective of managing remote or distributed teams are:

  1. Engineers can on-board quickly since they understand the general underpinnings of how to work in an Agile team.
  2. Managers can track and assess the performance of the team through the activities of the process, and by using metrics that are associated with an Agile process, without the need to “see” developers at their desks.

As far as process is concerned, the main difference between an agile co-located team and an agile distributed team, is how well the process it’s defined. With a distributed team, processes should be well documented and easily accessible for the team to read and follow and collaboratively adjust. A simple wiki serves this purpose. For example, one team we worked with who were implementing weekly sprints even posted a day-of-week schedule for the team to follow: activities for Monday, Tuesday, etc.

Processes should include communication protocols: team member contacts and their roles, when meetings occur, who is responsible to attend those meetings, and what tools are used. Protocols should also define off-hour or emergency communication procedures and phone numbers.

Think of workflows as more detailed expressions of your processes, similar to logical decision-making trees. In Git For Teams (O’Reilly), the author presents examples of very well defined workflows and processes using Git for Agile Scrum teams. The published chapter Workflows that Work is a great introduction. Use them as examples of how detailed and well-define your workflows can be.  Written workflows help team members place their task or problem in the right context, and understand what their options are for handling them.

Far beyond resolving loss of performance, robust processes can enable distributed teams to actually outperform collocated teams.  In a 2009 article titled How to Manage Virtual Teams, published by MIT Sloan Management Review, the authors write:

“Virtual teams that had processes that increased the levels of mutual support, member effort, work coordination, balance of member contributions and task-related communications consistently outperformed other teams with lower levels. Moreover, dispersed teams that had high levels of task-related processes were notably able to outperform co-located teams with similar levels of those same processes despite the physical separation of their members.”

I suggest making a best effort to design your processes up-front collaboratively among your team members, internal and remote.  Working together, your team will feel more ownership of the process, and it’s a good team building exercise.  It doesn’t need to be perfect. Refinements can be made iteratively.

Go to Next Chapter