Communications: Can You Hear Me Now? No? That's a Problem.
Developers have built a certain reputation for themselves as elite, specialized resources who 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 that 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 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 homegrown 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.
