XP is typically seen as the antithesis to high-ceremony methodologies (i.e., prescriptive software processes that demand large amounts of paperwork and many hoops to jump through before any code gets written). The problems with such methodologies include the following:
There are often too many hoops to jump through before any code gets written. Having a few hoops (e.g., defining the requirements) is good and is commonly known as looking before you leap. Some types of project do benefit from these additional stages, though (e.g., life-critical systems, space shuttle navigation systems, payroll systems).
Much time is often wasted on creating documents that nobody ever reads.
Excessive documentation is more likely to result in out-of-date documents.
All projects are not the same. One methodology just can t fit all possible project types.
That last problem is also true of XP, of course. For example, XP is best suited to small-scale projects of up to 12 programmers. As soon as you have too many programmers to fit into one room, you ll need to add some additional layers of process to assist in communication between teams . At this point, the methodology essentially ceases to be XP.
We explore the problem of squeezing too many programmers into one room in Chapter 14.