Data: Respect the 800 Pound Gorilla.
All application development outsourcing work is dependent on data. It is the one ingredient that can't be short-measured. Every development team must have access to data - company, customer, partner, etc. This could be live data or replica data, depending on the coding being done at any given moment. Not respecting the data can easily create problems that might impact the company's business (think application build rollout with billing, services, and e-commerce data). The first good idea to consider is having a data analyst on the team to implement and manage issue tracking and protect the company's source code. Whether this person is onsite or not will depend on the specific project, but onsite often works best. First, we need to look at why the data analyst is paramount to a successful global Agile team.

If left alone with a company's data, the development team will rapidly devolve into the coder's version of a child in a candy shop. It needs access to specific data to test a new piece of code, so it goes out and grabs it. This holds especially true with Agile teams, since speed is a defining aspect of the benefits of using Agile. The development team is doing what has been asked of it, however the team members aren't thinking about the business repercussions their work style is having. Without the data analyst to monitor these calls for data, discrepancies will occur.

The data analyst should set up and own the process of synchronizing original system data with the development team's system to avoid creating a ‘new version of the truth.' Think about billing and backlog reports being run from two versions of the same data, one a month old. Discrepancies could lead the development team in the wrong direction and cause painful repercussions for the company's business itself. One way the data analyst can avoid this is to create automated data disparity alerts, and monitor them frequently. There isn't a cure-all for preventing ‘many truths,' but there are some good ideas to consider for stopping them from becoming a problem. Setting up these alerts is one option.

Data analysts don't need to be onsite for the entire project. In fact, depending on the specific length, scope, etc. of a particular project, it may make more sense to only bring the analyst to the customer site for key moments of the project. The most important times for a data analyst to be present are during the backlog definition and release planning cycles. At these points, it will be easier to define additional backlog through stories or tasks during the iterative planning cycles. These are the points where data can turn against an Agile team if not handled carefully. An analyst who is familiar with the corporate data will be able to review the backlog and spot potentially disastrous discrepancies, or where they're likely to occur. Most corporations have a number of checkpoints through which a new piece of software must pass before it's allowed to enter a production environment - your basic ‘checks and balances' applied to IT. A data analyst should be present during these meetings to present a good case on data integrity, otherwise the project runs the risk of being hopelessly entangled in corporate bureaucracy, endangering the chances of a quick release into production. 

Communications: Can You Hear Me Now? No? That's a Problem.
Developers have built a certain reputation for themselves as elite, specialized resources that resist management rules and regulations. The complex nature of what they do breeds this type of behavior and, unfortunately for them, it also leads management to distrust the Agile concept of team self-management. For less experienced Agile teams, this lack of oversight has proven disastrous, often resulting in failed projects. For management, the thought of letting the ‘inmates run the asylum' in a globally distributed environment is almost laughable. The second good idea to consider is to set up effective communications strategies and boundary conditions for decision-making across the team. Clearly defining expectations of both team and management and how to facilitate collaboration is necessary for successful distributed Agile projects.

Holding a daily meeting, or Scrum, is essential to keep the team on the right track.  But how do you encourage attendance and participation when the team is thousands of miles apart? Let it be known that attendance will be tracked and participation noted. There's an amazing phenomenon that takes place when people think they're being graded, and this approach will motivate them for these meetings.  There are many telephony tools available which enable low-cost voice and chat along with application sharing.  These can be used throughout the normal working day with great effect to help simulate a single, onsite team.

The red herring of globally distributed Agile teams is that members must be located together. The very nature of Agile development dictates continuous, rapid communications between members, and there are many collaboration tools available that help team members who are dispersed around the world. These include WebEx, Skype, and NetMeeting. If your team has non-native English speakers, they may feel more comfortable using a chat tool, rather than a telephone, and this shouldn't be discouraged. Anything that facilitates better communication should be embraced. However, developers are people and they can't bond with programs - personal rapport goes a long way. Face-to-face meetings between team members are ideal for hammering out how to communicate. Generally speaking, it's recommended to meet every three months.

Boundary conditions are the key to putting management at ease about distributed Agile teams. This is the most important area to consider (more so than communications). A successful self-managing team must establish an issues hierarchy. This is not an authoritarian hierarchy, and in no way does it imply boss-subordinate relationships. As a team, members need to decide what situations can efficiently be handled by the developers, which ones are better suited for project managers, which would be handled best by the QA staff, etc. All parties must know what is in the realm of their decision-making sphere and what is not. More importantly, establishing clear guidelines for how to recognize when an issue has escalated from being a developer issue to a project management issue will help globally distributed Agile teams to operate effectively. For example, personality conflicts or ineffective QA practices are commonly kept with the developer rather than being moved up the chain to the project manager.

Agile-ready? It's not a Fit for Every Company.
Setting up a globally distributed Agile team takes a real commitment from an organization. Whether the team is home-grown or provided through an outsourcing partner, it needs to examine if it is ready to adopt Agile. Agile requires many changes within an organization, from upper management to company processes to the actual development team. The third good idea to consider is to make sure all these areas of the company are willing and able to adapt.

Starting at the development team level, companies that are apt to succeed with distributed Agile projects will have mature, experienced developers. The very nature of Agile work places a lot of responsibility and self-governance with each team member. Assigning developers to one project rather than diluting them across many is important, since shared resources can easily become problematic in a distributed Agile team. This is particularly true if a developer is working jointly on one waterfall and one Agile project. Also, a team that boasts prior experience with automated, test-driven development will be more successful with distributed projects.

From a management perspective, an Agile-ready company will understand that executive involvement is required on a regular basis. As with any Agile project, a distributed team is dependent on management deciding what business objectives are the most important for the new application to address. Management is also going to need to work with the Agile team to develop a smart set of boundary conditions.

In some organizations, the core principles of Agile may create friction. If an organization is used to working within a fixed scope, budget, or corporate release window, adopting Agile practices can be particularly shocking to the system. There are a couple of ways around this. Top level executive support becomes necessary here - otherwise, the needed changes are hard to affect. Make sure the CXO's are onboard.

If this isn't possible, and you must work within the corporate release window, focus on analyzing each window for what has the most business value. This way, Agile practices can be used to ensure the most valuable coding is done first. It may be possible to reduce the risk of the application you are looking to deploy or even decouple it from the core release in some way.

To set up a successful global Agile development team, a company should pay close attention to its specific data considerations, communications needs, and the company's Agile readiness. How you handle each of these issues will vary widely and there are no best practices that can help - just a few good ideas to consider.

About the Author
David Webb currently serves as Agile Practice Lead and Engagement Manager for Exigen Services. He has been working with distributed Agile teams for more than five years, establish practices and metrics to effectively manage and execute offshore Agile projects. David lives in London, England.