Ongoing quality improvement, or: how we all learned to trust XP

Author(s): Striebeck, M.
Venue: Agile Conference 2005
Date: 24-29 July 2005

Type of Experiement: Other
Class/Experience Level: Professional

Quality
3

Reference: http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1609831

SUMMARY:

Six months into rewriting its flagship product, VA Software realized that the traditional waterfall model would not work for the project. The product managers were continuously making changes about which features to include or upgrade from the legacy product, and the team needed a more agile process to react to the changing requirements. Two project managers researched extreme programming and decided to apply it to the product.

Initially, the QA team was skeptical of the new process, and insisted on performing a full QA run after the first release of the product; the significantly lowered bug count and ease of integration convinced the QA team to fully participate in the extreme programming process. This included attending planning meetings so that acceptance test scripts could be written before the development was completed. One point of note is that this paper suggests that the team adopted an iterative-test-last process instead of test-driven development as mandated by extreme programming; tests suites were created an run continuously, both on a CruiseControl server and a Tinderbox server.

The team saw development time decrease, while code quality increased. The last reported release of the product came in under budget by three calendar days. Quality was measured in number of bugs found per release; since switching to extreme programming practices, the product has experienced an 80% reduction in the number of bugs per man-weeks of product development.

0