Agile Pair Programming

When I think about pair programming in Agile, what I really think about are several facets, not just the usual: 2 Developers, 1 keyboard.

I think Agile developers should not only pair in some sort or fashion, but I believe that testers should pair with development as well. The benefits of pairing developers and testers in my mind are so valuable for an Agile team, here are some of my favorite reasons:

Agile Pair Programming and Testing

  1. Testers and developers will learn from each other through ‘promiscuous pairing‘ (pairing with many different developers and testers throughout a development cycle)
  2. Testers learn programming techniques – Such as how to better do automated testing
  3. Developers can go through testing tasks earlier with a tester to give guidance
  4. Test cases are covered earlier through developer pair reviewing
  5. Testers and developers create a shared language, a common vernacular that helps with communication and collaboration

What other benefits do you suggest comes with pair development?

10 Replies to “Agile Pair Programming”

  1. Neal Ford was very good on this topic last week at an excellent
    presentation he gave in Manhattan for the Agile NYC User’s Group.
    The presentation was a case study: ”Rails in the Large: How Agility Allows Us to Build the World’s Biggest Rails App.”
    He said that sometimes that it’s very effective to change pairs very often, after each day or even after half a day.

    I asked him after his talk how his company gets programmers who are good at getting re-paired on such a frequent basis, since programmers from my experience can often be independent types. Neal said that when they hire programmers, they specifically look for the kind of collaborative personality they feel will do well with paired programming, and this helps them get very good results.

    If your readers get a chance to see Neal speak, I highly recommend they take advantage! Jeff

  2. I completely agree with the post.

    Responding the question:
    Pair programming increases focus. There’s no lost time (facebook, personal email, etc).

    I suggest: Pair programming + Pomodoro Technique

  3. I find it interesting also for the business sharing part too. In our team the QA Manager is also in the client calls with the product owner and other stakeholders so she is really aware of the business and that would help the sharing of business knowledge to the team members even more.

  4. Been working at a client who has lots of off-shore folks both in development and test. Recently, a middle manager in chanrge of one of the main development groups using offshore staff, approached me about working with them on pairing. There has been a hand-off, waterfallish behavior between the dev and test folks, leading to consistent failure to deliver “done” functionality every iteration.

    So Im getting ready to do some very engineering-level training and coaching for this group of people. Part of what the client manage wants to see is pairing between dev and test folks and a more test-driven approach to the development to strengthen the unit level testing so the functional level runs into fewer blocking errors. (Right now, the functional testing cannot be completely integrated into the iteration work done by developers for avariety of reasons.)

    But the idea of pairing dev and test staff is something I’ve had clients do before, sometimes on their own, other times with a lot of urging from me.

  5. Pingback: Agile Pair Programming | Agile | Syngu

Leave a Reply