«Abstract We conducted an industrial case study of a distributed team in the USA and the Czech Republic that used Extreme Programming. Our goal was to ...»
Essential Communication Practices for Extreme Programming in
a Global Software Development Team
Lucas Laymana,*, Laurie Williamsa, Daniela Damianb, Hynek Buresc
Department of Computer Science, North Carolina State University, 900 Main Campus Drive, Raleigh, NC 27695,
Department of Computer Science, University of Victoria, Victoria, BC V8W 3P6, Canada
Radiante Corporation, 3108 Falconhurst Dr., Wake Forest, NC 27587
We conducted an industrial case study of a distributed team in the USA and the Czech Republic that used Extreme Programming. Our goal was to understand how this globally-distributed team created a successful project in a new problem domain using a methodology that is dependent on informal, face-to-face communication. We collected quantitative and qualitative data and used grounded theory to identify four key factors for communication in globally-distributed XP teams working within a new problem domain. Our study suggests that, if these critical enabling factors are addressed, methodologies dependent on informal communication can be used on global software development projects.
Keywords: global software development, extreme programming, case study
1. Introduction Distributed software development (DSD) is becoming common practice in today’s industry. With DSD, software development teams are not physically co-located and, therefore, cannot see or speak in person on a regular basis.
DSD ranges from team members being distributed over adjacent buildings to being distributed over different continents. Global software development (GSD) is the special case of DSD in which the dispersion of the team extends across national boundaries . GSD includes both outsourcing and distributed teams within the same organization that are disbursed in different countries. GSD allows organizations to overcome geographical distances, to benefit from access to a larger resource pool, and to reduce development costs. Over the last decade, outsourcing of information technology (IT) has become a mainstream business phenomenon, and offshore management is emerging as a critical business component for firms. The amount of software exports from India alone increased 16-fold from 1995-2002 , and the software production industry in India has seen annual growth rates of 30-40% in both employment and revenue in each of the last 10 years . GSD has brought about its own unique set of challenges. Issues regarding cultural and language differences, trust and commitment, extended feedback loops, asynchronous communication, and knowledge management add new difficulties to today’s alreadycomplicated software development [13, 26]. These issues seem to preclude the use of processes reliant on informal communication, such as agile  methodologies.
Communication, particularly informal communication , plays a critical role in the success of a GSD team [9, 19, 23, 25, 40] and, therefore, has been chosen as the central theme of this paper. We describe a GSD team that used Extreme Programming (XP) , a process that requires an informal, communication-rich environment in order to succeed. Communication is one of the five central values of XP  and many of the XP practices explicitly support this value . Our case study involved a project contracted to an organization with a development group in the Czech Republic, Radiante Corporation, by a U.S. telecommunications software and hardware provider, Tekelec.
The project involved the creation of a simulator for a telecommunications signal transfer point system. The project was the first time the two organizations had collaborated on this technology. Project management personnel, including the customer, project manager, project tracker, and development manager were located in the U.S. The contracted development team was located in the Czech Republic. On this project, the GSD team used XP for the first time and encountered a considerable amount of requirements volatility. Not surprisingly, XP’s reliance on informal communication, as well as the use of an unfamiliar development methodology, presented challenges to the GSD team. The project was successfully completed and put into production after six months of development. The resulting software is currently being used by Tekelec’s customer service personnel to train new customers.
* Corresponding author: Tel: +1-919-513-5082 Email addresses: email@example.com (Lucas Layman), firstname.lastname@example.org (Laurie Williams), DanielaD@cs.uvic.ca (Daniela Damian), email@example.com (Hynek Bures) The goal of our industrial case study was to better understand how a globally-distributed team using Extreme Programming overcame the hurdles associated with global software development. We present a series of observations derived from both qualitative and quantitative data collected during the course of the project; this data collection was structured via the Extreme Programming Evaluation Framework (XP-EF) . Analysis was conducted of the team’s project artifacts, and interviews were conducted with the customer and project personnel.
We examined the communication practices the team adopted to create a communication-rich environment in which informal information flowed actively between all project stakeholders. Specifically, the team was able to establish close customer-developer interaction, to address linguistic and technical issues, and to develop a project in an unfamiliar problem domain. Four conjectures concerning the success factors for globally-distributed XP teams emerge from our study. We present conjectures, rather than results, that also serve as challenges for researchers to enhance the community’s understanding of the use of informal communication in GSD. Finally, we provide a corresponding list of recommended communication practices for global software development teams using XP.
The remainder of this paper is organized as follows: Section 2 describes related work, Section 3 outlines our research methodology, and Section 4 describes the software project in detail. Section 5 provides case study observations and conjectures as well as recommendations. Section 6 discusses the limitations of our study, and we conclude in Section 7.
2. Background and related work In this section, we provide a brief introduction to communications and requirements engineering practices in global software development. We also provide background information on XP and the results of studies of colocated XP teams.
2.1. Global software development and requirements engineering practices The processes of communication, coordination, and collaboration are at the heart of, and key enablers of, software development processes. Research continues to reveal the significant impact that distance has on project performance [13, 26]. Communication seems to be an essential component of all software development collaboration practices and processes. Besides formal project communication, empirical studies suggest that developers rely heavily on informal, ad hoc communication [12, 21, 32, 43]. Consequently, hurdles in communication will have dramatic effects in the success of GSD projects.
Besides differences in language and culture, GSD teams suffer from a lack of informal communication, resulting in low levels of trust and awareness of work and progress at remote sites. In GSD projects, managing cross-cultural issues is important. Strategies recommended in the literature include the use of cultural liaisons , bridgehead teams , straddlers (technical or managerial liaisons) , or rotation of management to cope with cultural diversity . With bridgehead teams, 75% of the personnel are located offshore while 25% onshore. The onshore personnel are more experienced and culturally assimilated. These individuals work to understand the customer’s requirements and translate them to the offshore programmers and to reduce miscommunication between customer and vendor . The development manager role, discussed in Section 5.2, acted a bridgehead.
One class of software development activities directly affected by challenges in communication is requirementsrelated activities, such as requirements definition and negotiation, design, and project management. Activities of requirements engineering are one of the major difficulties in multinational organizations . An in-depth field study of requirements engineering in a multinational organization  clearly identifies the multitude of factors impacting the effective management of requirements in GSD. The language barrier alone could be a significant problem in achieving shared understanding of the required functionality. Terms that convey different meaning in different organizational settings may be misinterpreted until late in the project with potentially damaging results.
For example, “overlooking the development of a feature” may mean overseeing its development or simply forgetting its development. Further, multicultural interaction between developers and clients together with time delays and the inability to maintain an awareness of working context at remote sites contribute to major challenges affecting the entire software development process. Failure to fully understand the required system features, reduced trust and the inability to effectively resolve conflicts result in budget and schedule overruns and, ultimately, in damaged clientsupplier relationships .
Offshore development is a particular case of GSD that is bound to suffer from these hurdles, given the reliance on geographically-distributed client-supplier relationships. As requirements management activities are primarily impacted by distance , GSD projects benefit from requirements specifications well-defined at the onset of the project , thus avoiding the need to reiterate feature understanding. This specification is often used in planning processes, important in the organization and managing of distributed projects . Frequent deliveries are also recommended as a successful GSD collaboration practice . Incremental integration and frequent deliveries are also recognized as powerful techniques for managing requirements creep , and are a core practice of agile methodologies for co-located projects . Though the study of agile practices in GSD has received little attention, there is some evidence that agile practices can be used in offshore development . In this paper we build upon these initial results.
2.2. Extreme Programming
The development team in our study followed the XP software development methodology. XP was designed for use with 10-12 co-located, object-oriented programmers . XP is an iterative development methodology with a short planning horizon (three month releases, 1-2 week iterations). In XP, a release corresponds to a stable, deliverable version of the product that can be used by customers. Iterations are shorter increments of development where individual tasks are assigned to developers and a working prototype of the system is evolved and periodically evaluated by project stakeholders. The XP practices do not include the preparation of extensive requirements or design documents prior to starting development. Consequently, XP is heavily reliant on continuous communication between stakeholders and tight feedback loops to clarify and specify feature implementation and to respond to change. This continuous communication can be a challenge for GSD teams and is the central theme in this paper.
In XP, functional requirements are captured as user stories. User stories are informal, natural language descriptions of system features that are written on an index card. Each user story is written by the customer, who is also responsible for stating the priority of the user story. The customer also provides a corresponding customer acceptance test (CAT) for each user story that, when passed, marks the completion of the user story. Since the initial user story often does not contain the specific details necessary for implementation, developers and customers have an on-going dialogue throughout the development process through which user stories are clarified and further refined. Through this on-going communication, the customer retains control over the product being developed.
2.3. Extreme Programming case studies
Practitioners and researchers have reported numerous, predominantly anecdotal, studies of XP. There is a lack of industrial case studies of XP in general, and of studies of XP in GSD in particular. However, some empiricallybased XP case studies do exist. Abrahamsson  conducted a controlled case study of four software engineers using XP to implement data management software. Comparison between the first and second releases of the project yielded increases in planning estimation accuracy and productivity while the defect rate remained constant.
Similarly, Maurer and Martel  reported a case study of a nine-programmer web application project. The team showed strong productivity gains after switching from a document-centric development process to XP.
The XP-EF  is a benchmark for expressing the context of XP case studies, the XP practices an organization has selected to adopt and/or modify, and the business-related results of this adoption. In the XP-EF, researchers and practitioners record essential context information of their project via the XP Context Factors (XP-cf). Recording context factors such as team size, project size, criticality, and staff experience can help explain differences in the results of applying the methodology. The second part of the XP-EF is the XP Adherence Metrics (XP-am). The XP-am use objective and subjective metrics to express concretely and comparatively the extent to which a team utilizes the XP practices. When researchers examine multiple XP-EF case studies, the XP-am also allow researchers to investigate the interactions and dependencies between the XP practices and the extent to which the practices can be separated or eliminated. Part three of the XP-EF is the XP Outcome Measures (XP-om), which enable one to assess the business-related results (productivity, quality, etc.) of using a full or partial set of XP practices.