As I wound up my afternoon on Friday, I was thinking that it would be worth breaking my self-imposed hiatus and make a post about work. We made a big change on Monday and it appears to be alleviating the pressures I hinted at looming on the horizon. Problem is, I got home and promptly forgot about it. I train myself too well 😉

As luck would have it though, AJ decided to post about it. I don’t know how many small development teams start introducing XP methodology, but any that do should read AJ’s post before they start. The best line in his post:

We’ve only been working this way for a week now but we’ve made more progress in that week than we have in the prior month.

In the face of what was fast becoming an impossible deadline, at the end of last week we decided something had to change. We’d tried to come up with ways to improve our productivity, but in the end there were only 2 major things taking up the team’s time – Support and . Support is something we absolutely do not compromise on, which left us with the unfortunate option of finding something in our thus far limited XP implementation to cut.

I’ve just realised that the solution we came up with has restructured the team back to what it was over a year ago, which makes sense given that we’re in this situation because the team has temporarily shrunk back down to the size it was then. We now have half the team doing support, the other half developing and everyone working on their own (for now, I hope we decide Pair Programming is necessary on the bigger tasks because there is only so much knowledge you can share during a code review).

What we haven’t done is drop XP and go 100% back to our old way of doing things. Sure we would’ve “finished” on time, but a lack of testing and code quality would kill any development plans for a few months while we fix bugs. What we have now relies on everyone individually keeping to the rest of our XP process, most importantly Test Driven Development. This is something I know I haven’t trained myself to do yet, I’ve been relying on someone sitting next to me to keep me on track – but sometimes you get stuck in the deep end 😉


The message I want to send to new XP teams? XP is not a strict set of rules, or a one way street. If something big comes up and you’re faced with not enough time to get the job done, don’t be afraid to look at cutting back some of your XP processes to speed things up. Particularly when it’s new you don’t want to be faced with total failure. Flexibility in XP doesn’t have to come just from what happens while implementing the process. It can also come from altering how much of the process you implement when conditions

We will of course be re-introducing Pair Programming once the deadline passes, everybody in the team knows there is value in what we were doing and regret that we’re forced to stop. We’ve just decided that right now we need to sacrifice some of that value to get back the development speed we lost with the reduction in team size.