OK, there is something I can talk about. For the last year, I've been on a project that has used the XP process as the methodology. At the beginning, I had mixed feelings about the process. Now that I've practiced TDD and pair programming and used tools like NUnit and NAnt for over a year, I can say that...I still have mixed feelings.

Why is this? Because I feel that the process has too much religious trappings around it. I can't quite put my finger on it, but it feels like XP has a cult-like feeling to it. Granted, that's not what we're doing on the team as we use the practices that work and drop the ones we feel don't cut it. I like TDD - I have a lot more confidence in the refactoring I make because I know I can run my tests and know if there were any problems with my changes. I also like pair programming. I find it refreshing to get real-time feedback to the task at hand. In fact, when I want to work on the code base, I don't like it when we have an odd number of developers in the room. However, I also feel like there isn't enough investigation that's done into the system requirements. Yes, I know that you can't know everything, but the story concept is something way too vauge for me. I don't know...the XP ideas are interesting, but I don't call myself an XP developer. It's hard to get a pulse on the project as a whole. Finally, it's weird to hear the XP coaches that the company brought in for these projects to say, "Well, the XP process says...". That's fine, but I'm more interesting in simply coming up with best practices and ideas and not limit them by labeling them into a defined view of software development.

Ultimately, there is one overarching goal that I strive for in every project: Get it done! Granted, there's a lot more that a development team needs to do to have a successful project, but when I feel like I'm getting derailed, that's the phrase that I tell myself to try and get back on track. Each project is very different, and I don't think there's one approach that will work in all cases. I like some of the ideas that XP has to offer, and, as long as it's taken as a set of debateable best practices rather than a group of religious commandments, then I'm fine with it. When push comes to shove, I'm more concerned that our team is working well and the customers are happy.

And...I'm curious. Do Microsoft development teams follow XP? If so, why? If not, why not? Whether you like or hate Microsoft, they are one of the most successful software companies in history, and it would interesting to know if MS teams use any of the XP principles.