A reader recently asked:

I have learned a bit about Scrum and Crystal and found that things are looser and they do not prescribe practices as XP seems to and that they want you to work toward finding the practices that work for your team. An example is Mike Cohn saying that he does not like to prescribe practices, like TDD which he believes in, but wants the team to discover for themselves their need of it as they do root-cause analysis and retrospectives. Does this go against y'alls advice on trying to do all the practices and later adjusting things to meet your needs as a project? Or is it something different?

[For example, see] Mike Cohn's thoughts about Scrum and XP. In particular starting with Scrum and creating your own XP.

My response:

I agree with Mike Cohn's description of the differences between XP and Scrum. I would emphasize that Scrum and XP are very similar, with the exception that XP includes more "how to" practices. There's also a bit of an focus difference; I feel like Scrum's focus is "let's create a self-organizing team" and XP's focus is "let's create excellent software." In other words, when I talk to Scrum people, they tend to talk more about self-organization and enabling the team; when I talk to XP people, they tend to talk more about software and delivering value. But despite that difference in attitude, the actual practices are very similar.

Mike's closing statement, that Scrum brings big benefits by itself, matches my experience. Scrum is also easier and less threatening than XP, so I see a lot more people starting out with Scrum. On the downside, the teams that start with Scrum tend to struggle more than the teams that start with XP. The XP teams experience more pain starting out, but then get to a high performance state within the first year. The Scrum teams I know have a much longer ramp-up time, generally having code quality problems for several years. Actually, I have yet to meet one that wasn't having code quality problems. None have gotten to the same high performance result that good XP teams do.

Granted, these statements are based on my experience, and my experience is formed by the people I meet at conferences and the companies who hire me. High performance teams generally don't hire me, so it could be that I'm not meeting the high performance Scrum teams.

Nonetheless, my experience is that Scrum teams have an initial success and then struggle. XP teams struggle to get started, but once they figure it out they have more success. Sometimes they don't figure it out, fail, and give up. With Scrum, teams seem less likely to realize that haven't figured it out; I've met teams who said they were using Scrum but weren't doing anything of the sort; they were just using the terminology. That happens with XP, too, but to a lesser extent, and usually of the form "we're doing XP but not..."

To boil it down to simple statements (perhaps too simple):

• Scrum: easy to adopt, very hard to master, fails quietly. You're more likely to successfully adopt Scrum, but the benefits won't extend to your codebase and you'll struggle with legacy code for many years. If you're missing pieces, you may not realize it.

• XP: hard to adopt, easier to master, fails noisily. You're less likely to successfully adopt XP, but you'll be well positioned for long-term success and mastery. If you're missing pieces, you'll probably be able to tell.

I have one complaint about Mike's essay. XP doesn't prescribe engineering practices, as Mike says; it includes them. For teams new to agile development, I do recommend that you use all of the practices from the start. However, a team that knows what it's doing will change its practice of XP over time. No two experienced XP teams practice XP in the exact same way, and there's no requirement that you do exactly what the books say. For example, one long-running XP team I know has evolved away from using iterations entirely, but I'd still think of them as practicing XP.

However, in order to know what to change, you have to know how the techniques work in practice. That's why I recommend starting out with all of the practices. Otherwise, it's like deciding to be an avant-guarde violinist without first mastering the violin.

Should you start with Scrum or XP? I recommend starting with XP, but Mike's right--you won't succeed if you force the practices down people's throats. The team has to agree to try them. If they're not ready to do that, you might be better off starting with Scrum. Then you can use that success, along with some of the code problems you'll encounter, to guide them to XP.

Finally, if you have the opportunity to get a coach to help you adopt your method, I recommend that you do. A good coach will help the transition go a lot more smoothly.