After working under the agile methodology for a year, our team started looking into pair programming. Our manager had attended training at a company that did pair programming full time, and the owner had written a book on it. He brought the book back and passed it around the team, all the while evangelizing the benefits this company had seen.

The developers were very nervous, and that nervousness was felt throughout the team. We were very used to putting our headphones on, sitting in our cubes, and working away at our assigned stories. This method seemed to be working fine, so why change it?

One of the big proponents of our trying this new method was our manager. He was very enthusiastic about trying new things, and after reading of the benefits others were gaining from pairing the developers, he started the conversation with the team. We agreed as a team in a sprint retrospective to give it a try.

For our team, we defined pairing as two developers working side by side on one computer for all forty hours of the week. No code would be written without both developers present. We would also rotate developers every sprint to give everyone a chance to pair with everyone else.

We set forth with no definite endpoint but knowing we were going to be in it for a quarter of a year, at least. A quarter turned into a year, and we did a pairing retrospective at the end of the trial year. We listed on a board all the pros and cons of pairing that the developers could come up with. The following are observations that came up in the retrospective.

Velocity

Before we started pairing, our team was doing around 40 points every two-week sprint for our velocity. We knew going into it that we were effectively cutting the development team in half, so our velocity was going to take a big hit. It worried us a bit, as our business owner was not going to like a lower velocity. Much to our surprise, we completed 40 points’ worth of stories as pairs. This continued to hold true sprint after sprint.

What we found is that pairing reduced a lot of the downtime developers can have during development. When stuck on a problem, instead of taking a walk to think it over or sleeping on it, we had someone right there to talk it over with immediately. We were having constant conversations about problems, design, and patterns. The reduced a lot of downtime. You also didn’t have anyone going through email for long periods of time, as your partner isn’t going to sit there and watch you do that. We were able to keep each other accountable to getting code put in and getting the story completed.

Training

A huge benefit we gained that we didn’t even think about was how pairing would affect onboarding of new developers. When new developers were brought onto the team, we had all the usual things to help them out, including developer onboarding guides to get their machines set up with all the software and tools they would need. We had lunch-and-learn sessions to introduce them to the architecture and the third-party applications we supported.

A new developer would start producing equal to his or her peers after being on the team for six weeks, or three sprints. After we introduced pairing, we noticed this ramp-up time was cut from six weeks to only three! Pairing new developers with our senior developers taught them the architecture, standards, and tools much more effectively than a few one-hour discussions and having them poking around in the code base.

Quality

The majorly touted benefit of pairing is the quality it brings to the software the team produces. We always stressed code reviews, unit testing, and documentation before pairing. Sadly, it almost always fell by the wayside. Again, the pairing brought accountability to this effort. We now had 100 percent code reviews on all code being written. Coding errors were being caught well before the code was checked in, let alone put into a testing environment.

Another thing we were holding each other accountable for was unit testing. This was another item we agreed to do before pairing, but it was hit or miss in actually getting done. We have some developers who made a game out of unit testing. One will write a failing unit test, and the other will write the code to make the test pass. Then the code goes back to the first developer to either update the unit test to fail again or to write another unit test that would fail. The pair would switch roles throughout the day.

Quality was our biggest gain in this process. With better quality software being developed and pushed out the door, there was less need of the developer’s time to spend investigating testing or production environment issues. We were shipping fewer bugs, which took less developer time to debug, which meant we had even more time to devote to getting stories done in the sprint.

Technical Debt

Before we started pairing, we had a team architect. He designed the architecture, got the developers’ buy-in, and ensured we were following the standards in using it when we developed stories. The team was still rather small, so it was easier to ensure we stuck to the software design. Then we had two things happen: the team grew with more developers, and the team architect started getting more involved in enterprise projects, which gave him less time to devote to the team.

Due to this, as individual coders, the rules around the architecture started being bent and broken. This was especially true for new employees who were unaccustomed to the architecture. As each solution was developed that strayed from the common architecture, the amount of technical debt started to grow. As developers went in to make updates, they would notice things were wrong, but they had no time to fix them. We wrote stories to address the issues and get them refactored, and they were placed in the technical debt backlog.

Then, once we started pairing, we also noticed the rate at which the technical debt was growing slowed down immensely. This was due to accountability, as well as another awesome benefit: In pairing new or junior developers with senior developers, the architecture could be taught, and the ways to stay within the framework were passed on. The technical debt backlog was still being added to, but now it is a rare event to see. With less technical debt, this frees up more of our time to take on more business value stories, and as our software framework grows, we are building upon a solid foundation instead of having to deal with a code base that is held together with gum, duct tape, and prayers.

Conclusion

Negatives to pairing did come up in the retrospective. One included senior developers feeling they had to slow down when paired with junior developers. Some of the developers have a hard time expressing vocally the thoughts they have running through their heads about the problem at hand. Having a developer call in sick or having snow days also greatly affected a pair’s ability to produce. And of course, some of the developers’ personalities didn’t always mesh well with each other.

With all the pros or cons to developer pairing up on the board, we were asked the big question: Did we want to continue with pairing, or did we want to stop? Because it was the developers who had to pair, the vote and choice was given to them.

We were a bit surprised, though quite delighted, when the developers unanimously voted to continue with pairing. They all agreed the positives we gained completely outweighed any of the negatives. We are now closing in on two years of pairing, and we are not looking back.