One of the struggles people can have when they first start pairing, is understanding when it is time to drive, and when it is time to watch. Developing a good tempo to the act of pairing – and understanding when the change over should occur – can make it seem like a much more fluid activity. When it is working well, outsiders will see the keyboard moving backwards and forwards between the pairs (albeit perhaps slightly slower than a game of table tennis!).
If one pair member hogs the keyboard too much, the other member can feel that they are not properly involved with development. Depending on your development tools and build times, you may need to identify different points at which to pass control. The important thing is to ensure that both members of the pair get to feel equally involved in the development. Set yourselves a target for the maximum duration for each member to have control of the keyboard – ten minutes seems a good target to aim for, but a shorter duration may work better for you.
Example – Test, Implement, Refactor, Switch
When using Test Driven Development, a good way to develop this tempo is to use the acts of writing a test and making it pass to define when to change over. I’ve seen success in having the person A write the test, then have person B get the test to pass and refactor, then write the next test before passing the keyboard back to person A.
Extreme Example – Chess Clocks
This example was related to me by a colleague. The team in question had chess clocks at each pairing station. The idea was that each member of the pair got to drive for four hours of the eight hour day. To keep track, at each switchover they’d click the chess clocks to start the other persons timer. If at the end of the day if you’d used up all your time, you had to watch. Very quickly each pair worked out a dynamic in which the time became equally distributed – I’d certainly of liked some video footage though!
magpiebrain 
10 Responses to “Pairing Pattern: Ping Pong Pairing”
Pairing for eight hours a day? Is that even possible?
Well, I am skimming over the time to check email etc….
How do you pair on things like bug fixing, where it may take so so long to even find out where the problem is?
Pairing isn’t about sharing typing duties – it’s about having a continuous dialogue between developers that can help share ideas, ensure good code gets written and keeps people focused. Those benefits mean that we can actually solve problems faster working together, than when working alone.
[…] to make it a fun thing to do. One of the ways I’ve been doing this is making use of the Ping Pong Pattern. However, there are situations when this pattern doesn’t fit such as when debugging, […]
[…] discusses the unusual use of chess clocks in paired software development. Labels: Chess […]
Interesting to see the comments about pairing and debugging. I’ve found that pair debugging sessions are extremely efficient, perhaps because the initial set of possible solutions is larger, while dead-ends are eliminated more quickly.
[…] colleague Sam Newman previously wrote about ping pong pairing, including an approach to ensure that both members get exactly the same amount of keyboard time per […]
[…] navigator/driver roles when pairing – as we were able to adopt a TDD approach most pairs used the ping pong pairing approach to keep both people […]
[…] turns. One good pattern to follow is the ping pong pattern which is a way to figure out the tempo to which we figure out when to code and when to […]