Exploring Extreme Programming in Context: An Industrial Case Study

Author(s): Lynn Cunningham, Lucas Layman, Laurie Williams
Venue: Dept. of Comput. Sci., North Carolina State Univ., Raleigh, NC, USA. Agile Development Conference, Pages 32- 41.
Date: 2004

Type of Experiement: Case Study
Sample Size: 10

Quality
3

Reference: http://mythic.lib.calpoly.edu:2388/iel5/9399/29819/01359793.pdf?tp=&arnu...

SUMMARY
Exploring Extreme Programming in Context: An Industrial Case Study describes a longitudinal case study that analyzes the effects of using extreme programming for building commercial software at Sabre Airline Solutions™ in the United States. The study compares two releases of the same product: one release completed using a traditional waterfall process, and the other, 2 years later, using extreme programming methodologies.
The paper provides quantitative output measurements of productivity and quality, as well as qualitative information gathered from team member semi-structured interviews (an interview with a mixture of open-ended and specific questions designed to elicit unexpected types of information), and statistical analyses done on company historical data. The paper also employs the Extreme Programming Evaluation Framework (XP-EF), an ontology-based benchmark for expressing case study information, for evaluating the effects of extreme programming on the project.

Some extreme programming practices such as continuous integration and collective code ownership were already a part of the team’s waterfall process while, for example, paired programming took the place of code reviews in the new release. If programmers were not paired, it was common to ask a colleague for a peer review. Even so, paired programming was a source of debate, as developers disliked mandated pairings, but found it helpful when difficult problems needed solving. And, although most processes were integrated completely, some were only able to be integrated within limits. For example, the marketing representative served as the on-site customer (available for half of the time) and was available through phone and e-mail the rest of the time. Testing GUI components was also found to be quite difficult because of limitations in available unit testing technology.

The project was described as being a good candidate for fully adopting extreme programming from the start because it was “characteristically agile.” Unfortunately, many of the objective metrics in this study could not be gathered since most of the metric information was from historical data. For those metrics that could not be calculated, team leaders who were present for both releases were interviewed. Regardless, all team members reported hat communication among the team increased using extreme programming, which allowed problems to be solved more quickly, and all developers benefited from increased customer feedback.

Comparisons of the new release project results to the old release project results show a 50% increase in programmer productivity, a 65% improvement in pre-release quality, and a 35% improvement in post-release quality. In fact, Severity 1 defects (those defects causing the system to become unusable when a user encounters them) were reduced from 12% using the waterfall model, to 0% using extreme programming. All these findings suggest that, over time, adopting the extreme programming process can result in increased productivity of programmers and quality of code. The perceived success of this and the other early extreme programming projects in the company led to extreme programming adoption in over 30 teams with more than 200 people throughout Sabre Airline Solutions.

0