Which is better? Scrum or XP? Is there one that is more applicable than the other or is there another alternative?
Tobias Mayer recently wrote on his blog Don't Do XP:
I am beginning to grow weary of the repeated discussions with the many who insist that Scrum doesn’t work without XP. Scrum works just fine — if applied with an understanding of the values and principles that are at its foundation. The context you implement Scrum in will determine the practices you need to apply. Scrum in Church will have a different set of good practices to Scrum in Software, and both will be different to Legal Scrum.
XP advocates are quick to blame Scrum for the lack of good development practices in the software industry. But given the very slow uptake of XP it could be argued (and I shall do so) that in fact XP itself is responsible for the lack of good practice in our industry.
It seems what Tobias is saying is that Scrum is enough to "pull" (in the Lean sense) the necessary technical practices and that does not require all of XP. XP is too much of a burden and it's lack of adoption is proof of that.
Steve Freeman responded to Tobias' post in Do do XP:
As an occasional XP advocate, I don’t “blame Scrum for the lack of good development practices in the software industry”, I blame the software industry. If we worked in an effective industry, we wouldn’t be having methodology wars because things would just work. Now this same industry is messing up Scrum too by just taking on its ceremonial aspects. On the other hand, to blame XP for blocking good practice is just bizarre.
XP is a tiny movement that attracted some attention. What XP (version 1) did achieve was to show that it is possible to break through the logjam of cautious procrastination that still cripples many development teams, but without resorting to hackery. It gave teams a reliable package of practices that just worked. Of course XP didn’t take over the world because it’s not suitable for everyone–not least because it requires a degree of focus and skill that is not appropriate for many teams. Kent Beck’s presentation of XP version 1 was extreme on purpose: it was designed to inspire us huddled masses, and to stretch the boundaries of what was considered possible in software development, to reframe the discussion.
Steve goes on to say that XP had much to do with the current emergence of the craftsmanship movement:
Tobias writes that the good development practices were spreading slowly at the time, but I’d argue that without XP we’d still be waiting. Test-Driven Development is still not that widely accepted and even the original C3 team didn’t adopt it fully until Kent was writing his book. Refactoring had a small academic following, but it’s not very safe without the compensating practice of TDD. I suspect most teams still ban changing code unless it’s to change a feature. Pair programming is still a very hard sell and, again, works much better in the context of TDD. I’ve seen enough Scrum teams that have not found a coherent set of technical practices. To say that they just need to improve their Scrum implementation begs the question of how Scrum is adopted and the limits of self-organisation.
This conversation, and many others, prompted Yves Hanoulle to suggest that maybe the Agile community is going through the second of the forming/storming/norming/performing cycle:
It looks like we have a lot of discussions where we question ourselves as an industry.
I have the feeling it is the first time this happens at this scale. Maybe I’m too young. Maybe I ‘m more in the middle now or have more idea’s myself on who’s right or wrong. Maybe it’s the always connect, twitterly, blogging world that makes these discussions so more public.
This reminds me a lot of the storming phase that exists in a team live cycle,or the chaos phase in Satir's model. So from a point of view of a coach these discussions and where this goes is interesting.
In these discussions, there is clearly no leader. Or let me put it in another way, no leader that everyone would accept.
So this contention in our community might actually be just a sign of our continuing maturity. This writer has found in his experience that everything makes sense in context. There have been successful teams that started with Scrum, and others that have been successful starting with XP, and many that have failed with both. The one thing that we do well at the Agile community is learn by experimentation and not lose sight that all of these practices and processes are only a means to an end.