Extreme programming is no longer relevant. According to the latest annual State of Agile™ survey, less than 1% of the nearly 4,000 respondents stated that they were practicing Extreme Programming, while 94% said they were practicing agile.
Could it be that the need for engineering practices have passed?
I’m not suggesting that I think that teams don’t need engineering practices, I’m saying that after seeing these stats that I was concerned that people may have stopped thinking that they need engineering practices.
Has the need for engineering practices passed?
Extreme Programming is the first of the big movements that got the attention of the development community. Scrum probably came earlier but it was Extreme Programming that really started igniting people’s imaginations. Yet, lately we don’t hear about it. It made me nervous that agile has had so much momentum, yet the foundational engineering practices seem to have been passed by, so I dug a little deeper.
What I started to uncover is that while Scrum is still the most common project management oriented piece of agile, you’ll notice a lot of organizations are using a hybrid, they’re doing Scrum for their project management and their teams are using Extreme Programming practices without necessarily realizing those practices come from Extreme Programming. I think that’s okay, but it makes me wonder if we might start losing some of those engineering practices because we’re just not talking about them enough.
Extreme Programming Today
First, let’s talk about what is Extreme Programming. Extreme Programming is a set of practices, mostly technical practices, that we want to apply to our software development cycles. Now this can fit nicely with Scrum, so that’s good. Most of these practices are around test-driven development, which is vital. Practices such as refactoring, continuous refactoring, continuous integration, automated acceptance tests and pair programming. There are others, but these are the ones that I see as the heart of Extreme Programming. If we want to continue to emphasis these practices without calling them Extreme Programming, we might start to lose the holistic nature of what XP is all about. So I do worry about that.
I take heart that Extreme Programming practices are being used somewhat unconsciously. Often when I meet a new team practicing Scrum and ask about technical practices, they look at me like I’m crazy and say, “Well, duh, of course we are doing that.” That’s fantastic, but with the dramatic growth of Agile in the enterprise we need to be careful that we don’t start to lose these practices.
This makes me think of something Kent Beck said at the very first Extreme Programming Universe Conference, “You know, five years from now I hope we don’t even use the name, XP. It’s just how people make software.” It seems he has gotten at least half of his wish, people don’t tend to use the name, XP, but I’m not sure we’ve gotten to the point where it’s just how we write software.
Enterprise agile is, by necessity, going to focus more on project, program and portfolio management, leaving the implementation to the teams themselves. If no one is talking about technical practices, may they one day be overlooked and forgotten?
From my perspective, what we really need to do most is build on agile’s momentum by digging deeper into the technical practices. We need to make the second half of Kent Beck’s wish come true and make technical practices just how we write software.
A consultant by the name of Payson Hall once made a comment that sticks with me, “If you can’t reach this distance, you’re not tall enough to ride this ride.” If you’re not doing the Extreme Programming practices: pair programming, refactoring and so on, then you’re not ready to get on the agile ride. It doesn’t matter how many iterations you plan, how many fantastic meetings you have, how many Scrum gatherings you attend, if you’re not doing the engineering practices, you’re not going to be as successful as you could be.
As often is the case, this is not just a technical problem, it’s a people problem. If the organization feels like they are agile just because they are doing sprints or have a kanban board, they’re not where they need to be. They’re not going to succeed. They might get some traction. It’s certainly going to be better than just waterfall but they’re still not there. The whole point behind Agile practices is we need to reduce and flatten the cost of change curve and we can only do that with the technical practices in place.
What’s Next for Technical Practices?
There’s another movement that has been growing over the past few years called Software Craftsmanship. If you look closely, if you scratch the surface of the Software Craftsmanship movement, what you’ll see is the same people who have been incredibly active in the Extreme Programming community. This is no accident.
The Software Craftsmanship movement is a reaction to the emphasis on project management and a way to bring Extreme Programming practices and the idea that creating software is more than just typing a bunch of lines of code into. It’s important that we look at Software Craftsmanship as a natural extension of Extreme Programming.
We need to keep focus on the foundational principles that are core to XP, not just the technical practices but the values: communication, feedback, courage and, simplicity. Those values being an important part of our day-to-day lives in the software development community. Craftsmanship is a nice wrapper; it gives us a metaphor to think about it where Extreme Programming gives us the actual activities and the values that can help us make that successful.
What’s next for Extreme Programming? What can you do about this?
First, go read the book again. Every couple of years I go back and read the book and I learn more. It reminds me why this was so exciting in the first place. Second, make sure you’re doing these things. Make sure you’re embracing these values and practicing the technical practices on a day-to-day basis.
Does that mean that we’ll bring the words, Extreme Programming, back to the front? I don’t know. I don’t know if I care. What I do care about is that we find a way to get these great ideas back into the software development world.