Pair Programming: first steps

https://www.flickr.com/photos/308entre2/2820470279

https://www.flickr.com/photos/308entre2/2820470279

This is the first of a series of posts on the subject of pair programming and how one team went about doing it from scratch. I’ll be your host as a Scrum Master coaching a team. This team mentioned in a Retrospective that it thought it would be helpful to work together more and the question was asked, “Should we try pair programming?” My Scrum Master heart strings were twanging as the team went about discussing how it might go about it in the coming sprints. At the end of the brainstorming, one question loomed large:

Where do we even begin!?

First steps

Start by acknowledging that it may be tough. In her great post, Melinda Stelzer Jacobson lists 5 difficulties a team should expect to encounter:

  1. It’s a big change
  2. It’s intense
  3. It’s exhausting
  4. It requires soft skills that most of your team might not have fully developed
  5. All change is hard

Her article is excellent. Please consider reading it.

She goes on to list the benefits she and others have observed and even studied and some helpful suggestions and techniques to follow. It’s an excellent read and I recommend it to anyone wanting to seriously engage in pair programming, whether you’re starting from scratch or stepping into a mature team of pairers.

Our Pair Programming Experiment

I’m Scrum Mastering for a team that is interested in trying pair programming. In recognition of the difficulties common to teams engaging in pair programming, I’ve suggested some guidelines.

Commit to a focused timebox of at least 1 to 4 hours

The commitment to pair must come first, either as a pure commitment to experiment or in simple recognition of the challenges the pair will face. Choosing at least an hour ensures that the pair has time enough to “zone in” on a reasonably complex problem. Choosing no more than 4 may guard a pair from overexerting themselves before suitable skill in the practices is obtained. This last suggestion may only be necessary in environments where pairs would be forced to pair for extended periods of time when they are not yet ready or willing. Admittedly, here is why the advice is a bit squishy and should definitely be read as a guideline and not a rule.

Problem solve instead of mentor…for now

Helpful person: “But Jason, the act of pair programming brings with it active and passive learning just by doing it. In essence, pairing is training.”

Me: “You are correct; however, great disparity in skill can bring an additional challenge into the pairing effort. A relationship of mentor and apprentice may develop and become to easily the focus of the pairing rather than the solving of the problem.”

Helpful person: “So a junior programmer and a senior should never pair!?”

aside: this is a straw man defense

Me: “When only beginning a pairing effort, it may be helpful to concentrate on solving rather than mentoring, since mentoring brings additional challenge. Eventually once pairing is well understood, it is an excellent tool for mentoring and continual learning.”

Pair co-located

Using tools to pair across locations can be done but brings additional complexity into the equation. If you can find someone in close proximity, you may find it easier to concentrate on the act of pairing rather than testing the limits of your telepresence tooling.

Use library voices

Do be sure your location affords for the wonderful new interactions your pair programming will require. Generally, normal conversations don’t disrupt those around you; however, be sure to be conscientious :). Consider asking around if your new pair programming activities are bother others and do what you can to accommodate their needs.

Aim for constant code review

Consider thinking of pairing with that person to whom you would have asked for code review when programming solo. You will find that the cycle of “code -> review -> code -> review -> done” is replaced with a much more effective and efficient alternative: “code -> done.” While you’re at it, consider including any QA professionals #scrumbut in your pairing effort in order to replace your now improved cycle of “code -> done -> test -> code -> done -> test -> done done” with the much preferable: “code -> done.”

Love the one you’re with

Me: “Try to pair with someone with whom you suspect you’ll enjoy working!”

Helpful person: “But isn’t one of the benefits of pair programming enhanced team cohesion?”

aside: again, with the straw man

Me: “Why yes, it is; however, when first learning to pair, you may see quicker progress towards that goal by choosing a partner with whom you will experience less friction in your collaboration.”

Measuring Results

We are attempting to measure the results of our new pair programming effort and have decided to collect and analyze the following:

Satisfaction

I’m administering a simple, daily poll which asks only two questions:

  • How are you feeling?
  • Are you pair programming?

The poll instructs those answering to answer the first question on a scale from 1 to 5 using the following criteria:

1 (fist): (╯°□°)╯︵ ┻━┻ You are likely to storm out of office, yell at a co-worker, or eat a gallon of ice cream when you get home.
2: ಠ_ಠ Something is bugging you badly enough to be a constant frustration
3: ( ͡° _ʖ ͡°) Neither good nor bad. I really don’t remember much about that day really
4: ◔‿◔ Things just clicked, something great happened, I feel like celebrating!
5: ᕕ(ᐛ)ᕗ I may never forget this day, I’m on top of the world, nothing can stop me or this team

The goal of this metric is to uncover struggles with pairing rather than to determine if pairing is likely to increase satisfaction. The poll is anonymous to allow those to answer honestly, free of a pressure to appear successful. A positive side effect is to remind the team of their commitment to the experiment in an unobtrusive and non-judgmental manner.

Issue Churn

The team uses Jira and has made a few modifications to better track and visualize the feedback loops present in its current workflow. Specifically, it has:

  • Added a new, numeric issue field called “Rework.”
  • Added a new post function on the transition between essentially the “Coding” stage and the “Testing” phase; every time an issue is handed from a coder to a tester, the “Rework” field is incremented. If work is handed back to a coder to correct/complete, the “Rework” field gets incremented to 2 before the issue can be completed.
  • Configured the card layout on its Scrum board (in Jira) to display the “Rework” field
  • Changed card colors on its Scrum board to correspond to queries like “Rework = 1”, “Rework = 2”, etc
  • Added board quick filters to visualize issues attempted i.e. Rework >= 1 and issues specifically done without any rework i.e. Rework = 1

After making these changes, a new goal metric is visible and may be tracked against, issues Done Right the First Time (DRtFT). The hope is that, in pursuit of increasing the number of issues DRtFT, the team will needs improve its processes in order to cut down on costly rework. This is of course, one of the great benefits of pair programming

For the future

Starting is half the battle, and there are future battles to come. The team is curious to know if pair programming will noticeably affect not just the quality of their lives and processes, but also the quality of their work. We are taking aim at measuring data that will reveal correlation (or not) between pair programmed work and quality of code, # of defects, etc. We have some ideas of how we might measure these dynamics although we have not yet got systems of measurement in place.

Please consider commenting on our first steps and contributing to our future success :).

jknight

Jason is a developer, Scrum Master, writer, teacher, coach, husband, father, and community leader out of Tulsa Oklahoma. He's been delivering software since 2007 and absolutely loves the values and principles of agility especially as given form by the Scrum framework.

  • Craig Rawstron

    Pairing is not just programmers.

    I teach BDD, and encourage QA’s and Coders to develop tests in advance as pairs, then move the QA to something else – then encourage Coders to pair together to write something that makes the tests pass.

    I involve the PO, and any other interested parties to define the tests along with the coders – and put a stop to “nice to have” coding, or “Just in Case Code” (Specification Workshops).

    The end result is that there is almost no rework. It the code cannot put the green light on a test, then something is wrong. Get people involved, from all skill sets.

    I could go on and on, and have written a lot over the last 5 years on LinkedIn about this, so don’t want to keep repeating myself.

    But I will provide the two links I always do, as I know these people. Dan North (BDD) and Gojko Adzic (Specification by Example).

    We have all worked as Coders, QA’s, PM’s and Agile Coaches

    http://specificationbyexample.com/.

    and

    http://dannorth.net/introducing-bdd/

    Good luck out there.

    • Agreed! I’ve had massively satisfying experiencing pairing with my PO as a developer. We sat, talked, I programmed, and we succeeded quickly!

      A team I worked on (at a previous company) is now Sprint Planning by spec’ing out a serious of failing tests. These are acceptance level tests. They even go so far as to measure progress toward their Sprint Goal by examining tests they have yet to make pass. This is a nirvana I hope to reach in each team I work with.

      Thanks for the links. I will definitely read them.