I just finished reading Joel Spolsky’s discussion defending the ability of programmers to context switch, in response to Dmitri Zimine’s story about wasting two weeks with a two hour job. They’re both right on some points, but I have a few points of my own to throw in the mix based on the short time we’ve been adopting XP practices.

Yes, the good programmers can context switch easier than most and yes, it does take time to learn just how much development time that costs. But no, it doesn’t have to kill an iteration and no, it doesn’t have to delay the output of the iteration either.

Our development team has managed to train our manager quite well, at least to the limit that our estimation allows. We’ve trained him to only give us development tasks on cards, even features requested by clients. We’ve managed to come up with a workable point system so he knows roughly how many points are available for each day of the iteration.

And most importantly, whenever something like an urgent customer request comes up we never drop anything, but just give him a card with a rough point value. Often we write cards just for investigation into the feature, before we even think about implementing it. But instead of forcing it into the backlog for the next iteration, we give him the option to take some cards out of the current iteration and put this new card there instead.

Of course it’s never quite that simple; if we’re nearing the end of an iteration there won’t be enough points to take out and sometimes we leave the poor guy with a choice between not satisfying this customer request or dropping features from a release. But that’s what he gets paid for, so we try not to stress about it 😉

My point is that we have flexible iterations. Maybe I haven’t gone far enough through the XP documentation to understand why static unchanging iterations are a good thing, but I get the feeling that no matter how you slice it Joel is right on that point. Locking developers into a list of tasks is going to hurt your customer satisfaction.