Everything is in the title: What is the difference between Scrum and eXtreme Programming? Is it possible to have a simple but explicit explanation?
Here is a great definition:
- Scrum teams typically work in iterations (called sprints) that are from two weeks to one month long. XP teams typically work in iterations that are one or two weeks long.
- Scrum teams do not allow changes into their sprints. Once the sprint planning meeting is completed and a commitment made to delivering a set of product backlog items, that set of items remains unchanged through the end of the sprint. XP teams are much more amenable to change within their iterations. As long as the team hasn’t started work on a particular feature, a new feature of equivalent size can be swapped into the XP team’s iteration in exchange for the unstarted feature.
- Extreme Programming teams work in a strict priority order. Features to be developed are prioritized by the customer (Scrum’s Product Owner) and the team is required to work on them in that order. By contrast, the Scrum product owner prioritizes the product backlog but the team determines the sequence in which they will develop the backlog items. I’ve never seen a Scrum team not choose to work on the highest-priority item. And a Scrum team will very likely choose to work on the second most important. However, at some point one of the high priority items may not be a good fit for the sprint being planned—maybe a key person who should work on it will be swamped by work on higher priority items. Or maybe it makes sense to work on a slightly lower priority item (let’s say #10 on the product backlog instead of #6) because the team will be working in the code where #10 would be implemented.
- Scrum doesn’t prescribe any engineering practices; XP does. I love the XP engineering practices, particularly things like test-driven development, the focus on automated testing, pair programming, simple design, refactoring, and so on. However, I think it’s a mistake to say to the team “you’re self-organizing, we trust you, but you must do these specific engineering practices….” This sends a mixed message to the team that causes confusion. I love the XP practices but don’t like mandating them. I want teams to discover the value on their own.
Picking up on a few points that have already been made:
XP is - as the name suggests - about programming. Scrum on the other hand is about managing projects first of all. These do not have to be software projects, although they fit quite well into the "Scrum way".
As iterations in Scrum are quite fast, it's quite natural to pick up certain techniques which support the ability to work quick.
Pair programming helps to make a team flexible, as certain tasks are not in the responsibility of one sole member, but at least one other member knows enough to pick up on the task in case of illness etc.
Code reviews also help to identify errors early and give the rest of the team an idea of the architecture and components of the system under development in which they are currently not involved.
So, I would say both fit together quite naturally.
XP has some practices which are not required (but are usable) by scrum, such as pair-programming and test-driven development.
Both are similar in that they're agile, iterative processes that require some measure of planning, development, and testing within a single iteration (sprint).
A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
A software development methodology.