Today I picked up Kent Beck 'Extreme Programming' book from the bookshelf, what's a great book! Last time I read it was about 5 years ago. The XP practices now make even more sense to me. However, over this period, I saw more projects branded themselves 'Agile', 'Scrum', few doing XP. Why?
With the help of James Shore's Scrum and XP Practices: Cross Reference, we can do a quick comparison
- Stand-Up Meetings XP: Yes, Scrum: Yes
- Continuous Integration: XP: implied, Scrum: n/a
- Ten-Minute Build XP: Yes, Scrum: n/a
- Simple Design XP: Yes, Scrum: n/a
If a programmer thinks it is easy, then he/she is still in "don't know what you don't know" stage.
- Pair Programming XP: Yes, Scrum: n/a
Maybe a controversial one, but there many studies approving pair programming achieve better productivity with lower rates
- Single Code Base XP, Scrum: n/a
I have seen too many times, several junior level developers (not by age) got excited talking about branches, always end up with disappointments.
- Refactoring: a core practice in XP, n/a in Scrum
Note if you don't have unit tests, it is NOT refactoring. What's your project's unit test code coverage?
- Customer Tests XP: implied, Scrum: n/a
Getting customer to write/review automated tests prevents miscommunication.
- No bugs: XP: Implied, Scrum: n/a
As you can see, XP practices are more real, for my experience, found more used in successfully projects. Few people claim their doing XP as it is can be easily checked against the above list.
Scrum is, in my opinion, a more abstract version of XP and the word 'sprint' sounds cool. I remembered that in a group session at one conference, one attendant called out "Who else hate Scrum?" For me, what flag you fly up doesn't matter, how you do it matters. Story cards and stand-up meetings don't make projects 'Agile' (I am sure you have seen enough Fake agile projects like me), automated testing (unit and functional UI) and continuous integration do.