Most people in the industry seem to agree that Scrum and XP complement each other. Jeff Sutherland and Ron Jeffries agree that it is a good idea to start with Scrum and then let XP follow naturally (since Scrum teams are self-managing and can choose whatever engineering methods they like).
Here’s a quote from Ron and Jeff’s Deep Agile course:
"You don’t see high performing Scrum teams without XP engineering practices. It is difficult to scale XP teams without Scrum and Scrum solves the management interface issues for XP. Be careful about doing pieces of anything and calling it Agile."
Mike Cohn and Robert C Martin believe (or hope) that these will merge together into some kind of "unbranded Agile". Mike’s take is that this will simply be called "the way we do software". (Based on personal discussions with both of them)
2nd Annual State of Agile Development Survey shows the following statistics for Scrum & XP adoption:
- Scrum: 37%
- Scrum + XP: 23%
- XP: 12%
This is of course a matter of definition (i.e. how much of XP do you have to do for it to count in this survey?). But the message is still quite clear.
Personally I believe that many of the "scrum only" companies in that survey are in fact using many of the XP practices under the radar.
So what’s your guess for next year’s survey? My guess is 30% Scrum, 40% Scrum+XP, 10% XP.
This picture illustrates how they fit together. Scrum can be seen as the interface between the team and the stakeholders. Scrum leaves a hole in the middle, i.e. how the team should do their daily work, which XP fills in quite nicely. Once Scrum is in place the team is self-managing and can choose how to do their work. However, Scrum places fairly strict requirements (such as delivering working tested software every iteration) making XP a natural choice for many teams.
Agile (a.k.a. adaptive or empirical) software development is all about feedback cycles. Scrum and XP complement each other very nicely here, as shown in the picture below (yellow = XP, green = Scrum). There is a slight overlap in that both XP and Scrum advocate daily meetings, which is no problem really.
Small circle = short feedback cycle.
On one end of the scale, pair programming gives a feedback cycle of a few seconds, where defects are detected and fixed within seconds ("hey, isn’t that supposed to be a 3?") . This is a "are we building the stuff right?" feedback cycle.
On the other end of the scale, Sprint demo gives a feedback cycle of a few weeks. This is a "are we building the right stuff?" feedback cycle.
Right on! It’s feedback cycles all the way down. And up! Recommended reading for anyone who wants to explore this way of looking at things more deeply: The Fifth Discipline by Peter Senge.
Glenn Vanderburg had an essay at OOPSLA 2005, where he examined XPs tight coupling of practices.
In that essay, he draws two interesting curves that shows approximately the same thing as the onion, in a different way. The curves shows (most) XP practices and what each practice gives feedback to (statements, classes, architecture, …) and in which time-span they give the feedback (from seconds to months).
I found the curves rather interesting, since I hadn’t thought explicitly about it as the same thing on all levels before that presentation.
Kind regards
Niclas