Instead, XP views refactoring as an ongoing and healthy aspect of software development. XP takes a practical approach to software refactoring, expressing a view of “"when the code smells, fix it." This may mean identifying and repairing a software defect. Or it may mean that 20% into a task a developer has realized that a high level architecture or design can be built or "realized" by two different implementations. By re-doing the 20%, the task will be completed faster and with an overall increase in quality of the final product. XP’s design strategy resembles a hill-climbing algorithm (Beck). You get a simple design, then you make it a little more complex, then a little simpler, then a little more complex. The problem with the hill-climbing algorithm is reaching local optima, where no small change can improve the situation, but a large change could (RUP).
XP's focus on small or short-duration releases makes it more difficult to manage large and complex projects. The rate at which a customer can accept and deploy new releases will depend on many factors, typically including the size of the system, which is usually correlated with business impact (RUP). A two-month cycle may be far too short for some types of system; the logistics of deployment may prohibit it (RUP). The PMBOK and RUP are often at odds with XP’s feverish pace.
There is clearly a degree of conflict and redundancy between XP and the PMBOK. This is not a straight forward process stack. There are a number of approaches to make the combination successful. One approach is to vary the stack over the duration of the project. In other words, some parts of the project might be governed more heavily by the PMBOK and other parts by XP. In terms of over-all involvement, the project manager may be heavily involved in project initiation activities as one would expect under the PMBOK. In development iterations or “sprints” the process may shift towards XP, and the project manager may check with the development team periodically, perhaps every 2 to 4 weeks.
A project manager can also leverage XP’s note card based process. The use of note cards is a core XP practice and is in part intended to create an "aha moment.” A deck of note cards is created, and each card lists a specific task and its estimated duration. The note cards are then presented to the stakeholders like a deck of cards. If there is agreement that each card needs to be completed, but the sum of the estimated durations exceed capacity, then there is clearly a problem. If time and budget are constrained and the parties decide to negotiate scope, it is easy to add and remove cards, and re-arrange the sequence to produce the desired outcome. Once this exercise is complete, it is then a relatively simple task to convert the note cards into a network diagram, identify dates and the critical path, and manage the execution of the project. This approach should be encouraged. Note cards are tangible and may be more palatable to both developers and stakeholders. It is also easier for team members to participate; shuffling around cards is easier than formally reviewing and amending a network diagram.
Another XP best practice is to normalize estimates vs. actuals after a sequence of development activities. Even if the estimates were not produced by a formal process such as PERT and the numbers are inaccurate, normalizing the estimates over the course of a few iterations will produce reasonably accurate numbers. It is trial by error so it may be slow, but by