The question of how often you need to rotate pairs has to be answered by the development team. I’ve heard some teams say their pairing rotation was 90 minutes and others would rotate much less frequently. My preference is to lean towards pair continuity on either the story or task level, having a pair work a task from start to finish. Of course, I also think stories or tasks should be ruthlessly subdivided to fit within a day or two of coding effort (iteration management is a topic for another day), so that still leads to pair rotation at least every other day. I think it’s convenient to define the pairs immediately after the standup meeting in the morning or right after lunch. Don’t let any kind of schedule like this idle your developers though. I’m a morning person and I’ve always been more effective in the early morning with a fresh mind. Keep a backlog of non-pairing work around so no one is ever idle waiting on a pair to do something useful.
I think the only constant in pair rotation is that the developers need to be self-organizing and manage themselves in this respect. Having one person, whether the development lead or project manager, assign the pairs as a dictator doesn’t seem to be as effective as a more egalitarian approach. What I’m really trying to drive at is not to automatically give the most challenging coding work to the most senior guys because it never affords the others a chance to learn and it can breed resentment.
One thing we did on a project last summer was to designate one developer as a story owner for the duration of a user story throughout the iteration. I thought that turned out to be a great way to balance continuity with pair rotation.
I’ve heard a practice described several times is having some kind of bell or buzzer that rings to tell the developers to play musical chairs. I think that’s obnoxious myself, but whatever floats your boat.