XP vs Scrum: Complementary Approaches

XP and Scrum emerged around the same time and share the same roots, but they focus on different problems.

Scrum focuses on project management: How do you organize work? What roles do you need? What meetings? What artifacts? Scrum gives you a framework for managing the flow of work through a team.

XP focuses on engineering practices: How do you actually write the code? How do you ensure quality? How do you keep the codebase healthy? XP gives you practices for doing the work well.

This is why they complement each other so naturally. Scrum tells you what to build in a sprint. XP tells you how to build it.

Despite different focuses, XP and Scrum share key concepts:

• Iterations: Scrum has sprints (2-4 weeks). XP originally had 1-2 week iterations.
• Customer involvement: Scrum has the Product Owner. XP has the on-site customer.
• Retrospectives: Both emphasize reflecting and improving.
• Self-organizing teams: Both trust teams to figure out how to work.
• Working software: Both prioritize running code over documentation.

A team "doing Scrum" looks a lot like a team "doing XP" from the outside. The difference is under the hood.

Scrum is silent on engineering practices. The Scrum Guide says nothing about TDD, pair programming, refactoring, or continuous integration. It assumes teams will figure out the technical practices themselves.

XP is prescriptive about engineering practices. XP says you must write tests first. You should pair program. You will refactor continuously. You will integrate many times a day.

Scrum defines roles. Product Owner, Scrum Master, Development Team. These roles have specific responsibilities.

XP is flexible about roles. There's a customer and developers. That's about it. XP assumes the team will self-organize around roles as needed.

Scrum has specific events. Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective.

XP has more flexible cadences. Planning game, standup, iteration demo—similar, but less rigidly defined.

Many successful teams use Scrum's framework with XP's technical practices. This combination is powerful:

• From Scrum: Sprints, Product Owner, Scrum Master, Sprint events, Product Backlog
• From XP: TDD, pair programming, refactoring, continuous integration, collective ownership

This isn't "impure" or wrong. The original Scrum creators expected teams to bring engineering practices. XP provides them.

A common pattern:

1. Use Scrum for planning and organizing work
2. Use XP practices for doing the work
3. Use retrospectives to continuously improve both

Teams often call this "Scrum with XP engineering practices" or just "doing agile well."

You can do XP without Scrum. Some teams prefer XP's lighter-weight approach:

• Continuous flow instead of fixed sprints
• Customer on-site instead of a Product Owner proxy
• Self-organized roles instead of defined Scrum roles

This works well for teams that find Scrum's structure too heavy, or where work arrives continuously (like operations or support).

The key is that XP's technical practices are non-negotiable. Whether you use Scrum, Kanban, or something else to organize work, TDD, refactoring, and continuous integration remain essential.