«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 ...»
When asked how the customer felt about the capabilities of the product (in terms of features and functionality), the customer was neutral on the subject. The simulator did not cover all the desired aspects of the real system. Due to the immovable deadline on the project, the functionality of the tool was intentionally reduced so that the project could be delivered on time. The productivity of the project was lower than published standards . The results of this comparison may be influenced by the team’s use of a 4th generation programming language as well as extensive unit testing by the developers. When the test code created by the team is included in productivity calculations, the productivity is on par with published standards. We acknowledge that KLOC-based measures of productivity are oftentimes inaccurate and unreliable, but we include them in this study for comparison purposes. The user stories/PM metric (a measure of how many features delivered) and the Putnam Productivity Parameter (a LOCbased metric that controls for project size and duration) can also help understand the team’s productivity. The customer felt the project progressed very well in such a short amount of time. The customer also stated that the end users of the simulator “enjoyed the product.” The quality and productivity (including test code) indicate that this project was on par or better than published standards.
5. Conjectures and recommendations
In this section, we present four conjectures on the enabling communication factors that created a communicationrich environment needed for a successful XP project despite geographical, temporal, and linguistic hurdles. We do not focus on the individual practices of XP and how they were used in this particular project. These conjectures serve as an initial basis for understanding the challenges facing XP GSD teams and are based on grounded theory observations. We base these conjectures on the data that we have collected in our case study as well as our own rationale, but they will bear further substantiation. When writing the conjectures, there are three parts that we address: the conjecture statement; an explanation of the statement with supporting evidence and references to related research results available in the literature; and a recommendation for other distributed teams who wish to use a communication-centric process.
5.1. A definitive customer role for requirements management activities Conjecture 1: In a globally-distributed XP team, a well-defined customer authority is essential for effective decision making and a clear requirements statement.
In XP methodologies, the customer role is particularly important for requirements management activities. The “on-site customer” practice of XP states than an active customer should be continuously available, physically present (ideally) with the developers to answer developer questions, to make planning decisions, and to provide customer acceptance test cases (CATs). This need for customer contact is compounded by the fact that the development team was working in a new problem domain, a situation typical in GSD . Furthermore, requirements management activities are primarily impacted by distance [14, 45]. Thus, as discussed in this section, the customer role becomes essential for effective requirements management in a distributed XP project to succeed.
The customer role and its associated responsibilities proved to be initially the greatest source of difficulty with the new software process. The development manager, project manager, and development lead all pointed out that the customer role was ill-defined for the first month of the six month development effort. Project management personnel were providing the developers with high-level goals, but there was no external customer with a defined purpose and usage for the system being built. The ill-defined requirements were also influenced by the team’s firsttime use of the XP process and unfamiliarity with how to write effective user stories. The following example user
story from early in the project that illustrates the high-level and poorly-scoped nature of the user stories:
The simulator must recognize every command specified in the Eagle 31.0 command handbook, and be able to distinguish between mandatory and optional arguments. An appropriate rejection message shall be printed if the command syntax is incorrect.
Initially, the F-15 project was to be a simulator for the entire signaling system, a “grandiose” goal according to the project tracker. There was no clear purpose of the usage of the system. From a requirements standpoint, this made it difficult to identify necessary, concrete features for final system implementation. Both the development lead and one of the proxy customers pointed out that the lack of upfront defined project scope caused problems.
While user stories are high level and written in natural language, they must contain enough information to provide some bounds of the feature’s scope so that the user story can be broken down into readily-identifiable, concrete tasks during the iteration planning meeting . However, user stories with high-level goals but ill-defined features pervaded the early stages of development. Furthermore, XP requires customers to provide CATs up-front to validate the user stories and guide development. Yet, during the first month of development, neither clear user stories nor CATs were provided. One of the proxy customers noted that the project being developed was not a usable application, so there was little interest in writing acceptance tests. The initial requirements difficulties experienced by the team were a result of unfamiliarity with the XP process. The distribution of the project management and development teams compounded this problem, since the developers did not have easy access to a readily-identifiable resource who could resolve any outstanding technical issues.
After this initial troublesome month, a new stakeholder joined the team as the project’s customer. The customer had a strong interest in creating the system for a particular purpose. At this point, the goal of the project became to create a simulator that would be used to teach a class on using the signaling system. This also placed an immovable delivery deadline on the project. A clear goal now enabled the creation of well-scoped and concise user stories based upon consultation with a highly-motivated customer and upon the course description available in training materials. The project manager noted that the team’s project’s lack of focus improved greatly with the new
customer involved. The language of the user stories also became more specific:
The instructor shall be able to cause SLTC failure on link. The SLTC failure shall be reported every 30 seconds. REPT-STAT-CARD shall show loopback.
The customer remarked that he began receiving prototypes two months into the project and ran tests against them to give feedback to the developers. As the project progressed, CATs became more commonplace. The customer and proxy customer also wrote scripts to test system features. Furthermore, the developers now had an identifiable person who could answer their questions about user story details and implementation specifics. When the customer was unavailable for these questions (due to travel or other commitments), the proxy customers could make decisions with the aid of the training course documentation.
The problems experienced by the F-15 were largely the result of adopting a new software process that was unfamiliar to all parties involved. Similar difficulties with the customer role have been observed in other XP studies of co-located teams [35, 36]. However, research has shown that distance impacts requirements management activities [14, 45], thus making the customer role in a GSD XP an even more critical component to project success.
The impact of the customer role was greatly increased in this project since the team was working in an unfamiliar problem domain, a situation typical of GSD teams . A new problem domain increases the need for active customer involvement as the customer not only has to provide requirements, but may have to spend a significant amount of additional time clarifying technical aspects of the problem.
Recommendation: Define a person to play the role of the customer up front. This individual must be able to make conclusive decisions on project functionality and scope, must be readily accessible, and must have a vested interest in the project.
The contrast between initial difficulties followed by concrete progress solidified the need for a definite customer.
A definite customer helps to settle the difficulties of requirements management that are amplified in a globallydistributed project and provides the developers with an identifiable resource to answer questions about features and project scope. This recommendation is similar to what XP requires of all its teams, yet other studies have shown that XP teams can be successful without consistent customer involvement  . We believe that active, consistent customer involvement is essential for the success of an XP GSD and cannot be overlooked.
5.2. Bridgehead Conjecture 2: In a globally-distributed XP team, having a key member of one team physically located with the other team can provide an essential two-way communication conduit.
The notion of an individual used to bridge technical, linguistic, and managerial gaps between GSD teams is not novel [9, 22]. However, this person’s role is essential when communication between sites is required on a daily basis. In XP, communication between developer and customer is so critical that the use of an “on-site” customer, physically located with the development team, is recommended . In this section, we discuss the development manager, the technical lead on the project who worked closely with both developers and project management personnel. In many ways, he was considered an “on-site customer” for the developers (with regards to technical issues) and an “on-site developer” for the project management personnel.
The development manager had been working with Tekelec for five years. During this time, he founded Radiante in the Czech Republic, which he also managed. He had been personally familiar with all of the developers involved in the project since 2002, with the exception of the development lead who he had known for many years prior to that. The time spent at Tekelec allowed the development manager to become familiar with the company, its technologies, and its needs. Consequently, he had a solid understanding of the system being built, far more so than the remote developers. Furthermore, his close ties with the developers allowed him to informally communicate
many technical issues to the development team. According to the customer:
… [the development manager] had a really strong grasp of what [we] wanted. And he was able to effectively convey that to the developers.
The development manager played an essential role as a technical and cultural liaison between the development team and the project management personnel. The language barrier presented challenges early in project development. The developers and the development manager spoke English as a second language. None of the project management personnel (other than the development manager) spoke Czech. This language barrier resulted in some difficulties in understanding the technical aspects of the signaling system that the F-15 project would simulate. Since the F-15 developers had no prior knowledge of the signaling system, they had to learn many proprietary technical terms that were difficult to communicate by the project management team. This unfamiliarity with the technical language associated with the signaling system created a learning curve for the developers that made it difficult to understand feature requests early in the lifecycle.
For the developers, the development manager served as a technical liaison for the project management team who could answer technical questions and provide feature details quickly. For the project management team, he represented the developers and intimately understood the status and progress of the project. In many ways, the development manager was the most essential communication conduit, more so than the weekly phone calls and daily email messages. With a thorough understanding of both development and project management needs, he was able to guide the project efficiently. With an identifiable reference for both development and project management personnel to refer to, he significantly narrowed the communication gap caused by technical, distance, and language barriers. These observations of the essential role of the development manager corroborates the existing evidence on the role of “expert designer” in software development  as well as of the cultural and technical liaison in global software projects [9, 33]. However, there is risk associated with a project that becomes overly dependent upon any small number of individuals .
Recommendation: When the project management and development teams are separated, create a role within the XP team whose purpose is to work closely with both development and project management teams on a daily basis, preferably someone who speaks all languages involved.
It is necessary to establish an individual (or possibly a group of individuals) within the team who will straddle both the development and project management realms. This individual is responsible for playing several key roles that emerged as essential in the success of our case study. Ideally, this person is located that group that is not his original organization.
5.3. Short, asynchronous communication loops
Conjecture 3: In a globally-distributed XP team, prompt responses to asynchronous queries positively impact development commitment and confidence and create a focused development environment.