Distributed Agile: An Interview with Vishwanath Nagara



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.


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.


About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.