| We define Distributed Extreme Programming as XP with certain relaxations on the requirement of physical proximity of the team members. DXP applies XP principles in a distributed and mobile team environment. In DXP, team members can be arbitrarily far apart as well as highly mobile. Some ideas about DXP have already been mentioned at the XP and Flexible Processes in Software Engineering XP2000 conference [Kircher+2001; Schuemmer+2001]. DXP addresses all aspects of XP, although to varying degrees. In general, certain things are irrelevant to the locality of the team, while others are totally bound to the fact that the team members are colocated. Table 44.1 summarizes some of the aspects that are relevant to DXP and some that are not. From this table it becomes clear that for effective DXP, we need to address the practices of planning game, pair programming, continuous integration, and on-site customer in a distributed team environment. In the section Addressing XP Practices and Values in DXP, we show how these practices are addressed. Table 44.1. Relevance of XP Practices to DXP | XP Practice | Requires Colocated Team? | | Planning game Pair programming Continuous integration> On-site customer | Yes. These rely on close interaction among the businesspeople, including the on-site customer and technical people. | | Small releases Metaphor Simple design Testing Refactoring Collective ownership 40-hour week Coding standards | No. These can be done independent of the fact that the team is centralized or distributed. | Note that we consider refactoring, by itself, to not require collocation. The actual implementation of a refactoring relies on pair programming. However, the decision on whether to refactor does not require collocation. Even more concrete design tasks may best be initiated alone [Cowan2001]; we consider this to be part of the refactoring, while the implementation tasks fall under pair programming. DXP Assumptions To be effective, DXP assumes the existence of certain conditions and the availability of several tools and technologies. Beyond the assumptions of XP, including speaking a common language and general openness, DXP assumes these things. Connectivity Some form of connectivity needs to exist between the team members. If communication is performed across long distances, it is assumed that the Internet is used as the communication medium. For company-local communication, an intranet can be used. E-mail The ubiquitous availability and asynchronous nature of e-mail make it a key enabling technology for DXP. It can be used as a convenient means to exchange information and to schedule any DXP sessions. Configuration management Effective management of programming artifacts mandates the use of some kind of configuration management tool. This in turn serves as a key enabler for collective ownership. Application sharing To apply XP practices in a distributed environment, some form of application- or desktop-sharing software needs to be available to the team. Videoconferencing For effective synchronous communication using audio and video among distant team members, some kind of videoconferencing support is needed [Steinmetz+1996]. Familiarity We expect that DXP can succeed only when team members know each other well and can view it as an extension of their prior work arrangements. Why DXP? XP stresses the need for physical proximity of team members. However, circumstances may prevent a team from working in physical proximity, thus mandating the need for using DXP. A company or a project may therefore be forced to adopt DXP for these reasons. Situational constraints A company or a project may have little choice because of the existing physical distribution of development teams. Many projects are sanctioned with teams residing in different locations, sometimes across the globe. Individual constraints An individual may not be able to work at the main project location, at least temporarily. It thus becomes important that the individual continue to stay part of the development activities even while being physically separated. Even if a company or a project is not constrained by circumstances, it may still choose to adopt DXP. This is because, in addition to maintaining the benefits of XP practices, DXP offers some additional benefits. Cost A growing trend in the software industry is to outsource all or part of a software project because of cost. It is often much cheaper to develop software in some countries, such as India or China. As a result, several projects are distributed across two or more countries. Convenient customer involvement DXP makes it easier to involve the customer, even if they are unable to be at the development site. With traditional XP, the customer would have to stay on-site. This has the drawback of removing the customer from their own company environment. In DXP, however, this problem does not arise because the customer need not be on-site and can simply be available to the development team through, for example, videoconferencing. Mobility In many organizations, some team members need to travel frequently to, for example, maintain customer contacts or attend conferences. DXP offers a smooth integration of mobile team members. Mobile team members can stay connected with the rest of the team by using mobile equipment such as a notebook with a small camera and a broadband or dial-up connection. The team members can then participate in the development activities for part of the day or even for just a few hours. DXP thus addresses circumstantial constraints of companies and projects, and offers tangible benefits beyond those offered by XP. Challenges in DXP In relaxing the XP requirement of physical proximity, DXP faces several challenges. Communication An important aspect of communication is to know how the other person reacts to what we say. To judge a reaction, typically we read this information from the body gestures, facial expressions, and voice patterns of the other person. In DXP, because the two people are not physically next to each other, how can they receive this information? Coordination When two or more team members working together on a project are in two different physical locations, coordination among them becomes a challenge. This can include synchronizing availability, adjusting for time differences, and coordinating distribution and integration of activities. In addition, document and application sharing among the team members can also be a challenge. Infrastructure Both communication and coordination among team members in DXP depend heavily on the infrastructure. This includes the available hardware and software as well as the bandwidth of the connecting network. A poor infrastructure can make it very difficult to make up for the physical proximity that may be missing in DXP. Availability Distributed team members may be available at different times. Some of them might be working on multiple projects and thus be restricted by time. Others might be constrained by personal limitations. In addition, the availability of distributed team members can also be affected by different time zones. Management The manager of the team needs to have a high degree of trust in their subordinates if the subordinates are often remotely located. Direct managerial control over distant subordinates can be difficult to execute, so new strategies may need to be defined. Addressing the Challenges/Solution DXP offers many challenges. However, each of these challenges can be addressed and in most cases overcome. Communication Given a close-knit team, good communication can take place among members without requiring physical collocation. For example, assuming that you know the other person pretty well, a video picture of your partner might be sufficient to be able to tell what they are thinking and how they react to your comments. The team members can use many different forms of communication to bridge the physical distance. For example, they could convene a video- or phone conference or could send each other e-mail. In addition, actual meetings could be convened periodically to enhance interpersonal relationships among team members, thus easing remote cooperation. When deciding on a particular form of communication, we need to consider many different factors. These include the cost of equipment and its usage, travel costs, cost of time, available bandwidth, and the effectiveness of the particular form of communication with respect to the tasks that need to be performed. Remote communication and cooperation can be greatly improved by the ability to share documents. With Web technologies becoming more and more inexpensive and thus popular, new ways of communication are now available that enable close involvement among team members across an intranet or the Internet via videoconferencing and application sharing. Coordination Proper coordination of activities among distributed team members requires effective planning. However, making extensive use of different lines of communication can facilitate this. For example, two members in different locations could exchange daily e-mails containing their schedules for the day. They could then assign certain slots within the day for working on a project. In doing so, they would also need to take into account any time differences that may exist. Availability The DXP team needs to formulate rules and guidelines to ensure the availability of the team members. The general XP spirit of not denying help to anyone asking for it should extend to being available for remote communication. All team members should be able to easily access a daily or weekly schedule of each team member's availability. Pair programming sessions or testing sessions should then be scheduled based on the availability of the team members, to enable the most knowledge diffusion to take place. Management Project leaders and upper management need to learn how to handle distributed teams. In particular, project leaders need to learn how to manage team members who are at different locations. This can include requiring daily or weekly reports from all team members, whether local or remote. It can also include giving regular feedback to team members to give them the feeling that they are connected and thus an integral part of the team. In addition, regular team events can help build trust and motivation among all team members. Infrastructure The availability of the necessary infrastructure is critical and not as easy to achieve as it may seem. Important factors in choosing the infrastructure components are ease of use, interoperability with other tools, and availability on different platforms. Addressing XP Practices and Values in DXP In addressing the challenges of DXP, we must not violate the practices and values of XP. As identified in Table 44.1, team distribution affects only four XP practices: planning game, pair programming, continuous integration, and on-site customer. This section examines each of these practices in the light of DXP and proposes possible solutions that can be applied to keep DXP within the realm of XP practices. Planning game For the planning game with a remotely located customer, support for videoconferencing and application-sharing software is needed. For example, application sharing can be used to write the story cards. Ideally, more than two participants should be supported. Though this is possible with certain solutions, such as CUseeMe, most videoconferencing software supports only one pair of participants.[1] [1] CUseeMe Networks, voice and visual communications over the Internet; see http://www.cuseeme.com.
Pair programming For pair programming between team members in different locations, Remote Pair Programming (RPP) should be used. This requires videoconferencing and application-sharing support, to share the Integrated Development Environment (IDE). Continuous integration Because a remote team member cannot move to a separate integration machine, an alternative must be provided. If one team member is working at the central team site, that team member can invite the other remote team member to do common integration at that machine. If both team members are remote, this is not possible, so integration needs to be done on the development machine. On-site customer Videoconferencing should be used to involve remote customers. In DXP, a remote customer is not really an "on-site customer," but a "virtual on-site customer." The big difference is that the customer needs to conform to a certain set of rules, such as coordination and availability. To ensure that we did not modify XP in general, we would like to revisit the four values of communication, simplicity, feedback, and courage in the context of DXP. Communication The use of available tools makes it possible to communicate effectively regardless of physical location. Therefore, the value of communication in DXP is as great as it is in XP, though it may take different forms. Simplicity The philosophy "Make it simple" doesn't depend on the physical location of the team members, so DXP does not affect this value. Feedback The value of feedback is equally important in DXP as it is in XP. The only difference is that feedback needs to be propagated across distribution boundaries. If there are no hurdles in communication among team members, providing effective feedback should not be an issue in DXP. Courage This value is not affected directly by the distribution of the team. Therefore, DXP does not modify the four XP values. |
