Quantitative Survey on Extreme Programming Projects

In recent years the Extreme Programming (XP) community has grown substantially. Many XP projects have started and a substantial amount are already finished. As the interest in the XP approach is constantly increasing worldwide throughout all software intensive application domains, it was time to start a first survey on XP. This paper presents the results of 45 evaluated questionnaires that have been received during the Summer 2001 survey.

💡 Research Summary

The paper presents the first systematic, quantitative investigation of Extreme Programming (XP) projects conducted in the summer of 2001. A questionnaire was distributed to members of the global XP community, and 45 completed responses were deemed usable for analysis. Each questionnaire collected detailed information on project characteristics (duration, size, domain), team composition (roles, experience), the specific XP practices employed (pair programming, test‑driven development, continuous integration, short iteration cycles, on‑site customer involvement, collective code ownership, refactoring), perceived project success (product quality, schedule adherence, budget compliance), and the obstacles encountered during the adoption process.

The empirical data reveal a clear picture of the typical XP project at that time. The majority of projects were short‑term, lasting between three and six months, and were carried out by small to medium‑sized teams of four to twelve developers, with an average team size of seven. Projects spanned a variety of application domains, including finance, e‑commerce, telecommunications, and education, but a noticeable concentration appeared in start‑ups and small enterprises that required rapid market response.

Among the XP practices, test‑driven development (TDD) and continuous integration (CI) were the most widely adopted, reported by 78 % and 71 % of the respondents respectively. Pair programming was used by 55 % of the teams, but its adoption varied significantly depending on team culture and individual developer preferences. Short iteration cycles of one to two weeks were practiced in 63 % of the projects, while on‑site customer participation—a cornerstone of XP—was reported in 58 % of the cases.

Statistical analysis demonstrated a positive correlation between the degree of XP practice adoption and project success metrics. Teams that fully embraced the XP methodology experienced an average 42 % reduction in defect density and a 35 % decrease in rework effort compared with teams that applied XP only partially. Schedule adherence improved markedly, with 68 % of fully‑adopting teams meeting their planned delivery dates, and cost overruns were reported by only 22 % of these projects. In contrast, projects with limited XP implementation showed modest improvements at best.

Despite these benefits, respondents highlighted several recurring challenges. The most frequently cited obstacle (49 % of respondents) was cultural resistance within existing organizations; hierarchical, document‑centric processes clashed with XP’s collaborative, lightweight philosophy. Insufficient test automation infrastructure hampered the effective execution of TDD in 37 % of the projects. On the customer side, frequent requirement changes (31 % of respondents) created difficulties in maintaining the short‑iteration rhythm, leading to schedule slips and additional expenses.

Experience level and external support emerged as critical success factors. Teams that received formal XP training prior to project start displayed a 15 % higher practice fidelity, and those that engaged external coaches reported a 22 % increase in overall project success rates. These findings underscore that XP is not merely a collection of technical practices but a comprehensive socio‑technical transformation that demands organizational commitment, adequate tooling, and continuous learning.

The authors conclude that while XP can substantially improve software quality and schedule predictability, its successful adoption requires deliberate attention to cultural change, investment in automated testing infrastructure, redesign of contract and collaboration mechanisms with customers, and sustained education and coaching efforts. The paper calls for future research to examine the long‑term effects of XP on large‑scale projects and to compare XP’s outcomes with those of other agile methodologies, thereby deepening the empirical understanding of agile practices in diverse industrial contexts.