Scrum and Extreme Programming (XP) are two agile processes that work well in tandem. In fact, if you walked in on a team doing one of these processes you might have hard time quickly deciding whether you had walked in on a Scrum team or an XP team—both because their framework is similar and because Scrum teams often adopt XP practices, and vice versa.
XP and Scrum complement each other so well because, though they both embrace agile principles, they come to agility from different perspectives. While some of the differences between the two are mainly semantics (Scrum’s product owner is close to XP’s customers; Scrum’s sprints are XP’s iterations; and so on), others are more substantial. XP’s iterations are one or two weeks long, versus the usually longer two-week to one-month Scrum sprints. Scrum doesn’t allow any changes to the chosen sprint backlog after planning; XP allows teams to substitute a feature in exchange for an unstarted feature of equivalent size. At the same time, XP teams must always work in priority order; while Scrum teams can choose a lower priority item for a sprint if it makes sense for scheduling or coding. (For more details on these differences, check out my classic blog post: “Differences between Scrum and Extreme Programming
Perhaps the biggest difference, though, is the very thing that makes these two frameworks so compatible. XP mandates a set of engineering practices; Scrum does not. At the same time, Scrum mandates planning ceremonies and artifacts, where XP does not.
My typical advice to teams is “start with Scrum and then invent your own version of XP.” I love the core 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.
The XP practices are wonderful but they work best (and teams truly commit to them) if the team members decide to implement the practices themselves rather than having them mandated. I help teams do this in my coaching by asking questions like, “Would this bug have happened if we'd been doing test-driven development?” and “Would we have made that mistake if we were pairing?”
Scrum and XP are both valuable approaches to agility in their own right. Put them together, though and you have a wonderful blend of the management and technical practices teams need to function at a high level.