What to Do Next

From our experience on this development project, we do not mean to imply that XP fails to work for large and complex application development. Instead, we only point out that many of the basic practices of XP are quite useful in such projects, but they need to be supplemented with some "heavier" methodology to work well. A list of story cards, if it becomes too large and complicated, needs to be supplemented with a holistic "picture" to ensure that the cards are managed, updated, and ordered well. More importantly, you must carefully watch the dependencies among stories as the list and complexity of story cards grow. Metaphors can go so far, but the complexity they can communicate is limited. A "customer," if it has many facets, needs someone to facilitate communication among the camps, manage the reconciliation of incompatible voices, and provide business expertise from a global perspective. All these examples point to the fact that you should be prepared for reduced "agility" from XP, as well as unforeseen challenges, when it is implemented for particularly complex or large application development.

But our experience also speaks to the issue I raised at the outset of this chapter: Is there a place for analysis in XP? From the experiences I have recounted here, it should be apparent that our use of XP on a large and complex development project forced us to institute roles and procedures that are not clearly envisioned in the common list of XP practices and roles. Thus, it made sense for us to include a team of traditional analysts in this project to fill these and other related roles. Of particular importance in this case was the complexity of the business logic in this particular application. The customer's team on this project provided considerable guidance in defining what was built, but they needed assistance from business experts with a broader perspective and from traditional software analysts to articulate clearly and completely in a set of functional tests what the system needed to do.

To help avoid disagreements with our diverse customer and to articulate more completely the dependencies among parts described in story cards, we needed to produce more traditional artifacts in addition to the story cards and functional tests. For each story card, we developed a separate, more detailed description of the functionality involved, its business purpose, its impact on other parts of the application already developed, and any additional specifics needed to direct the developers. This document was accessible online to all parties involved and often helped resolve misunderstandings or uncertainties that could not be determined by examining the story card by itself. Were we to initiate a similar project of this size in the future, I suspect we would devote even more manpower to the production of more traditional artifacts of analysis so that the XP practices we found productive could be employed once again successfully at this scale.