Peter, Mitch and I gave our talk on the pairing game at Agile 2006 this year, and the session was well received (deck). I think the stars aligned for it:
- The right audience. Our talk doesn't really focus too heavily on introducing the concepts of pairing and TDDing, but instead on our modifications to pairing. If you're not familiar with the concepts, then you can get a bit lost by the nuances of the problems we try to solve with the game.
- The right size audience. Peter made the comment that the talk is much harder past about 50 people, and I agree. With an audience of 25-50, you can be very interactive. We pushed the outside envelope of audience size, but it still felt very intimate.
- The right message. We finally were able to distill what is most important about the game (which I'll describe below). What helped was discovering that the basic technique already existed (Ping-Pong Programming), which led us to be able to differentiate against it effectively.
- The right environment. We've given a variation of this talk in many forms, and I think this one works the best. In essence, we had a very tall table that was used for the pairing laptop (my shiny new MacBook Pro running Windows XP). This was better than sitting at a table, and better than using a podium, which hides the computer.
- The right deck. I can't stress enough how amazing Cliff Atkinson's Beyond Bullet Points can be. We had multiple comments when we were done about how engaging the deck was for people in the audience. All the photography in the deck is from stock.xchng (highly recommended).
The essence of the game is quite simple. When doing Test Driven Development, you have a state machine that is sometimes called "Red/Green/Refactor". The idea is that you start with all tests passing (green state), write a test that fails (red state), write just enough code to make the test pass (back to the green state), and then refactor as desired (whenever you're in a green state).
What we say is that you have discrete activities: writing a test, making the test pass, and refactoring. After performing any one of these actions, you pass the keyboard to the other person. In the red state, you have to make the test pass; if you're in the green state, though, you can choose to write a new test or to refactor. This process is what Ping-Pong describes. The keyboard passes very quickly; if you have the keyboard more than about 5 minutes, you're probably doing too much.
Our addition to the process talks about why you're doing this, other than "doing something extreme, in an extreme fashion". The purpose of the frequent keyboard passing is to provide an explicit state for scope negotiation. When player A writes a test and gives the keyboard to player B, that's a great time for them to discuss whether the test is taking them in the right direction, what it means to the architecture of the code, whether the step is too big, etc. Similarly, when player B makes the test pass and hands the keyboard back to player A, that person can also negotiate over whether too much work was done, or whether they even like the work done at all.
This frequent negotiation overcomes some of the limitations of traditional pairing. When you do the traditional style of pairing, the driver might have the keyboard for an extended period of time (30 minutes? an hour or 2?). Without explicit hand-over guidance, it's very easy for an extroverted driver to take over the pair. By forcing the hand-off, you tone down your extroverts and empower your introverts. You make sure nobody has the opportunity or desire to check-out of the process when they're the observer.
Even though the process sounds very simple, it can have a dramatic effect on the quality of your pairing time. I found that this style allows the team to stay engaged and get a lot done in just a little time. A warning, though, that this style of development can leave you feeling both mentally and physically tired at the end of the day. Remember to take frequent breaks.
All that we're missing now is a good name for the technique...