Process Mixtures

XP + Evo

XP values and spirit regarding specifications is not compatible with Evo. XP's value of avoiding written or precise requirements, and preferring oral communication between developers and requirement donors is very different than Evo's emphasis that when a specification is required, it be done so with clarity and measurable qualities.

Evo

Evo specifications

On the other hand, many XP development practices may be consistently applied with Evo, such as test-driven development, pair programming, and so forth.

XP's client-driven adaptive planning is also consistent with Evo. The XP stand-up meeting, common project room, and whole team together supports Evo's feedback goals.

adaptive planning

XP's 1 3 week iteration length is relatively consistent with Evo, which prefers 1 2 week iterations.

XP + Scrum

Most Scrum practices are compatible with XP. The Scrum meeting is a refinement of the XP stand-up meeting (in fact, Beck got the idea from Scrum), using special questions. Both recommend a common project room. The Scrum practice of a demo to external stakeholders at the end of each iteration enhances XP's feedback and communication goals. The Scrum Backlog and progress tracking approaches are minor variations of XP practices.

Scrum

Scrum meeting

Scrum's 30-day iteration length is not consistent with XP too long.

A Scrum practice is to have only one customer representative, the Product Owner, who is ultimately responsible for the requirements and priorities. But in recent updates to XP, there is an emphasis on collaborating with a group of customers avoiding just a single person. It is nice to have a single customer voice, and it is useful to know and resolve multiple people's goals. XP and Scrum tackle this tension differently, shifting whether development or business is responsible for resolving the conflict.

Mike Beedle, one of the early Scrum practitioners, has explored combinations of XP and Scrum under the name "XBreed."

see www.xbreed.net

XP + UP

Most XP practices are either equal to or specializations of UP practices, and many XP practices can be applied in the context of an overarching UP project. For example, test-first development is a specialization of the UP continuously verify quality best practice. The UP does not require or promote unnecessary document creation all artifacts are optional and so it is a misunderstanding to assume the methods are fundamentally incompatible. Although speaking of some XP within UP can have conceptual integrity, the opposite is not true, as there are some differences in style and emphasis.

UP

UP practices

One area of difference is in the accepted degree of up-front modeling (diagramming, etc.). For example, within a UP project and a two-week iteration, it is considered acceptable to spend a half-day near the start to consider design ideas "at the whiteboard" before programming. In XP, no more than 10 or 20 minutes before programming is considered suitable.

Another difference is in the goal of the early iterations. In the UP the goal is to identify and drive down the high risks: technical, political, satisfying the customer, and so forth. Although this may happen in the XP, it is not an explicit guiding principle.

A third difference is in requirements specifications. The UP allows and supports the creation of relatively detailed specifications (evolutionarily, over a series of iterations), assuming that an onsite customer is not going to be present. These will usually take the form of use cases and an associated nonfunctional specifications document, created in a series of timeboxed requirements workshops. The idea in the UP is, during the early programming iterations, to have a parallel track of requirements analysis where the majority of requirements are being written, while the development team is also programming something critical. The programming work is meant, in part, to help clarify the requirements work.

XP stories are normally features, rather than use cases. Thus, XP promotes a feature-driven approach to requirements. On the other hand, the UP promotes a use-case-driven approach, although the UP accepts and allows features rather than use cases.