I’m going to apply the concept of distinguishing resistance from lack of clarity as in Monday’s post/video. I’ll explain why pair-programming often intimidates and two tips that reduce the fear.
In the video linked in the previous blog post, Resistance vs. Lack of Clarity, we saw that when trying to institute a change, a lack of clear direction confuses people about what the new behavior should look like. This confused state looks a lot like resistance.
For example, say you’re trying to influence your team to take up pair programming because of its many benefits (as listed in Pair Programming Illuminated):
- Improved quality
- Improved productivity
- Improved morale
- Improved trust and teamwork
- Improved knowledge transfer
Everyone agrees to take an afternoon to try pair programming, so you block everyone’s calendars, but when the day comes, everyone suddenly has somewhere else to be. What happened? Perhaps you could have been more clear about what pair programming entailed.
The Role of the Navigator
For starters, many people are confused on what the navigator, that is, the person who is not doing the typing, is supposed to do. This confusion, besides leading to resistance to pairing in general, can also weaken the benefits of pairing. Often what happens is the navigator follows along as best they can for a while as the driver takes complete control, then their ability to concentrate weakens over time, eventually leading to “zoning out”.
What can be done? There are a couple of approaches for getting the navigator more engaged.
“Strong-Style” Pairing
One is “strong-style” pairing, described by Llewellyn Falco in Llewellyn’s strong-style pairing. In “strong-style” pairing, the driver does nothing that the navigator did not tell them to, or as Llewellyn puts it, “For an idea to go from your head to the computer it must go through someone else’s hands.” This fully engages the navigator. When the driver needs to contribute an idea, they must relinquish the keyboard to the navigator and then do the directing from the navigator position. Maaret Pyhäjärvi described the difference between traditional pair programming and Strong Style as a change in the conversation like the image below:
“Ping Pong” Programming
Dave Hoover tells a story about picking up the ping-pong programming technique from Aslak Hellesoy in Ping-Pong Programming: Enhance Your TDD and Pair Programming Practices and then finding it documented on Ward’s Wiki as the Pair Programming Ping Pong Pattern.
For teams that practice Test-Driven Development, “ping-pong” pairing provides a great alternative for engaging the navigator. In “ping-pong” pairing, the “write a failing test”, “make it pass”, “refactor” loop is used to fully engage both partners. Partner 1 starts out as the driver, writes a failing test, and hands the keyboard over to partner 2. Partner 2 makes the test pass, does any refactoring, writes the next failing test, and hands the keyboard back to partner 1. Partner 1 now makes the test pass, refactors if necessary, writes the next failing test, and returns the keyboard back to partner 2. And this repeats throughout the pairing session.
If you teach these simple techniques to your team, you may find that you can make pairing less confusing and thus less intimidating to teams that are beginners in pairing. And what you thought was once resistance may turn out to have been a lack of clarity.
I would love to hear what you thought of the article, so feel free to comment below, on The K Guy Twitter, or on The K Guy Facebook fan page.
Pingback: Find The Retro Feeling - The K Guy()