AGILE IN ACTION

Wednesday, 30 April 2008

People do pair-programming

Posted by Simon Baker

On the whole our team is pretty good at pair programming. Our promiscuity is ramping up nicely and we’re now using the concept of rolling story ownership. It works like this: At the daily standup, when a new story is brought into play, someone will volunteer to own it. Another person will volunteer to pair on that card. They’ll work on the story until the next pair-swap at which point the owner moves off the story passing ownership to his partner and a new volunteer steps in to pair. The same thing happens at the next swap and so on. Ownership of the card passes to the partner and a new person comes in to pair. The person owning the story when it’s done is responsible for demonstrating the story at the showcase.

At the end of the day I guess it’s just collective code ownership or perhaps more aptly collective story ownership. I really like it because it gets more people involved in delivering the story and, because of the frequent pair-swaps and shifting ownership, it gets people communicating. And that creates a buzz. That said, the pairing sessions themselves can still suffer from some of the common ailments, for example:

  • Keyboard hogging
  • Drivers over-doing the running commentary
  • One-way conversations
  • Procrastination through too much discussion
  • Copilots disengaging
  • Copilots playing on their handheld device
  • Copilots not thinking at a system-level thinking
  • Holding one another accountable for smelly code
  • People not remaining aware of other person’s skills and level of experience

Our retrospective today asked the question: What makes an effective pair programming session? The goal of the retrospective was to raise awareness of the people-aspects of pairing - growing a relationship, building rapport, being conscious of the other person’s needs, effective communication, etc. The team split into 3 groups of 4 people and they went away to brainstorm and create posters. After 30 minutes we reconvened and each group presented their poster and took questions from the rest of the team. The exercise worked reasonably well as all the teams identified and explored, to varying degrees, the need to build a relationship and maintain effective communication.

Here’s some of the posters:

Effective pairing Effective pairing Effective pairing Effective pairing

I wanted to emphasize the need for effective communication because, as a team, we’re highly collaborative and extremely conversation-driven, so I spent 10 minutes talking about it. Everyone knows that communication happens in many ways - language, gestures, pictures, code, etc - yet people often don’t recognize that everyone wants to get along and do their best. When people sometimes respond to something you’ve said in an unexpected way - maybe they’re argumentative or obstinate, or perhaps they look confused - there are usually good reasons. Responding in kind is not the way to go. That’s just going to make the conversation spiral negatively. Consider how the other person might have interpreted what you said. Find out what possible reasons might exist for their reaction.

A conversation is simply an exchange of information but they can be hard work. It’s important to alternate between informing and listening. If you’re saying something, don’t assume your message is received. Ask for acknowledgement. Ask the other person to play it back to you. When speaking, delivery is everything. Is your delivery causing people to not listen? Saying it louder probably won’t work. Try saying it differently. If you’re listening to someone, don’t just hear them, actually listen. Maintain eye contact, visibly show interest and focus on what they’re saying. Verify your understanding by playing it back to them, in your own words.

People label people. These labels essentially stereotype people and encapsulate how you expect them to behave. Labels are a handy means of characterizing a person but they can create negative perception. “What I don’t hear, I make up, and I hold you responsible for it.” It’s difficult but you need to at least be conscious of the labels you use.

Communication needs to be congruent. Balance your own needs, desires and goals against those of others, taking into account the context or environment in which you’re interacting. Every person is different. Every pairing session is different. You have to invest in growing a pairing relationship over time with every person in the team.

The action we took out of the retrospective was to give and get feedback within pairs after each pairing session using a 10-minute reflection on the interaction. Here’s how it works:

At the end of each pairing session the pair rip an index card in half and each person writes his name at the top of the half-card. The pair discusses the session and each person makes notes on their half-card about what worked well for them, what didn’t, and where the interaction can be improved. They do not critique one another. When complete, they exchange the half-cards providing each person with a reference to the pairing session from the other person’s perspective. When the pair comes together again they combine their card-halves and work together to improve their relationship and interaction. At the end of each pairing session, the pair writes new card-halves to drive continuous improvement.

We’ll run with this for a while and see what happens.

2 Comments

This collective-code-ownership is a very nice idea. It's pretty similar with what we do in coding dojos (http://www.codingdojo.org/). Coding dojos are meetings where programmers get together to solve problems. The whole thing is very agile, we end the meetings with retrospectives, we do TDD/BDD, baby steps and so on.
One of the meetings format, the Randori, is a time-boxed round (of 5-7 minutes). At the end of each turn, the pilot joins the audience, the co-pilot becomes pilot and a new co-pilot from the audience joins the pair.
There is an accepted paper about the dojos held here in São Paulo - Brazil at Agile2008, a good reason to go to Agile i would say ^.^.

Comment by Fabs

I'm interested to know if you had any fear-based resistance to pair programming when you first introduced it. Like the kind of reactions that I talk about here

Two really common reactions seem to be:

"I don't have to try it to know it's bad - I don't have to jump off a cliff to know it's bad."

and

"It's not my job to babysit the newbies."

Is this something that you've experienced? How did you deal with it?

Comment by Mark Stringer