Scrum vs Extreme Programming: process or practices?

If you ask what Scrum says about unit tests, the honest answer is nothing. The Guide says Developers instil quality by adhering to a Definition of Done, and leaves what that contains to the team. That is not a flaw. It is a boundary. Scrum is a framework for working together, and software craft is somebody else's job. Extreme Programming, usually called XP, is where a lot of that craft was written down.

What XP is

XP grew out of a payroll project at a large car manufacturer in the 1990s, when requirements were changing faster than traditional methods could follow. It took a collection of existing good practices and, as the name suggests, pushed each one to an extreme. If code review is good, review all code all the time, which became pair programming. If testing is good, write the tests first. If integration is good, integrate several times a day.

Its values began as communication, simplicity, feedback and courage, with respect added in a later edition. Its practices cluster into four areas, according to the common summary:

• Fine-scale feedback: pair programming, the planning game, test-driven development and having the whole team involved.
• Continuous process: continuous integration, refactoring and small releases.
• Shared understanding: coding standards, collective code ownership, simple design and a shared metaphor for the system.
• Programmer welfare: a sustainable pace that avoids overtime.

XP also names a few roles, notably an on-site customer who supplies requirements and steers the work. The SBOK® Guide's overview of agile methods adds that XP's roles include customer, developer, tracker and coach, and says XP's engineering practices are the reason it has been widely adopted.

XP was one of the methods represented when the Agile Manifesto was written in 2001, alongside Scrum.

What Scrum covers that XP does not

Scrum is about structure around the work. It defines a Product Owner who orders a single Product Backlog, a Scrum Master who is accountable for establishing Scrum, and Developers who plan and do the work. It defines events, a commitment to a Sprint Goal, and a way of inspecting an Increment with stakeholders. XP has a planning game and short iterations, but it does not define accountabilities with the same precision, and it says less about how stakeholders inspect the outcome and about managing the product over time.

What XP covers that Scrum does not

The Guide asks the Developers to create a usable, verified Increment every Sprint that meets the Definition of Done. It does not say how. XP does. Test-first development gives rapid evidence that code does what it should. Continuous integration keeps the Increment always in a state that can be shown. Refactoring prevents the code from becoming expensive to change, which would eventually slow every Sprint. Pair programming spreads knowledge. Collective ownership removes the single point of failure.

These practices are what make a Definition of Done sustainable. A team can commit to "all code reviewed, tested and integrated" in Sprint Planning, but without a practice for achieving it daily, it will break the commitment by the last week. See Definition of Done.

A worked example: the same Sprint with and without XP practices

This is an illustrative team. They have a two-week Sprint and a Definition of Done that requires automated tests and a merged build.

Without XP-style practices, developers work alone on branches for a week. Tests are added at the end. On day eight, three branches are merged, two of them conflict, and the build is red for a day. Two items miss the Definition of Done. The Sprint Review shows three of five items, and the Retrospective produces an action to "improve testing".

With them, developers pair on the riskiest item, write a failing test before each change, and integrate at least once a day. The build is rarely red for long. By day eight, four items are done and the fifth is close. The Retrospective discusses whether to extend the pairing to the whole team.

The Scrum events are identical in both cases. The difference is in what the Developers do between them. Scrum creates the demand for a good Increment, and XP supplies a way to build one.

How the two relate in practice

Many teams combine them. Typically Scrum supplies the roles, events and artifacts, and XP supplies the engineering discipline underneath. The Scrum Guide welcomes this: it describes Scrum as a container for other techniques, methodologies and practices, and it states that the Developers decide how to turn Product Backlog items into Increments. Nothing in the Guide prevents pairing or test-first work. Nothing requires them either.

A few places where their ideas touch directly:

1. Iterations and Sprints. XP uses short iterations and Scrum fixes the length in a similar way.
2. User stories. XP popularised writing requirements as stories. The Guide does not require them, but they are common in Product Backlogs.
3. Velocity and estimation. XP's project velocity and Scrum's capacity work have much in common, and both can be misused. See how velocity gets misused.
4. Sustainable pace. XP lists it as a practice. The Guide credits working in Sprints at a sustainable pace with improving focus and consistency.
5. Customer involvement. XP's on-site customer maps loosely to a Product Owner. The two differ in authority: the Guide gives the Product Owner full accountability for the backlog's content and order.

Where they pull in different directions

The two are not free of friction. XP's emphasis on an on-site customer can conflict with the Scrum idea that the Product Owner is a single accountable person: if a team takes requirements from several customer representatives, the backlog loses its one voice. XP also encourages changing priorities between iterations, while Scrum protects the Sprint Goal from changes that would endanger it, though it allows scope to be renegotiated. And XP's rule that every line of production code is written in pairs is a stronger statement than anything in the Guide, which leaves the choice to the Developers.

None of these is a reason to avoid combining them. They are reasons to decide, in the working agreement, which rule applies when the two disagree.

Common mistakes

• Treating XP as a rival. It is not a competing framework in the way Kanban or waterfall are. The two are usually complementary.
• Blaming Scrum for technical debt. Scrum does not tell anyone to skip tests. A team with no engineering practices will accumulate debt in any process.
• Adopting practices without reasons. Pair programming on every task is not required. The question is whether the practice serves the Definition of Done.
• Assuming the Scrum Master teaches engineering. The Guide makes them accountable for Scrum, not for code quality, which belongs to the Developers.

How to practise it

Look at your Definition of Done and ask what practice makes each line achievable every day. If a line has no practice behind it, it is a wish. In the simulator the Definition of Done is a decision you make and hold, so you can see what a weak one costs later in the project.