I'm always happy to talk about how to make things better and I'm mostly of the opinion that XP is the best way to make development of software more satisfying for all those involved. With this belief, my focus has become, "Where is the value it what is being done?" What value is there is BDUF? What value is there in TDD? What value is there in what we are proposing to add/remove from our processes? Everything has boiled down to the simple question of what value does X provide. I don't think this is an XP specific, or even an agile specific, practice, but I find myself constantly asking this question internally and very often now those around me are probably getting used to hearing this query.
Which leads me to how we are currently adopting XP. We had a detailed discussion yesterday discussing what we have been doing and what we thought we were doing and what we really should be doing. During this conversation, I realized that we were sort of sneaking up on implementing XP within the organization. Not so much getting ready to ambush the company with XP, but rather ambushing ourselves (sort of). Almost a death by a thousand cuts, but instead of death, we get agile development and instead of cuts we have practices. The placement of the cuts are important, but I think I'll bail on this analogy now, before it gets uglier.
Initially, I was asked to identify what I thought should be the development teams focus to be more agile. The first step was to mandate that all development would be TDD. After that, we started pair programmer, but we started "soft" (but spontaneously went "hard" just last week). The interesting bit is where we just started grabbing at practices without much thought. Next cab off the rank was planning game, but this failed horribly. Partially because the customer was out of the office for an extended length of time, but even if this hadn't happened, the planning game wasn't going to give us the most value. We sort of discovered this during our discussion.
Out came the value query. What practices would deliver the most value for the team to adopt next. With this in mind, it was obvious to us that planning game was not the answer (though it might have looked like it previously). Customer tests won out in the end. We found that we were a bit rudderless and even though planning would provide this, acceptance tests really look to be the right answer. To be fair, we sort of are doing planning already, user stories with priorities, but no out right planning game. On inspection from where I was sitting, planning game looked like something valuable, but needed some infrastructure to really work probably. Also, there was a short discussion about how the planning game could help lift the team by providing a psychology boost by completing things. I argued against this from the point that it might very well add negative pressure as well if the team isn't quite ready for it. There is nothing worse than setting goals and continually falling short. Once we've got some acceptance tests and we are estimating and passing the acceptance tests, then the next step would be to get that boost. It sounds a bit conservative to me, but it makes sense. I'm not willing to introduce negative feedback loops to the process…
So, my overall generalizing conclusion from this small experience is that the best way to approach introducing XP to a team of developers depends a bit on history. If there is a legacy codebase, like what we currently have, then sneak up on it by constantly examining what could be done and prioritize these by what value you believe they will give to the process. We started with TDD. Next added pair programming. Failed miserably with planning game (but only because we forgot to look for value) and now are focusing on acceptance tests first before working on a story. Implied in this is that we are taking the time to reflect, which we have decided to explicitly do (even without a planning game, ironic, eh? 8)). BTW, to me, reflection is where you look at your values, i.e. communication, simplicity, etc.
The corollary to this generalization is that if you are on a greenfield project, grab as many practices as you can find and go for your life!
