Introduction

XP [Beck2000] is a lightweight methodology that has gained increasing acceptance and popularity in the software community. XP promotes a discipline of software development based on principles of simplicity, communication, feedback, and courage. It is designed for use with small teams that need to develop software quickly and in an environment of rapidly changing requirements. XP consists of 12 practices, which are planning game, small releases, metaphor, simple design, testing, refactoring, pair programming, collective ownership, continuous integration, 40-hour week, on-site customer, and coding standards. A careful analysis of these XP practices reveals certain key assumptions made by XP.

One assumption involves physical proximity. XP advocates a strong level of communication among team members. A key XP practice is pair programming. Pair programming is not just one person programming and the other observing. Instead, it is a dialog between people trying together to simultaneously design, program, analyze, test, and understand how to produce better programs. It is a conversation at many levels, assisted by and focused on a computer console [Williams+2000]. Therefore, a key assumption made by XP is strong and effective communication between the team members, enabling the diffusion of know-how and expertise throughout the group. To enable this communication, the literature on XP emphasizes that it is important to physically locate the team members close to each other. Ideally, the team members should all be in one room. This enhances the communication among team members through incidental overhearing of conversations [Beck2000] and minimizes any hesitation that the team members might have in communicating with each other.

Another important practice of XP requires close customer involvement through the entire development cycle. Different from traditional methodologies, XP stresses the role of an on-site customer and thus recommends having a representative of the customer working with the team all the time. The customer or one of its representatives thus becomes an integral part of the team. Therefore, a proper communication channel between the customer and the rest of the team can easily be realized if the customer is physically located on-site.

Thus, physical proximity of team members and close customer involvement are key assumptions made by XP. However, if physical proximity of team members or the customer is not feasible or desirable, will XP lose its effectiveness? In this chapter, we show how XP can be applied to software development and teamwork in a distributed team environment. Our crosscutting idea is whether it is really necessary for the team members to be physically located next to each other.

The next section describes our extension to traditional XP, which we call Distributed Extreme Programming (DXP). We describe the as sumptions made by DXP, the rationale behind DXP, the challenges in DXP, and how to address these challenges. Then we present our experience report on using DXP, and finally we present our conclusions.