Optimizing extreme programming

The vast amount of published literature explaining the ldquoright wayrdquo of doing Extreme Programming (XP) shows that in practice, there simply is no single right way. Even though XP is a simple and slim process, it has to be tailored to the nature of each team and project in order to provide the benefits it promises. Our team has been working on a project employing the XP methodology, experiencing unique issues arising from the distinct project setup and team composition, as well as the additional academic interests in the project. Initially, we aimed at applying "pure XP", but it became more and more obvious that for our project some of the practices just cannot be applied in their "pure" form. The concrete interpretation of these practices determines if XP can be applied successfully in the context of a team and a project. In order to reach an optimized process for our project, we continuously evaluate different approaches of applying XP practices on short release basis. We have noticed that some practices can be adopted directly while others need to be tailored according to the unique environment. In this paper we reflect on our process based on the data collected through code analysis and process evaluation tools, as well as notes of process retrospective review meetings. The lessons we have learned can also help other teams to lead them to an optimized XP process for the success of their projects.