Outsourcing is one of the most prevalent trends in software development today. We are working in a global economy with greater competition and choice. There are many reasons you may be working with a distributed team. Here are a few examples:
Your company has grown and expanded and has several field offices.
Your company contracts out portions of development to third parties.
A merger has occurred and two companies need to work interactively over great distances.
As more companies adopt Agile methodologies, it becomes apparent that they don't scale all too well between great distances. To work around this, agilists have devised the Team-of-Teams approach. In decomposing the features of a product, each component is broken down to a set of features that are assigned to a small development team that makes up the greater team. In Figure 15-1, the large circle represents an entire company spanning several continents. The smaller circles represent feature areas that are handled by each smaller team.
There is an inherent problem if you take this approach using Agile methodologies. To break down a project and teams in such a way, you have to have some sort of implied architectural plan before you start. One of the core principles in Agile is to avoid big planning up front. Therefore, the challenge is bringing in the architectural role and keeping it lightweight and responsive during the development of your project.
Microsoft has worked in a Team-of-Teams approach on many projects including Team System. For example, on Team Foundation Server, Team Foundation Build was designed by Microsoft India in Bangalore. Team Foundation Version Control was designed by the Visual Studio team in Raleigh, North Carolina, and work items and the Visual Studio 2005 Team Editions were worked on primarily in Redmond, Washington.