Regardless of how you feel about XP, it has helped the industry because it has given us a goal and opened up a discussion on how to achieve it.
For example, take test-first development and refactoring. Test-first may be a controversial practice, but it has raised the profile of automated testing, which can improve code with or without any other XP practices. XP's love of constant refactoring may be hard to swallow, but it has brought a positive light onto rewriting nearly working code and replacing it with something better.
Today, I came across another example: pair programming.
At $WORK, I'm writing a parser for a rather complex and underspecified grammar in Haskell. This week, another wrinkle came up: the need to read and write Tcl-formatted strings. I'm sorta the research programmer on the team, so I'm pretty much on my own on this project. Which sucks, sometimes. For example, it's hard to bounce ideas off of a partner.
Again, XP gives us a model and a goal. With pair programming, one of the goals is to keep both a low level and a high level perspective in mind when writing code, rather than just one or the other. The model is to program in pairs, where one person focuses on the implementation details, and the other focuses on the larger level issues. Imagine my surprise when I started feeling some of the benefits of pair programming while programming solo.
Here's the trick: pairing $me[time()] with $me[time()+3600]. A couple of times today, I felt myself getting stuck on a problem without making any progress, I put it aside and pulled myself up to a higher level perspective. (Maybe that process took an hour, maybe less. I wasn't exactly keeping track of time. I'm sure some psychologist has an explaination on why and how you need to take time to switch perspectives.)
All of a sudden, my mistakes became clear, and it became obvious where I was hitting the wall. I couldn't see the way out exactly, but I could see the problem that was holding me back, and I got a vague feeling for where I needed to be. When I started diving back into the code, things gradually got clearer, until I hit the next wall.
I shouldn't have been surprised, but I was. There have always been times when I'm writing code where the best thing I can do is walk away from the keyboard. What did surprise me is that I found yet another instance where the best way to improve a non-XP process is to borrow a page from the XP book, ferret out the goal, and aim for it.