In part one and part two in our series on Distributed Development challenges and solutions, we examined People Enablers and Process Enablers. In this third and final post, let's 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 of work is avoided.
The ‘real time’ nature of an electronic wall helps to avoid communication overhead and its transparency helps in building trust as well. This applies not only to the development team, but also to the product’s stakeholders when the electronic wall is shared with them.
A criticism leveled against electronic walls is that these do not convey information as clearly as physical walls do. There is definitely some merit in this assertion, as the benefits of ‘information staring you 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 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 collecting metrics accurately, with minimal effort.
Electronic Build Radiator
Similar to electronic story walls, the benefits of knowing the build’s status on a real time basis are immense. In fact, knowing whether the build is broken prior to checking in code is a critical hygiene factor, which can save the team from a lot of rework.
Knowing when the build is broken not only prevents check-ins in a broken state, but can galvanize the team to resolve the issue together, should someone be struggling with fixing the build.
A build monitor also helps ensure that teams do not ‘pass on the baton’ to another location when the build is in a broken state.
Communication and Collaboration Tools
The most difficult and persistent challenge in distributed development is the barrier 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, the constraints of doing this are a major limitation of distributed working. Inability to communicate and collaborate face-to-face not only creates a huge strain on team members, but also has potential for serious consequences such as loss of trust.
Hence, it is imperative that distributed teams be provided with appropriate tools for communication and collaboration, with the aim of getting as close as possible as being face-to-face. These tools should facilitate both individuals as well as group communication and collaboration and should allow for as much online communication as possible. Moreover, to the extent possible, video based communication should be used, 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, HipChat for conversations at team level, Google Hangouts for team meetings, IdeaBoardz for brainstorming and retrospectives, Trello for any activity requiring collaboration etc.
Organizations need to find the tools that 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 by which communication and collaboration challenges can be eased is by permitting team members to use their own devices, when they are outside the office, for example when at home or 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.
Maintaining a Wiki can help a great deal in effective context sharing among team members.
Source Control System
Distributed teams should work with a source control system which encourages trunk-based development, or otherwise 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 a larger 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 pushing their commits to the central repository. This may be achieved by using local, short-lived feature branches that are shared across team members for testing purposes, or by employing the “pull request” methodology when merging local changes to the central repository.
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 with in firefighting mode, once they become showstoppers or serious impediments to the functioning of distributed teams. The choice of network, access rights and bandwidth should ideally be addressed before the distributed team begins functioning.
Network related issues may be magnified when two different organizations need to access a single environment, 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 that comes into play for distributed teams is network security. This aspect also should be dealt with proactively, as security lapses on the network can lead to devastating consequences. A misconfigured network can lead to leakages of source code, which can be prevented through configuring the security permissions appropriately.
To summarize, distributed development does create additional challenges, but with appropriate enablers, they can be overcome quite effectively. Please share your experiences with distributed development in the comments.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
