When I started working in the universe of software development, I witnessed a lot of siloes: islands of “experts” who would often work alone. It was “normal” for one developer to implement a story, “throw-over-the-wall” for a tester to test it, then it would or would not bounce back to the developer, and so it goes.

These days I struggle to work this way. I think it’s counter-productive. This is why I decided that a part of the Quality Foundations series has to be a post on the practice of pairing. By seeding more collaboration, we prevent defects earlier on, and the growth of a person can be way steeper.

Two people working together Photo by Christina @ wocintechchat.com on Unsplash

What is pairing?

Pairing essentially is an activity of two people working on the same task. It’s an active collaboration.

Caution alert: pairing is not easy.

It is challenging to give your attention to another person for a prolonged period of time and can get very uncomfortable (who likes to be always observed and questioned?). Yet, this is where some amazing growth happens and I’ll also touch on the motivation of why we should pair.

Pair programming

The pairing that most people think of in the software world is pair programming. Pair programming simplified is two people working together to implement/program a work item. Often the pair works on the same machine. There are different styles of how the session could be led most effectively. For example, in Driver and Navigator style Driver has a more active role of controlling the keyboard/mouse and executing the steps while Navigator suggests what should be done next.

Kent Beck was first to coin this term in his “Extreme Programming” book in the late 1990s. However, the concept of it has been there way before that. Jean Bartik - one of the first programmers in history who worked on ENIAC which was completed back in 1945 - has said:

“Betty Snyder and I, from the beginning, were a pair. And I believe that the best programs and designs are done by pairs because you can criticize each other, and find each other’s errors, and use the best ideas.”

Pairing of different roles

If we’re in a cross-functional team with various roles, it can be extremely beneficial to pair outside pair programming, too. As a Quality Analyst (QAs), I daily pair with Business Analysts (BAs) and programmers. When pairing with BAs, I collaborate on writing user stories and analyzing requirements.

When I pair with programmers, I can join them in various stages of the development activities: from a bug investigation to pair programming. Involving other roles and a pair of fresh eyes during the development helps us make sure the quality is built-in. Even if as a QA I may not know how the syntax of that particular programming language works, I can help with my quality concerns or testing expertise. It’s a win-win situation for both roles: programmers get inspiration on what automated checks to include and how to prevent bugs, as a QA I also have an influence on quality before it’s too late.

I have also paired with other roles: from experience designers to even a salesperson. When I had to pair with the latter, I was annoyed and very uncomfortable at the start because I thought it would lead us nowhere. We were investigating a bug together. They were more of a navigator, and I was the driver. Eventually, we managed to find a root cause of the issue, and it was all thanks to the salesperson’s knowledge of the product domain. Their hypothesis made during the session was correct, and I could help them prove it with data. Since that occurrence, I am much more open-hearted and minded about pairing. It encourages us to leave our comfort zone bubbles where sometimes we are stuck and stall on the progress.

Why pair?

“Isn’t pairing slowing us down?” you may be asking. Well, the answer is… yes and no. As one of my favorite sayings paraphrased from “Accelerate” goes: sometimes we need to slow down to speed up.

Imagine two developers pairing: a senior and a junior. For the senior, this story would take one day to implement. For the junior, it would take 3 days. Together they are done in 2 days. What happened here, though, is that in the short-term they were slower, yet in the long-run, they did get faster because of:

Working together with someone other than us expands our knowledge base. We learn how others think, their work tips & tricks that help productivity and efficiency, and pairing can even help our focus. We work on something together and keep each other accountable and alert.

When more than one person worked on something, there are more people available to provide context, explain why it is that way, and react in case a change is needed.

Another person can add new ideas on what could go wrong or even call out the wrongdoings on the spot. Some of the most painful mistakes we make are when we’re on the “autopilot”: we may fill in certain characteristics quickly. For example, we may configure a different key because we copy-pasted a part of code and forgot to change it. Or, we worked on something similar before and that key was in our heads instead of what it should be. The pairing partner can spot this and help us avoid those mistakes before they reach production. That results in a way higher quality work because it was reviewed on the go.

These are just a few benefits of pairing. More can be found in a very detailed article on Pair Programming by Birgitta Böckeler & Nina Siessegger.

In conclusion: to pair or not to pair?

Pairing can be frustrating and also may make us feel like we’re slower than doing the task alone. Yet when we work in teams and organizations, we’re never alone. Bringing others on a journey with us and getting involved in their journeys fosters a culture of continuous improvement & collaboration, which cultivates high-performing teams.

Try experimenting with pairing and how it makes you feel. Just give it time - in the short run it may not have huge results, but it will help in the long run. Also, it could be that your culture is not yet ready for such high collaboration and pairing in every single thing you do, but step by step with little experiments it could take off. Pairing is one of the first steps to try out - just join others or invite others to join your tasks, and see how it affects your work.