During the last week of May, I attended and spoke at the XP 2002 conference held in Alghero, Italy (www.xp2002.org). Although most workshops and presentations focused on Extreme Programming (XP), many of them went beyond XP to discuss issues pertinent to agile software development in general. One such workshop was Dispersed Agile Software Development, led by Alan Wills, coauthor (with Desmond D'Souza) of Objects, Components, and Frameworks with UML: The Catalysis Approach (Addison-Wesley, 1999), and Michael Kircher of Siemens, who's currently working on a method called Dispersed Extreme Programming (DXP). At the full-day workshop, we identified some interesting techniques that can help resolve the problems faced by dispersed and distributed teams.
Remote Control
In distributed development, subteams work from several locations. Examples include outsourcing situations in which an external team builds part of your system and subteams within the same organization work together. In dispersed software development, however, a development team is uniformly located in several locations. Examples include individual developers working from home, individuals working in different physical areas within the same company, and individuals working on open-source software. The two approaches differ: In distributed development, it's the subteams that work at different locales; in dispersed development, individual developers work remotely.
It's important to distinguish between the categories because the problems differ. With distributed software development, developers on the subteams will bond, and your main challenges will focus on communication across team boundaries. With dispersed software development, everyone's effectively alone, and the main challenge is to make them feel like a team.
First and foremost, I advise you not to go looking for trouble. Although dispersed and distributed development makes sense in a variety of situations, I strongly urge you to avoid these practices whenever you can. That said, let's explore how to make these situations successful, focusing first on dispersed development.
The inherent communication challenges of dispersed development are the most difficult problems to overcome. When a team is dispersed, the opportunities for face-to-face discussion, the most effective way to communicate, are reduced. Instead, you're forced to rely on less productive strategies such as video conferencing, telephone conversations and written documentation—thereby dramatically increasing project risk. Unimpaired communication between developers and project stakeholders is a fundamental aspect of agile software development, so is it possible to take an agile approach to dispersed software development? Yes, but it takes work.
Together Time
To create a successful foundation, you should start the team in a single location. Your goal is to gel the team, to give people time to get to know one another and to build a common culture. This time together (at least a month or two is required) provides an opportunity for everyone to come to a consensus regarding the project scope and architecture. It also allows you to create some initial working software that helps to reinforce your chosen development standards and gives you a software base to build on. In an important side benefit of this approach, you may discover that you really don't need to disperse your team after all.
As your project progresses, you'll need strategies for adding personnel. The traditional and rigorous approach would be to first provide the new people with documentation to read at their desks and perhaps give them an overview presentation of your project, but agility demands more direct communication, first colocating the new team member(s) with one or more existing team members. The difference is marked: Instead of relying on relatively cold communication channels such as documentation or presentations, an agile project will focus on warmer methods, like face-to-face communication. Though documentation may still be provided, it isn't the primary tactic. Agile teams will have the new person initially locate and work with one or more existing team members; either in the office or, in the case of a truly dispersed team, in their home. Don't underestimate the importance of this initial bonding period: Without it, you run the risk of breaking the team's cohesiveness and effectiveness, which would threaten the viability of your project.
Afterward, don't sit back and relax: You need to work hard to keep the lines of communication open, with regular conference calls within the group, calls between individuals, and, if possible, work sessions in which the entire team gets together.
Have Team, Will Travel
When there's a great distance between individuals or subteams—perhaps they're on different coasts or even different continents—you'll need to support your efforts with travelers. A traveler is someone who works at one site for a few days or weeks, then moves to another site to work there for some time. Most travelers have a designated home base, although some simply travel from site to site. Travelers help to share information among team members and keep everyone in sync both culturally and technically. Being a traveler has drawbacks: It's tough on your personal life, and the traveling can be physically strenuous. Travelers are common with distributed teams, although they can be used with dispersed teams, as well. Rigorous project teams often use them to attend meetings or make presentations to the subteams. In contrast, agile travelers become active members of the development teams that they visit, building strong bonds and working with them face-to-face.
On the lighter side, morale-building activities such as pizza parties, staff picnics or even biweekly breakfast meetings aren't a viable option for most dispersed teams. As a creative alternative, you can plan simultaneous outings or events: Perhaps everyone goes out to see a movie on the same day, regardless of their location, or the entire team plays a distributed Internet game together.
Trust is a vital aspect of any software development effort, particularly so in agile development. It's difficult to trust people you don't know well or don't communicate well with. When people are dispersed, it's less likely that they'll know each other as well as they would on nondispersed teams. And, because their communication medium isn't as rich, more opportunities for misunderstandings arise.
It can be difficult to keep people focused on the tasks that they've taken on. A rigorous project team uses a manager to keep track of due dates, whereas an agile project team chooses a softer approach, such as assigning a "shadow" to each task who's responsible for seeing that the job gets done. The shadow checks on the person assigned the task, offering friendly prods when needed to keep things moving along. At any given time, you're likely to have several tasks that you're responsible for, and will be the shadow for several others.
Explicit Availability
Everyone needs to make their availability explicit, and the easiest way to do this is to agree to a common schedule and set of rules. Individuals and groups need to agree to a block of time when they're available to be contacted by other project members. This becomes more complex when the team is dispersed across time zones. A common solution is to negotiate overlapping blocks of times; for example, your London team is available in their late afternoon and your New York team in their early morning to schedule teleconference and videoconference meetings as needed.
Sharing Tools
Tools, their use, and interoperability among tools are critical to your project's success. Configuration management is also critical to your success—even more so for a dispersed project team—therefore, you need to select a version control tool early on. You'll also need to mutually agree on communication tools, including chat software such as MSN Messenger or AOL Instant Messenger, as well as collaborative software such as Microsoft's NetMeeting.
To use your tools, you need simple and concise standards and guidelines—such as numbering schemes for your version control system and rules dictating when to set the status of chat software to busy. Agile developers actively strive to adopt, tailor and then follow a common set of development guidelines and standards. Visit www.codingstyle.info for coding guidelines and www.modelingstyle.info for UML modeling guidelines.
Long-Distance Pair Programming
At the workshop, Dispersed Extreme Programming (DXP) was discussed. Workshop participants agreed that, though difficult, dispersed pair programming is possible. Michael Kircher indicated that you require a headset telephone, so you can talk with your partner while you type. Microsoft's NetMeeting was recommended because it enables you to share control of your machine over your network, allowing you to pair. Because dispersed pairing is so difficult, some people preferred to pair for a short time, then work separately for a short time, then come back together and merge the results. One participant suggested that you must check in code only as a pair to ensure that the unit tests are complete and the code quality high.
Not Optimal, but Not Impossible
I'd like to reiterate dispersed and distributed development are not optimal situations. I hope I haven't made it sound easy—it isn't. Neither is it impossible, if you follow the guidelines noted previously. For further details, visit Alan Wills' Wiki Web site, www.fastnloose.org/cgi-bin/wiki.pl/dad/?algheroworkshop.
I'd like to thank Alan Wills for his feedback regarding this article.
