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!?
Start by acknowledging that it may be tough. In her great post, Melinda Stelzer Jacobson lists 5 difficulties a team should expect to encounter:
- It’s a big change
- It’s intense
- It’s exhausting
- It requires soft skills that most of your team might not have fully developed
- 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.”
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.”
We are attempting to measure the results of our new pair programming effort and have decided to collect and analyze the following:
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.
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 :).