This week we’ve launched our first XP iteration. While we’ve been using parts of XP for a while, this has forced us to consider some of the differences between XP and Scrum iterations/Sprints.
First, the rollout of XP has been pretty smooth. One concern was that the introduction of pair-programming and test driven development would meet a lot of resistance and suffer in effectiveness. This hasn’t been the case. In fact, it’s been embraced by people transitioning over to XP.
Part of this can be attributed to lessons learned over the last year. Creating our first generation data-driven engine for a finished game in 25 months had left a lot of loose ends. One of the biggest pitfalls of such architectures is the ability for bad data to cause problems unless you are really careful. We didn’t have the resources or the practices to be as careful as we needed to be. Pain is a great teacher and it’s clear that we need to embrace better engineering practices to avoid this in the future. With the successful application of one Agile method (Scrum), we’re more than willing to try out XP as a solution.
XP books say that you can roll out XP practices one or two at a time, and we’ve done this. Pair programming and unit testing were the first practices introduced. Now we’re introducing proper iterations (as we grow the first teams that need it). Clearly we have work to do in writing user stories and defining acceptance tests.
The good thing is that you can come out of an XP iteration planning “game” with a bunch of tasks cards and start doing Scrum as usual. There is nothing inconsistent with either practice other than the 2-week Iteration versus the 4-week Sprint. However both methods allow you to adjust your iteration time range completely.