FREE ELECTRONIC LIBRARY - Thesis, documentation, books

Pages:   || 2 | 3 | 4 | 5 |

«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 ...»

-- [ Page 1 ] --

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 [47]. 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 [41], 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 [2]. 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 [10] methodologies.

Communication, particularly informal communication [24], 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) [7], a process that requires an informal, communication-rich environment in order to succeed. Communication is one of the five central values of XP [6] and many of the XP practices explicitly support this value [53]. 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: lmlayma2@ncsu.edu (Lucas Layman), williams@csc.ncsu.edu (Laurie Williams), DanielaD@cs.uvic.ca (Daniela Damian), hynek@radiante-corp.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) [52]. 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 [9], bridgehead teams [33], straddlers (technical or managerial liaisons) [22], or rotation of management to cope with cultural diversity [16]. 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 [9]. 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 [45]. An in-depth field study of requirements engineering in a multinational organization [14] 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 [14].

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 [14], GSD projects benefit from requirements specifications well-defined at the onset of the project [49], 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 [45]. Frequent deliveries are also recommended as a successful GSD collaboration practice [42]. Incremental integration and frequent deliveries are also recognized as powerful techniques for managing requirements creep [29], and are a core practice of agile methodologies for co-located projects [34]. 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 [18]. 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 [27]. 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 [1] 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 [38] 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 [52] 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.

Pages:   || 2 | 3 | 4 | 5 |

Similar works:

«TS 101 346 V6.1.0 (1998-07) Technical Specification Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS); Serving GPRS Support Node (SGSN) Visitors Location Register (VLR); Gs interface layer 3 specification (GSM 09.18 version 6.1.0 Release 1997) R GLOBAL SYSTEM FOR MOBILE COMMUNICATIONS GSM 09.18 version 6.1.0 Release 1997 2 TS 101 346 V6.1.0 (1998-07) Reference DTS/SMG-030918Q6 (cgo030c3.PDF) Keywords Digital cellular telecommunications system, Global...»

«Ind AS pocket guide 2015 Concepts and principles of Ind AS in a nutshell 2 PwC Introduction This pocket guide provides a brief summary of the recognition, measurement, presentation and disclosure requirements under the Indian Accounting Standards (referred to as Ind AS or Standards in the guide) prescribed under section 133 of the Companies Act, 2013, as notified under the Companies (Indian Accounting Standard) Rules, 2015, in a simple and concise manner. It aims to present the fundamental...»

«ETSI TS 123 272 V9.7.0 (2011-03) Technical Specification Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; Circuit Switched (CS) fallback in Evolved Packet System (EPS); Stage 2 (3GPP TS 23.272 version 9.7.0 Release 9) 3GPP TS 23.272 version 9.7.0 Release 9 1 ETSI TS 123 272 V9.7.0 (2011-03) Reference RTS/TSGS-0223272v970 Keywords GSM, LTE, UMTS ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex FRANCE Tel.: +33 4 92 94 42 00...»

«Ubiquitous Intelligence in Agent Mining Longbing Cao, Dan Luo, and Chengqi Zhang Faculty of Engineering and Information Technology, University of Technology Sydney, Australia {lbcao,dluo}@it.uts.edu.au Abstract. Agent mining, namely the interaction and integration of multi-agent and data mining, has emerged as a very promising research area. While many mutual issues exist in both multi-agent and data mining areas, most of them can be described in terms of or related to ubiquitous intelligence....»

«Czech Technical University in Prague Faculty of Electrical Engineering Doctoral Thesis July 2013 Ing. et ing. Petr Buryan Czech Technical University in Prague Faculty of Electrical Engineering Department of Cybernetics Refinement Action-Based Framework For Utilization Of Softcomputing In Inductive Learning Doctoral Thesis Ing. et ing. Petr Buryan Prague, July 2013 Ph.D. Programme: Electrical Engineering and Information Technology Branch of study: Artificial Intelligence and Biocybernetics...»

«Supporting children when a baby has died First edition © Sands 2013 No part of this booklet may be reproduced in whole or part, in any form or by any electronic or mechanical means without the prior written permission of Sands. All rights reserved. Whilst every care is taken in providing information, please note that it is of a general nature and that readers should seek professional or expert advice as appropriate to their specific circumstance. Sands does not accept any liability, including...»

«Bystander Beware By A Bystander August 2015 Bullying poses a major challenge for universities and the broader community in Australia and elsewhere. One of the most vexing issues facing the management of bullying stems from the potential nexus between the university and the line managers appointed by the university. The following analysis revealed four weak points in the detection, recording and management of bullying in the tertiary sector. The first of these involved the possible benefit of...»

«Foundations of Physics, Vol. 35, No. 2, February 2005 (© 2005) DOI: 10.1007/s10701-004-1941-6 On Zurek’s Derivation of the Born Rule Maximilian Schlosshauer1,3 and Arthur Fine2 Received August 23, 2004 Recently, W. H. Zurek presented a novel derivation of the Born rule based on a mechanism termed environment-assisted invariance, or “envariance” [W. H. Zurek, Phys. Rev. Lett. 90(2), 120404 (2003)]. We review this approach and identify fundamental assumptions that have implicitly entered...»

«The Photogrammetric Record 20(109): 48–68 (March 2005) PHOTOGRAMMETRY AND 3D LASER SCANNING AS SPATIAL DATA CAPTURE TECHNIQUES FOR A NATIONAL CRANIOFACIAL DATABASE Zulkepli Majid (zulkepli@fksg.utm.my) Universiti Teknologi Malaysia Albert K. Chong (chonga@albers.otago.ac.nz) University of Otago, New Zealand Anuar Ahmad (anuar@fksg.utm.my) Halim Setan (halim@fksg.utm.my) Universiti Teknologi Malaysia Abdul Rani Samsudin (dental@kb.usm.my) Universiti Sains Malaysia Abstract Photogrammetry is a...»

«® International Color Consortium ® White Paper 40 Level: Intermediate Black-point compensation: theory and application Black Point Compensation (BPC) is a technique commonly used in color-managed workflows based on ICC profiles. This paper provides a general explanation of the BPC concept and its use in ICC systems. The paper begins, in Sections 1 and 2, with a description of the context in which BPC first appeared — in particular, the provision of multiple Rendering Intents in the ICC...»

«SAS Global Forum 2007 Coders’ Corner Paper 062-2007 Simple Rules to Remember When Working with Indexes Kirk Paul Lafler, Software Intelligence Corporation, Spring Valley, CA Abstract SAS users are always interested in learning techniques related to improving data access. One way of improving information retrieval from a SAS data set or table is to create and use an index. An index consists of one or more columns that are used to uniquely identify each row within a table. Functioning as a SAS...»

«Opinion Mining in Conversational Content within Web Discussions and Commentaries Kristína Machová1 and Lukáš Marhefka1, Dept. of Cybernetics and Artificial Intelligence, Technical University, Letná 9, 042 00, Košice, Slovakia, kristina.machova@tuke.sk, lukas.marhefka@student.tuke.sk Abstract. The paper focuses on the problem of opinion classification related to web discussions and commentaries. It introduces various approaches known in this field. It also describes novelty methods, which...»

<<  HOME   |    CONTACTS
2016 www.thesis.xlibx.info - Thesis, documentation, books

Materials of this site are available for review, all rights belong to their respective owners.
If you do not agree with the fact that your material is placed on this site, please, email us, we will within 1-2 business days delete him.