XP (eXtreme Programming) is better than Scrum, as XP defined DevOps 20 years ago
XP (eXtreme Programming) is well ahead of its time. However, few projects adopt it though XP is more correct and practical.
Today I picked up Kent Beck’s ‘Extreme Programming’ book (2nd ed) again from my bookshelf. What a great book! I have read it many times. Over the years, the XP (eXtreme Programming) practices have made more sense to me.
XP started Agile, and the ‘Extreme Programming Explained’ book was published in October 1999. 22 years later, many projects branded themselves as ‘Scrum’ under ‘Agile’ while XP has been forgotten. Why?
First of all, the name matters. To an executive's ears, XP is probably not a good name.
Extreme
“I want to play safe, the fewer risks, the better”. This mindset explains the “Nobody Ever Got Fired For Buying IBM” proverb. (Fobes’s article “ ‘Nobody Gets Fired For Buying IBM’. But They Should ” is a good read)Programming
“I manage programmers (and don’t know to program), not the other way around.”
While Scrum might not sound like a good name either, it is abstract enough to make it meaningless by name. Nevertheless, the terms “Sprint” and “Backlog” sound ‘cool’!
Besides the names, the main difference between XP and other Agile processes is that XP is focused on engineering practices, while others are not. As it is explained on the Agile Alliance website:
XP is the most specific of the agile frameworks regarding appropriate engineering practices for software development. — agilealliance.org
With the help of Scrum and XP Practices: Cross Reference by James Shore (co-author of the highly-acclaimed ‘The Art of Agile Development’ Book), we can do a quick comparison:
Stand-Up Meetings XP: Yes, Scrum: Yes
Continuous Integration: XP: Yes, Scrum: n/a
Ten-Minute Build XP: Yes, Scrum: n/a
Simple Design XP: Yes, Scrum: n/a
If a programmer thinks ‘Simple Design’ is easy, then he/she is still in the “don’t know what you don’t know” stage.Pair Programming. XP: Yes, Scrum: n/a
Maybe this is a controversial one, but many studies have proved that pair programming achieves better productivity with lower ratesSingle Code Base. XP: Yes, Scrum: n/a
I have seen it too many times: several junior-level developers (not by age) got excited in talking about branches, but always ended 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 is your project’s unit test code coverage?Customer Tests. XP: implied, Scrum: n/a
Getting customers to write/review automated end-to-end tests prevents miscommunication.No bugs. XP: Implied, Scrum: n/a
Yes, ‘no bugs’ is possible with real test automation. Check out this article: ‘Why Don’t I Use Defect Tracking? No Need, I do real Continuous Testing.’Daily Deployment. XP: Yes, Scrum: n/a
At AgileWay (my company), we have been doing daily deployment for all of our software (if changes are made) for over 12 years. And this is backed up by comprehensive automated end-to-end testing.
What I can tell you is that doing daily deployment is actually more natural in software development. Check out this article: “Did You Push Software Updates into Production Yesterday?”
As you can see, XP practices are more real and measurable, while Scrum is vaguer. A project is not qualified for XP if it does any of the following:
Code has more than one active branch in the source control
No Continuous Integration or CI runs for more than 10 minutes
No executing automated tests in CI
Over a handful of outstanding bugs
Programmers code in their own individual cubicles, instead of pair-programming
No deployment to production every day
However, a non-XP project can happily label this as “Scrum”.
It is quite obvious, the bar that XP sets is too high for the mass. Take pair programming as an example. Most people have never seen the two 10x (10 times more productive) programmers work together. As their combined productivity will be 1+1 > 2, they get results quickly. The positive feedback fosters further co-collaboration. If an average programmer pairs with a 10X programmer, his productivity performance will most probably improve dramatically. As a matter of fact, this is the best way to grow. However, if you put two average/mediocre programmers together, the performance is often 1 +1 < 2.
22 years after the Agile movement, it seems that XP is more correct. XP fits well with DevOps which is probably the hottest terminology in the software industry. The popular terms we hear now, such as
CI/CD
Continuous Testing
Trunk-based development
Zero Bug Tolerance
BDD
Ship early and Ship often
Don’t you think they are just XP practices under a different name?
In my opinion, what flag you fly doesn’t matter, it is how you do it that matters. Story cards and stand-up meetings don’t make projects ‘Agile’ (I am sure you have seen enough fake agile projects). Automated testing (unit and functional UI) and Continuous Integration/Testing do.