Sticking push pins into a wall map to denote agile team member locations doesn't translate into a productive, global development organization. Seeking out companies that have created efficient, disbursed teams and asking how they did it won't help you, either. There are no best practices, just a few good ideas to think about and tailor around your particular objectives. Truly connecting those push pins means taking a critical look at three universal issues every organization must grapple with to make a global agile team successful: data considerations, communications needs, and a company's agile readiness. How you handle each of these issues will vary widely, and there are no best practices that can help.
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 accessto 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.