Extreme Programming Perspectives

Established or "traditional" companies that are considering adopting XP have many more difficulties to overcome than younger, developing companies such as ST. Traditional development teams, in which developers are comfortably established, working in small offices in prohibitively cloistered environments coincide with management dilemmas. Such dilemmas include legacy software "owned" (ransomed) by one or two heroic developers at the cutting edge of their business. Other companies monitored by the researchers reported having some badly underperforming teams, and in some circumstances management resorted to consultants to resolve their problems, with no significant success reported.

Often with great reluctance, brought about by the constrictions of a traditional system, management allowed our research team to visit their developer offices. Stress levels were high in these companies. Common problems, described earlier for traditional companies, created high risks [Beck2000], quality was compromised, communication difficult, and control largely ineffective. The message here, to companies considering the change to XP, is that starting from scratch is easier than trying to introduce XP practices into an established company with many legacy problems. The ST developer manager reinforces this point, during their early attempts at developing XP projects, with his comment:

One of the key "discoveries" has been the relative ease to which XP has been employed on an all-new project, and the difficulty in applying XP retrospectively on an established system.

In summary, a combination of qualitative and quantitative methods has helped identify uncertainties in applying XP practices in a medium-sized software development company in particular, how one company interpreted and developed their own brand of XP, molded from their experiences, both successes and failures. Successes came from such areas as the use and development of spike solutions and finding ways to have a customer presence within the planning game activity. And failures were seen in developer reluctance to buy in to collective code ownership, and the difficulties of implementing a test-first strategy and adopting the practice of simple design. Partial success was seen in pair programming that posed early problems and then showed improvement in maturity, but of course the evolution of XP continues.

Clearly, the efficiency of XP applied within small and growing companies requires further investigation. XP practices support one another, and many complex interrelated human factors form part of an ever-changing scenario, all of which should somehow be considered in any evaluation process. Qualitative research techniques have helped us gather important data in this area. There are other problems, such as how XP practices relate to one another. It may not be enough to report the results of individual practices in isolation. Data analysis presents many challenges, and the investigation of software metrics, qualitative methods, and soft computing techniques have a practical working value that merits further work. Investigation into the use of soft computing techniques, particularly fuzzy logic, has already begun, attempting to provide richer results through improved analysis of both qualitative and quantitative data. We hope that by continuing this work, we will soon be able to provide some of the answers.