Part IV reports on a series of experiences in applying XP. The goal is to guide future applications of XP by showing what went well and what did not work. This is a first step toward establishing a body of knowledge about XP in which different experiences can be classified and compared. To ease the comparison, the authors have been required to follow a fixed set of headings as follows: Research hypotheses, in which the goals of the trial of XP are described Description of the context of the experience, detailing the environment where XP (or a portion of it) was tried Results from the experience, with numeric quantification of the outcome, whenever possible What actions were taken as a result of the experience We have also encouraged the authors to follow a rigorous and factual style in reporting their XP experiences. A comparison with what happens in medical studies may help in understanding the purpose and the scope of our work. Usually, a drug becomes available for general use at the end of a four-phase process. We think that a similar approach would benefit software engineering in general and especially XP. These are the four phases. Phase 1 The drug is tested to determine whether it is harmful; in our case, we would like to know if a given methodology would be extremely harmful for an organization to try. We think that in XP we have already completed this phase. Phase 2 The drug is administered to volunteers to determine whether it has the beneficial effects it claims to have. We are at exactly this step in XP. We are "administering" the XP practices to the "volunteer" organizations that think that XP would benefit them. Phase 3 The drug is tested on a large scale, to perform a general, unbiased evaluation of its effects. Phase 4 The drug is released for general use but still under scrutiny for possible unexpected results and contraindications. However, the first trials of novel techniques are usually performed by those adept at such techniques, those who have a direct interest in showing that the tried technique does indeed work. Remember, we are in phase 2 of our experimental study. Therefore, the language is often emphatic, and the reporters are clearly biased toward XP. This does not limit the validity of the study, because some of the results are definitely positive, while others require more careful investigation, and a few denote a negative impact, especially in the managerial aspects. Table IV.1 summarizes the results. Taking the same experimental approach as with medical studies, we think that now is the time to move in two directions. Extend these phase 2 experimentations, to broaden the scope in situations where people are not sure how to apply XP, such as with large or geographically dispersed teams. Initiate phase 3 experimentations that is, systematically apply the XP approach to cases where it appears it would be useful. Table IV.1. Results of Real-Life Experiences with XP | Chapter | Authors | Hypotheses | Context | Results | | 30 | Hodgetts and Phillips | XP increases the rate of development. XP reduces development costs. XP increases the correlation of software to business needs. XP reduces the release cycle. XP increases the product quality. | Internet start-up; typical enterprise technology, including ASP, J2EE, relational db. | All hypotheses have been verified. | | 31 | Kini and Collins | XP works well in general. XP is easily accepted by the customer. Some practices have worth when requirements or conditions change. Most practices are not difficult to implement. | XP-based company, with specific hardware and infrastructures for XP. Four developers and one tester. | All hypotheses have been verified; areas of improvement include a formalization of the in-house XP process. | | 32 | Schalliol | The story cards and the resulting code are a sufficient guide for the project. Dividing application functionality into story cards is learned once and then reapplied for all subsequent iterations. It is easy to identify the single customer who drives the planning game for the XP process. Such a customer can drive the planning game and is the primary author of all functional tests. | J2EE development project that switched to XP halfway through its three-year life. Fifty-person team: about 30 developers, eight quality assurance testers, and eight analysts. Overall, about 500,000 lines of executable code. | Each hypothesis raises some concerns. There is a lack of the "big picture," perhaps because of the size of the project. It is not always true, because sometimes the division is not "obvious." The large size of the application would require more than one customer in charge of leading the project. The customer often was uneasy in defining the acceptance tests. There were also aspects in which XP worked really well. | | 33 | Elssamadisy | XP provides customers with positive feedback via quick releases. XP "manages expectations" more easily because of constant customer involvement. XP results in a better-quality product, delivered on time to customers. XP eliminates integration problems caused by the presence of several subteams. | Large distributed leasing application; typically about 25 developers, ten business analysts, ten quality assurance people. About 600,000 lines of executable code in 6,500 classes. | All the hypotheses have been verified. In large teams, though, there are problems in meeting, applying pair programming, staying within the 40 hours a week, and defining suitable metaphors. | | 34 | Griffin | XP makes the development team more responsive to business needs. XP increases the speed of releases and reduces the error rate. XP improves the development cycle flow. | Provision of secure transaction settlement services for business and consumer e-commerce sites. Multitier architecture with ASP, Java/EJB, Oracle db, and XML. | All the hypotheses have been verified. However, the company was not happy with the "performance" of the XP team no overtime, no stress, and so on. Therefore, the team was dismissed at the end of the project. | | 35 | Johansen, Stauffer, and Turner | Adhering to the principles of XP would help overcome the major deficiencies usually encountered on "regular" projects. XP creates a stronger team and an experience that is remembered with pleasure. | Small software development company. Eight-month, six-developer project, delivering a major upgrade to an enterprise software system. | All the hypotheses have been verified in general. However, the management and one of the developers felt that working more would have helped the project to deliver more. | | 36 | Gittins, Hope, and Williams | The incremental addition of XP practices provides significant benefits to the overall development process. There are difficulties of various kinds, which can be discovered using qualitative statistical methods. | Medium-sized software company committed to implementing XP. | Both hypotheses have been verified, with a careful analysis of the outcome of each XP practice. | |
