Pairing Pattern: Ping Pong Pairing
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!
Category: General 10 comments »
February 14th, 2007 at 3:34 pm
Pairing for eight hours a day? Is that even possible?
February 14th, 2007 at 3:52 pm
Well, I am skimming over the time to check email etc….
March 22nd, 2007 at 11:14 pm
How do you pair on things like bug fixing, where it may take so so long to even find out where the problem is?
March 25th, 2007 at 8:01 pm
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.
May 10th, 2007 at 11:46 pm
[…] 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, […]
May 17th, 2007 at 8:11 pm
[…] discusses the unusual use of chess clocks in paired software development. Labels: Chess […]
September 17th, 2007 at 10:52 pm
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.
November 5th, 2008 at 2:50 pm
[…] 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 […]
November 13th, 2008 at 1:41 pm
[…] 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 […]
December 9th, 2008 at 10:46 am
[…] 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 […]