Distributed Agile: An Interview with Vishwanath Nagara

In this interview with Vishwanath Nagaraj, a client principal and project manager for Twist at ThoughtWorks, he discusses the concept of distributed agile and some of the tools that help make the idea a reality.

Sticky ToolLook: We've read about agile experiences in all sorts of environments and organizations, but there is almost always an emphasis on the value of collocated teams. How have you seen "distributed agile" work?

Vishwanath Nagaraj: A fundamental principle that all agile approaches to software development rely on is the principle of feedback. From a feedback cycle perspective there is definitely tremendous value in having collocated teams. However, for various reasons--global availability of talent, economic benefits, scale, etc.--distributed development teams have become a reality for most organizations. The challenge is to adapt and evolve agile practices to facilitate feedback cycles on distributed teams within a project or program context.

As you move across the spectrum of how teams can be distributed, the challenges vary in their intensity and nature. For example, a collocated team could be distributed as soon as it outgrows its physical space and you move a portion of the team to another facility or a different floor in the same facility. Inter-team communication gets hampered as soon as you do this. You often see this in organizations that follow a more traditional approach to software development, where the engineering team and the testing team are working in different facilities.

As you move up the complexity scale, you see globally distributed teams--probably from multiple companies--working on a project. There, you need to start addressing not just challenges around communication that distance propagates but also around different time zones, cultures, and language.

As a clarification of terms, I refer to "distributed agile" as a delivery model where there are full-lifecycle teams at different locations and development takes place in all these locations. "Offshore agile" is a model we have used successfully at ThoughtWorks, where teams are distributed, but a majority of the development takes place in one location--albeit away from the customer location--and there is a smaller cross-functional team at the customer location. So, in a sense, an offshore model almost replicates a collocated model but not collocated with the customer.

I have been part of teams which have successfully applied agile practices on a spectrum of such distributed and offshore projects. Given the challenges, we have realized that rapid feedback cycles and visibility are more important in a distributed team than a collocated one. We have been successful when we have appropriately addressed three key elements: people, process, and technology.

Sticky ToolLook: What are some of the pros and cons of distributed agile, and how can teams get past the obstacles?

Vishwanath Nagaraj: The advantages of distributed agile, as the term suggests, are a combination of the benefits of distributed development, which include access to talent, ability to scale, and economic benefits. Plus, they include the benefits that agile practices bring to software development, such as the ability to respond rapidly to market and business changes, faster time to market, lowered cost of change, and improved quality of software delivered.

The challenge, however, is to address effectively issues of distribution, such as reduced communication bandwidth, lack of visibility, cultural differences, etc., through pragmatic application of agile principles and practices. I believe agile practices and principles inherently address challenges that distributed teams face. For example, business sponsors on a distributed team often find it difficult to get an accurate visibility of progress and status of a project. Applying agile practices of working in short iterations and using working software to demonstrate progress at the end of every iteration is a very effective way to address this challenge and build trust with the business.

As discussed previously, the three broad areas that organizations need to address to make this successful are people, process, and technologies.
People

It is not just the technical ability but also values and attitudes that become critical to success in globally distributed teams. People who have multicultural experience, have lived outside their home countries, or, at the very least, are willing to travel are probably more open to building relationships across cultural boundaries. That goes a long way toward making effective communicators and team members on distributed teams.

Team structures and roles are another key element. Since agile practices are geared to respond to change, the role of a proxy customer collocated with an offshore team is critical for faster feedback cycles on business priorities and requirements. Similarly, even if development is not taking place on site with the customer, it is critical to have a technical role on site who communicates to the offshore team at all levels.

Rotation of people across locations is extremely important for shared context and to build trust amongst the distributed team members. As anyone who has worked on a collocated team knows, the tacit knowledge that team members often have about the project, process, and other people in the project is more effectively transmitted through face-to-face interaction.

Process

Distributed agile teams need to adapt their project planning practices in order to account for team distribution, however most--if not all--engineering practices should continue as they would on a collocated agile team. This is critical, since engineering practices such as test-driven development (TDD) and continuous integration (CI) play an important role in feedback cycles for development teams. Tests, for example, are a very effective way of communicating design intent and requirements to distributed team members.

The other, more social-engineering practice "Collective Code Ownership" is also critical to distributed agile teams. This practice encourages distributed teams to trust each other to work off the same codebase. This obviously needs to be reinforced with other engineering practices like TDD and CI and with the social discipline of not leaving a broken build for the other team to fix unless as a communicated exception.

On agile teams, project planning is a continuous process and not a point-in-time activity. When teams are distributed, such continuous planning needs to consider additional factors: does the remote team have infrastructure available to handle the changes being planned?; do they have the knowledge, or should the change be timed with planned rotations of team members so knowledge and context transfer is more effective?; general availability of the remote team due to local holidays or vacations; etc.

Agile communication practices also need additional considerations. Local standup meetings now need to be run distributed, hence scheduling such communication meetings and taking into consideration different time zones becomes critical. It is unfair, for example, if only one team has to accommodate the others' time zone requirements. I have often seen that teams that share the pain of having to work odd hours are more successful at building trust and collaboration with each other than those which are not sensitive to the other teams' contexts.
Technologies

The fundamental role of technologies is to provide a shared context, transparency, and the infrastructure for faster feedback to distributed agile development teams.

Collocated agile teams have a physical card wall that provides them instant visibility on priority and status of their project. Keeping physical card walls synchronized across multiple locations is a painful activity. Tools like Mingle from ThoughtWorks have taken the real world agile metaphors such as the card wall and digitized it. This has made it possible for distributed teams to experience the same or enhanced visibility on projects. That and the advanced analysis that is now possible with a digitized card wall provide for a more enriched experience of transparency and shared context to teams.

Using source control repositories that allow distributed teams to work off of the same codebase is critical for development teams to have a shared context. However, this must be supplemented by a suite of automated tests that are harnessed to a continuous integration and deployment process that allows for the rapid feedback cycles that distributed agile teams need. While this is important in collocated agile teams, on distributed agile teams it is critical to automate the construction and maintenance of the build and deployment process that can manage deployments across multiple environments.

For example, Cruise, our continuous deployment product, supports distributed teams in promoting builds to environments across locations, so each stage in deployment is utilizing artifacts that have passed through a pre-specified stage with adequate checks. This not only avoids rework but also ensures that a distributed team is confident that it is working on the right build that is deployed in the right environment to perform whatever tasks the team needs to perform, either user acceptance testing by remote customers or manual and automated testing by an offshore testing team.

Tools for test automation are more effective when multiple roles (across locations) can participate in the testing process. Twist, our collaborative testing platform, for example, will allow business users or even customers to author acceptance criteria using English-like constructs, and a development team in a remote location can automate these tests. This fosters collaboration amongst various roles, potentially located at different locations.

Sticky ToolLook: How do networking tools like email, instant messaging, video conferencing, etc. help the implementation of agile across a distributed team?

Vishwanath Nagaraj:In order to address the reduced communication bandwidth, the market has responded with a lot of fancy gadgets that promise improved communication. My vote would be to build your communication infrastructure using easily accessible, low-maintenance tools. So, rather than trying to simulate face-to-face communication through expensive infrastructure such as video conferencing (which you may choose to do at later stages), I believe it is more effective to start with simple measures such as:

• Phones: High-quality phones that teams can use for distributed meetings, such as sprint or iteration planning, distributed standups, etc., where there is an exchange of context and opinions that is better through voice than written communication. In addition, provide everyone on the team mobile phones with international-dialing capabilities. Team members who talk to each other frequently have a greater chance of building a trust relationship with each other.
• Instant messaging: Collocated agile teams usually sit across a table and there is near-constant conversation. While it is not always about work, this chatter forms an important part in communicating context on a project. Instant messaging is the nearest replacement to this chatter on distributed teams. What I like about instant messaging over email is the instant use of emoticons :), which allows you to communicate mood and tone with the written word. The "murmur" feature in our next release of Mingle allows project-specific team conversations and chatter to be recorded and made accessible to team members in multiple locations.
• Email: Despite its ubiquity, emails have traditionally not been very helpful for distributed agile development. Email conversations are not as effective and interactive as voice or instant messaging and are not usually available to people who join projects after the mail has been sent. Broadcasts often spawn fragmented responses. However, given its popularity, email communication will remain a major component in distributed team communication.

Sticky ToolLook: Do you think more organizations will be open to distributed agile as virtual tools blur the line between collocated and distributed teams?

Vishwanath Nagaraj: I definitely believe that more organizations will be open to distributed and offshore agile as the tools and technologies address the challenges of distributed teams. I also think the market imperative of adopting a globally distributed way of working is going make it attractive for organizations to build tools and technologies that support this way of working.

A consolidation of the various communication mechanisms is happening in our industry, which I think distributed agile teams can take advantage of. With email integration with instant messaging (e.g. Google mail and Google Wave's promise of richer communication mechanisms), I am sure we are poised for interesting opportunities for distributed agile development.

Having said that tools and technologies are a part of the puzzle, the harder challenges are often the softer ones--those that deal with changing mindsets, erosion of trust, and understanding different cultural contexts. Taking those critical steps to promote a one-team feeling and creating an environment where people can have fun while they work is what often makes the difference. In the final analysis of distributed or collocated, Murphy's Law exists and things do go wrong on project. When you cannot be there in person to fix things, it is the fun you are having working as a team that will make people go the extra mile to make distributed projects work.