How Extreme does Extreme Programming Have to be? Adapting Extreme Programming Practices to Large-scale Projects

Author(s): Lan Cao, Mohan, K., Peng Xu, Ramesh, B.
Venue: Proceedings of the 37th Annual Hawaii International Conference
Date: 5-8 Jan. 2004

Type of Experiement: Case Study
Sample Size: 22



How Extreme does Extreme Programming Have to be? Adapting Extreme Programming Practices to Large-scale Projects describes how a large software company called “FinApp” adopted extreme programming practices for a group of 22 developers. FinApp develops and maintains a complex enterprise system that provides financial services to banks, insurance companies, loaners, and brokerages. The project includes more than 1,000 business objects in six different categories, and is comprised of over 7,000 files.

The paper proposes a set of agile practices that have been tailored to be suitable for large-scale, complex projects, and compares these tailored practices with agile principles that were proposed in prior research. Instead of adopting the whole set of extreme programming practices, FinApp used a “modified extreme programming” approach. It combined the traditional process of upfront design with the extreme programming practices such as short release, pair programming, and refactoring.

Many extreme programming processes, however, were adapted only to a moderate degree. For example, FinApp could not access its real customer, so substituted in product managers instead. “Flexible” paired programming was implemented, where programmers were paired in analysis, design, and testing only. The combination of solo programming and pair programming was reported to overcome the shortfalls of pair programming such as developer resistance, however, while still benefiting from pairings where feasible. And, although not experimentally tested, according to a project manager, two developers working together on a project finished their tasks roughly 80% faster than if they were assigned separately.

Also, refactoring was used as a technique to enhance reuse, and as such was not adopted as originally described (simplifying code and/or increasing readability while maintaining all functionality). The authors claim that reuse in this manner does not conflict with the agile approach and should be included in agile principles for large-scale projects. Some extreme programming practices, like using a metaphor to describe the overall system, were not implemented at all.

Some more traditional software engineering methodologies were also employed along with extreme programming practices. In large project like FinApp, managers decided, development of upfront architectural design and use of design patterns was critical.

Overall, the authors suggest that even large-scale, complex projects can benefit from adapting extreme programming to suit to their environments. The authors report that extreme programming improves a software project in four essential ways: communication, simplicity, feedback, and “courage,” regardless of project size. And, although the methods employed by larger teams may need to deviate from varieties adapted by smaller- and medium-sized projects, even large projects can benefit from extreme programming practices. Creating a stable architectural design upfront, especially, is recognized as the striking difference between the agile practices for large-scale projects and smaller ones. The concept of programming patterns and up-front design, a layered deliverables approach, and pair programming, are seen as the most beneficial extreme programming practices that the company adopted.