When Apple released the Macintosh it changed the face of computing. Graphical user interfaces, drag and drop icons, clickable menus. Since it’s release, the personal computer has never been the same.
The same thing happened with the release of XP. Like an earthquake, it shook just about everything we traditionally believed and practiced in software delivery down to it’s core.
And then both failed.
The Mac got displaced by the cheaper IBM PC Junior.
And XP was pushed to the side by the less threatening Scrum.
In this article I would like to explore why Scrum has become so popular, the challenges this popularity brings to Agile, and why, like the Mac, I don’t think we’ve heard the last of XP.
Maintaining the Status Quo
One reasons I believe Scrum has grown so popular, is because unlike XP, it struck the right balance between maintaining the status quo and change.
The first version of XP was threatening. If you weren’t a developer or a customer, it wasn’t really clear what your role on an XP project was. With developers and customers joined at the hip, XP teams delivered at a speed and level or quality, seldom seen outside of startups.
(Note: In reality we did many XP projects with analysts and testers but I want to make a point, so bear with me).
But this speed and efficiency came at a price. It radically changed the status quo.
Testers felt threatened because developers were writing tests.
Analysts questioned their role if developers were speaking directly with customers.
And Project Managers were perhaps the most disrupted. XP trivialized their best laid plans, and had them embrace the one thing they had been trained to eliminate on all software projects – uncertainty and change.
Scrum on the other hand was different. Instead of insisting developers and customers sit together and build software, Scrum said: “Why don’t you guys form a team, and ship something of value every 30 days.” It didn’t say how to do that. Only that working software every 30 days was the goal.
This was music to the established players ears.
Analysts could analyze.
Testers could test.
Project Managers could PM.
I call this Corporate Scrum. Everyone could pretty much do exactly what they did before, but now in shorter 30 day cycles. Much less radical. Way more status quo.
Where XP alienated. Scrum embraced.
The challenge with Scrum
This of course lead to some challenges. Scrum is all about planning. It doesn’t talk engineering. This lead to a lot of Scrum teams doing the easy stuff (daily standups and Sprint planning), while failing on the hard (consistently delivering high quality working software).
Planning is easy. Delivery is hard.
And I think the Scrum community itself could do more here. Not highlighting, or actively promoting the XP practices around unit testing, refactoring, TDD, and continuous integration runs the risk of seeing the term Flaccid Scrum grow in popularity.
The Tribal knowledge of XP
And I think us XP’ers can do our part by sharing our stories and wisdom around practices like:
YAGNI
Simplest thing that could possibly work
Yesterday’s weather
Test everything that could possibly break
Production readiness
These euphemisms are too important to forget. And the spirit and technical excellence that contributed to XP’s early success will be necessary for Scrum too.
This is the beginning. Not the end
So while XP feels like the Apple Macintosh of the 90s, it would be premature to write XP off. Many of it’s ideas are only now becoming widely accepted. And many more are only just beginning to re-emerge.
It may never reach the heights today’s Mac, or displace the IBM PC Junior that is Scrum, but it’s influence and spirit are still being felt, and will be, for years to come.
Filed under: agile Tagged: agile, Extreme Programming, mac, Scrum, XP