Dealing With Trouble While Adopting XP

The XP process allows so much flexibility in getting things done but this comes at the cost of focus. I’ve previously talked about how product managers have to be careful they don’t abuse the flexibility in XP, but recently Ephox has discovered the huge benefit that being focussed can be, even when you’re doing XP.

We’ve come up against a very tight, very important deadline for a really big, really difficult new feature and at the same time we lost our entire support department so all support fell into the engineer’s laps. Support is just one of those things you have to do as a software company and our first impression was that the extra support load would reduce our velocity but we’d be able to share the load around the team, get the day’s cases out of the way and get back to developing. What actually happened was the entire engineering team wound up doing support all day and development stopped. Worse still, the team felt drained and tired all the time. We should have been able to get support out of the way faster and get developing, but for some reason we couldn’t.

The problem was a lack of focus. Instead of coming in each day looking forward to getting our teeth stuck into the really big, difficult feature and making progress, we came in wondering how much time support would take up. On top of that is the impact of context switching – every time you start a new case you have to come up to speed with a new customer’s use case, their problem, a new area of the product and often, another product. All that context switching not only takes time, it tires out your brain. By the time you get to actual development, you’re brain has had enough for the day and just isn’t capable of working on really big, really hard new features.

So what have we done about it? We split the team in half. Half the team spends all their day doing support so that we keep up our high levels of customer support. The other half spends all their day doing development so we can actually have a chance of getting that really big, really difficult feature done. 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. Instead of feeling like the big feature was turning into a big death march, there’s some hope of getting it out on time.

There’s some very serious down sides to this approach though. We’ve just sacrificed half our team to doing support  - that’s a tough job to do, particularly when you’re a passionate developer that loves creating new stuff. So it’s a big ask for them to just focus on support and the team and the company needs to appreciate that – a lot (and we do). The other major downside is the lack of knowledge sharing. We had been rotating pairs around the entire team and we were making real progress at bringing everyone up to speed with all our products. We’ve had to sacrifice that to make our short term goal and it will come back to bite us in the future. Friday afternoons is now code review time where we go back through what we’ve done for the week and explain it to the rest of the team – it’s not as good as pairing with them, but it’s better than nothing.

The most serious risk with this though, is the risk that quality will drop. There’s no point in shipping this really big, really difficult feature if it isn’t also really good and really reliable. We need to keep up our discipline while under the stress of a tight deadline and while we don’t have the whole team providing their unique skills to the development work. That means a lot of discipline and constantly checking that we’re doing everything we can to get things right the first time.

We’ll definitely be constantly reviewing the product quality, knowledge sharing debt we’re accumulating and how the team is feeling to make sure we don’t sacrifice too much long term potential for a short term gain.