September 19, 2007
Tips for Active Pairing
On my current project, the dev team is attempting to adopt pair programming as a standard practice. I've only been moderately successful at this and one of the issues faced is that the non-driving part of the pair (the Navigator) wasn't really sure what they should be doing when not driving. As a result, I saw a lot of "passive pairing" where the Navigator was really just kicking back and watching the Driver code until it was their turn at the keyboard. To emphasize the sort of behaviour I expect from an engaged, active Navigator, I created a BVC on the wall of the dev room. I've reproduced it here in case it proves useful for other people encountering the same questions.
As an active pair, I:
Am thinking ahead of my Driver
- What is the next test?
- What is the next requirement?
Fully understand what the Driver is doing
- Make sure they are constantly explaining what they are doing
- Slow them down if needed
Am performing a continuous code review
- Constantly looking for "broken windows"
- Refactor ruthlessly
- If a needed change is too disruptive now, write it down for later work, or...
- Add it to team technical debt board
Am fully engaged/not bored
- Ensure frequent Driver/Navigator rotation
Do not correct my Driver's spelling errors (when the IDE will pick them up)
Am aware of all the requirements of the story
- Have the story readily accessible, either printed or online
Look for similarities between this story and other stories
Keep my Driver focussed on short deliverables
- Red, Green, Refactor
- Am looking for the next check in opportunity
Make sure all the pre check-in tasks have been completed
- Automated quality tests
Critically examine the development process
- How can it be done quicker, better, etc.