Using Technology Effectively

Teams are often so eager to get the project ball rolling that employing fundamental delivery tools or creating a delivery platform comes as an afterthought. How many times has the need for a source code control mechanism been left until late in the project? Given the typical requirement for rapid product delivery and the communication barriers of a distributed Agile team, the early establishment of the proper tools and technologies is essential.

Distributed Agile teams typically rely heavily on tools to facilitate communication and the broadcasting of ideas. Begin by picking the best tool for the job. To quote the philosopher Abraham Maslow, "If the only tool you have is a hammer, you tend to treat everything as if it were a nail" (Krym, 2009). Email might not be the best mechanism to share documentation, so look for a better solution such as a shared drive or SharePoint. XPlanner is an excellent open-source project planning and tracking tool for Agile projects (specifically XP) and SVN has shown itself to be a versatile open-source source code control application. Furthermore, don't be afraid to experiment and discover what works and what doesn't work during the Retrospective.

A common Retrospective item is the distributed team having environmental issues, e.g., the onshore and offshore have different system setups or connectivity issues. Achieving a solid distributed environment is a critical success factor. These types of issues, no matter the difficulty, must be resolved. If they are left to fester, the project will possibly require an enormous unplanned time commitment and the team will become increasingly frustrated. For example, I performed an analysis of the team's velocity and found that over the past few Iterations the velocity had sharply declined. I looked back to the Retrospectives and found a reoccurring and, at this point, an ignored issue: offshore network connectivity problems (the offshore would be randomly kicked off the network and lose unsaved data). With some elbow grease the network connectivity problems were resolved, thereby restoring the velocity to an upward trend and removing a painful offshore frustration.

Understanding Cultural Differences

Every culture has its own accepted practices, social norms and ways of respecting authority. It is important to realize that Agile's practice of open communication and team member equality might be daunting for some. Malcolm Gladwell in Outliers: The Story of Success, points out that we all have "tendencies and assumptions and reflexes handed down to us by the history of the community we grew up in." Certain cultures are more deferential towards authority, and thus don't contradict a superior (Gladwell, 2008). Gladwell provides an example of deferential attitude by quoting the Korean linguist Ho-min Shon:

At a dinner table, a lower-ranking person must wait until a higher-ranking person sits down and starts eating, while the reverse does not hold true. All social behavior and actions are conducted in the order of seniority or ranking; as the [Korean] saying goes, chanmul to wi alay ka inssta, there is order even to drinking cold water.

You may find that during the Joint Stand-Ups, some offshore members might not be comfortable giving their status or voicing a dissenting opinion. Their local manager/tech lead might provide the status or answer questions on the whole offshore team's behalf. I once asked, via email, an offshore developer a question, and instead of responding back directly, the developer responded to his local manager, who responded to his onshore manager, who finally responded to me. Given this, it is the duty of the ScrumMaster or manager to help all team members act pro-actively and voice their opinions. Attempt to assuage their discomfort by creating a safe and open environment where dissenting opinions, new ideas and participation are not only welcome but also expected. Push back if you see the team passively acquiescing. Make sure every individual speaks his or her task estimation and you may well find that the consensus wasn't a consensus after all. Ensuring everyone has a voice will not only strengthen the team but is also conducive to a well-adjusted work environment.

Respect for the traditions and practices of your team's culture can also go a long way. For example, scheduling a Demo on Diwali, a major Indian Holiday in October/November, is disrespectful and will irk the offshore team. On the other hand, remembering and asking what their plans are for the holiday shows respect, understanding of the culture and creates a stronger team bond. Try it and you may even be treated to some wonderful Indian Diwali sweets.

A Final Thought

As we have seen, the removal of communication roadblocks is key to managing a successful distributed Agile environment. The Agile process is naturally flexible, being able to adapt and improve as necessary. However, Agile is a well-defined process with practices resulting from the lessons learned of thousands upon thousands of Agile projects. When appropriate, replace rather than remove Agile practices. Find the root cause of an issue and look for an alternative practice (Miller, 2008).

Agile greatly facilitates frequent communication and feedback, a sense of ownership, and team building. Applying Agile to a distributed environment creates a unique set of challenges, primarily around communication. However, these challenges can be overcome through forethought, structure and diligence. By following the guidelines outlined in this article "Effectively Managing Distributed Agile Teams" a high functioning and successful distributed Agile team can be achieved. To quote the early 20th century oil baron J. Paul Getty, "The formula for success: rise early, work hard, strike oil."

For More Information

Brooks, F. P. (1995). The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition. Addison-Wesley Professional.

Carnegie, D. (1937). How To Win Friends and Influence People. Simon & Schuster.

Fowler, M. (2006, July 18). Using an Agile Software Process with Offshore Development.

Gladwell, M. (2008). a href="http://www.amazon.com/Outliers-Story-Success-Malcolm-Gladwell/dp/0316017922 ">Outliers: The Story of Success. Little, Brown and Company.

Krym, N. (2009, February 05). Using Agile with Offshore.

Manifesto, A. (2001). Manifesto for Agile Software Development. Retrieved from The Agile Manifesto: http://agilemanifesto.org/

Miller, A. (2008, October). Distributed Agile Development at Microsoft Patterns & Practices

Schwaber, K. (2003). Agile Project Management With Scrum. Microsoft Press.

Shore, J., & Warden, S. (2008). The Art of Agile Development.

Yourdon, E. (1999). Death March: The Complete Software Developer's Guide to Surviving 'Mission Impossible' Projects. Prentice Hall.