Thursday, May 10, 2012

Pair Programming: How To Do It Right


Pair programming is an XP practice of putting two people in front of a computer, and having them program together. If you haven't seen it work before, it sounds wasteful. It is wasteful if you have one person writing code while the other passively watches, but there are some practices that make it a lot more valuable. When done right, I consider "paring" to be vastly superior to solo programming.


The way I have done pair programming goes hand-in-hand with test driven development. Here are the techniques I have used.


Ping-Pong Pairing

This is a beginner technique. It can get you in the groove for a day of pairing, and it's also useful as an introductory technique to pair programming.


Here is how it works:
  1. Developer A: write a failing test
  2. Developer B: make the test pass
  3. Refactor together
  4. Developer B: write a failing test
  5. Developer A: make the test pass
  6. Refactor together
  7. Rinse and repeat
The idea is to make a game out of it. Write the simplest possible piece of code to make the test pass, and do so as quickly as you can.


Navigator / Driver

Notice that this isn't "Observer / Driver", as I have sometimes seen it described. I don't like "Observer", because it implies a passive role. At it's best, the person who is not writing code should feel like they are working harder than the person on the keyboard.

This is an intermediate-to-advanced strategy, and the way that pair programming works in a high-functioning team. The roles are:

Navigator
  • Thinks strategy: "What do we need to test?"
  • Keeps the overall objective of the story in mind.
  • Keeps track of potential refactorings along the way.
  • Does NOT tell the Driver what to code.


Driver
  • Thinks tactically: "How do I write this test?"
  • Focused on the next small step.
  • Keeps up a dialogue with the Navigator, describing what he/she is doing.

The key is to switch roles periodically. You don't want to do it too often, or you risk getting out of a good rhythm. You don't want to do it too seldom, because it's too easy for the Navigator to become disengaged.
Good times to switch are when:
  • There is a change of concept.
  • "I need a change."
  • A timer beeps (this isn't a bad way of starting with this technique, but not best for long-term).

Wednesday, May 9, 2012

Team Accountability: Be Courageous, But Don't Be A Jerk

I have been helping to lead an agile transformation / continuous improvement effort for the past couple of months.  It has been a great experience, and I want to capture some of the things that I'm learning as I go.

In yesterday's stand-up, one of the coach/developers brought up a problem he saw.  One of the team members appeared to have waited too long to ask for help, working on the same story for several days.  It went something like this:
We need to spend more time listening to each other and ourselves in stand-up.  If you find yourself saying "I'm almost done" two or more days in a row, or if you hear someone else doing it, that's a red flag.  For instance, I was pairing on a story with Bob last Friday, and I heard him say today that he was almost done with it.  He and his pair need to say "we're blocked", and reach out for additional help on their story.
I thought it was well put, but Bob (not his real name) was pretty upset about it, and felt that he was being called out.  I brought it up again in this morning's stand-up, and made it clear that what was being called out was the behavior, not the person.  I even said that "Bob wasn't being singled out - we need to call out improvement opportunities as we go so we can all learn."

He wasn't completely satisfied with that response and we've gone back & forth a couple of times over it.  I consider this a very good thing.  Minimizing conflict and argument in the interests of getting along is a bad practice.  It is far better to call out problems as you see them, provided that you keep the following in mind:
  • Always criticize a practice, rather than a person.
  • If you use a person as an example, be sure to make it clear that this is an example of behavior that anyone on the team could end up engaging in if we don't guard against it.
  • Be polite.
In the case above, "Bob" may have already asked for appropriate assistance, but the coach wasn't aware of it.   That really just highlights another problem about communication in stand-up - if you're blocked and find help, but you're still not done, say so.  Someone else may have something to offer, and the whole team should know that you're working on a particularly thorny problem and may call in more points of view.

The purpose of stand-up is to enable good communication.  This helps us hold each other accountable, which is another way of saying that we help each other to be good team players.