Distributed Development Enablers – Part 3

5 Feb

In the previous posts, we have examined People Enablers and Process Enablers, which can help in alleviating challenges of Distributed Development. In this post, the final one, let us look at Tools and Infrastructure related enablers.

 

  • Electronic Story Wall

A key challenge faced in a distributed working environment is ensuring that regardless of the location, everyone should have a common view of story wall, team metrics and so on. This can be best achieved through having an electronic story wall, which becomes the ‘single source of truth’ for all team members across various locations.

An electronic story wall can be a huge enabler in terms of bringing in shared understanding of iteration progress, blockers and dependencies. It can also help is ensuring that duplication or work is avoided.

The ‘real time’ nature of an electronic wall helps in avoiding communication overheads and constant transparency helps a great deal in building trust as well. This applies not only to the development team, but also to client and business, if the electronic wall is shared with them.

A criticism leveled against electronic walls is that these do not ‘throw information in the face’, like physical walls do. There is definitely some merit in this assertion, as the benefits of ‘information staring in the face’ at all times are immense. However, this limitation of the electronic wall can be overcome by either maintaining a physical wall, in addition to the electronic wall, or even better, by projecting the electronic wall in the area where the team is sitting. In case the team decides to maintain a physical wall as well, it is imperative that utmost discipline is required to ensure that the physical and electronic walls remain in sync at all times.

Regardless of whether a team is distributed or not, and electronic wall helps immensely in generating metrics accurately, with minimal effort.

 

  • Electronic Build Radiator

Similar to electronic story walls, the benefits of knowing the build status on a real time basis are immense. In fact, knowing whether build is broken prior to checking in code is almost a hygiene factor, which can save the team from a lot of rework.

Knowing when the build is broken not only can prevent check-ins in the broken state, but can galvanize the team to resolve the issue together, should someone be struggling with fixing the broken build.

A build monitor also helps in ensuring that teams do not ‘pass on the baton’ to another location when the build is in broken state.

 

  • Communication and Collaboration Tools

The most difficult and persisting challenge in distributed development is the barriers encountered in communication and collaboration between people across locations. While nothing can be more ideal than having face-to-face conversations, both individually and as a team, constraints in doing this is a major limitation of distributed working. Inability to communicate and collaborate face-to-face not only not only creates huge strain on team members, but also has potential for serious consequences like trust deficit.

Hence, it is imperative that distributed teams are provided with appropriate tools for communication and collaboration, with the aim of getting as close as possible to being face-to-face. These tools should facilitate both individual as well as group level communication and collaboration and should allow for as much online communication as possible. Moreover, to the extent possible, tools should aid video based communication, as seeing a person, even if it is via video, greatly enhances the quality of communication.

Examples of such tools include GTalk or Lync for point-to-point communication between individuals, Campfire for conversations at team level, Google Hangout for team meetings, IdeaBoardz for brainstorming and retrospectives, Trello for any activity requiring collaboration etc.

Organizations need to find tools which adhere to their security policies. This can be a challenge if the teams/people in charge of security are not sensitive to the challenges faced by distributed teams. It is important to work closely with the security team to identify tools which don’t compromise security and which meet the needs of distributed teams.

Another meaningful way in which communication and collaboration challenges can be eased is by permitting team members to use their own devices, when they are outside the office, viz. at home and while traveling. The organization will need to define and implement a policy for BYOD (Bring Your Own Device), which fits within the boundaries of the organization’s security policy.

 

  • Source Control System

Distributed teams should work with a source control system which encourages trunk based development, and minimizes the need for branching. Sometimes, there is need for team members to maintain source code on their respective machines and make local commits. If this is a valid requirement for the team, the source control system should have the flexibility to support this. Given that distributed teams put together may form a large unit, the source control system should support check-ins in large numbers, without having to grapple with conflicting pieces of code or juggling multiple versions. Team members should be able to view code changes across locations quickly and give feedback, as needed, before syncing with the repository.

A source control system which has a Wiki feature can help a great deal in effective context sharing among team members.

 

  • Network Connectivity

Network connectivity and bandwidth are actually more of hygiene factors than enablers for distributed teams. Teams working across locations, especially across countries, can pose network related challenges, which may not occur if the team is co-located. It is often seen that these challenges are not proactively anticipated, and are usually dealt in firefighting mode, once they become showstoppers or serious impediments to the functioning of distributed teams. Choice of network, access rights and bandwidth should be addressed ideally before the distributed team begins functioning.

Network related issues may get magnified when 2 different organizations need to access a single server, e.g. Client and Vendor. Complexities arising out of this scenario must be anticipated and dealt with in advance, to ensure smooth functioning of teams.

An important aspect which comes into play for distributed teams is security of the network. This aspect also should be dealt with proactively, as security lapses on the network can lead to devastating consequences.

To summarize, distributed development does create additional challenges, but with appropriate enablers, these can overcome quite effectively.

Please share enablers that have benefited your distributed teams.

 

 

 

 

 

 

 

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: