This is a guest post by Jim Holmes.
Pair programming is often thought of as an exercise just between two developers; however, in my experience, I’ve seen tremendous benefits when different roles pair up.
Several years ago I was a consultant involved in a multi-year engagement at a multinational global enterprise. One of the many efforts we began was cross-discipline pair programming between testers and developers. The benefits became obvious after a year working through a number of structural and cultural issues. I regularly use this experience as a case study in the benefits of pairing across roles, as it illustrates many of the great gains that organizations can see by encouraging, or better yet expecting such behavior.
A Team Journey
Software delivery teams at this particular client were, for the majority, behind in modern practices, and also behind in professional skills required for improving the organization’s ability to deliver high-value software. Developers and testers had low technical skills and were often woefully behind in domain-specific skills such as testers understanding basic system-wide data flows, developers grasping SOLID concepts, etc.
Over the space of two years’ hard work from coaches, management, and most importantly the delivery teams themselves we saw a dramatic transformation. Many improvements were made, but I have specific examples due in large part to an intentional, concerted effort to get developers and testers to sit down and pair up on development and testing tasks.
Developer Benefits
Some stereotypes are based on bits of truth. One of those is developers focusing mostly on happy path testing: writing automated checks that don’t catch all boundaries, or are simplistic and don’t use more advanced concepts.
It’s not surprising, as a testing mindset isn’t part of most developers’ professional experience or education. Sure, Test Driven Development and similar approaches help developers think about overall better testing, but it’s still uncommon to have developers thinking far outside the happy path box.
On this project, developers who paired with skilled testers learned to think far past the happy path, and began exploring testing (automated and exploratory!) in boundaries, abnormal conditions, and even extending into advanced test case design using approaches like combinatorial or pairwise testing. That was an extraordinary benefit!
We also found developers who regularly paired with testers began showing a deeper understanding of the broader business and user domain. Instead of being just focused on the technical aspects immediately in front of them, junior and mid-level developers took a broader view of the system and were, therefore, able to better understand inputs, outputs, and other interactions outside the immediate system. The developers also started to better understand the needs of the users–something often left to testers as “customer proxies.”
Tester Benefits
Our testers were initially very resistant to pairing with developers. They had a large batch of fear based on their own skill levels, and that caused difficulties getting the testers to sit down and work with developers. After moving through a number of challenges, the testers themselves became very excited about the benefits they experienced as a result of paring with the developers.
Very shortly after even narrow pairing sessions started, the testers proclaimed their dramatically improved understanding of deeper technical issues around the system. They better understood the overall architecture, they better understood how data flowed from the database up to the custom Javascript in the browser’s UI, and they had a far better understanding of how to approach test automation and exploratory sessions to validate different service boundaries.
Additionally, all the testers were very happy with their improved SQL skills, as they’d spent significant time with the developers and DBAs working on low-level functionality specifically at the database level.
One of the largest benefits was the software craftsmanship skills testers began to gain. Automated tests became far more flexible, maintainable, and valuable thanks to time learning SOLID principles such as single responsibility and Don’t Repeat Yourself.
Overall Benefits
Some wonderful synergy began to display in the team through this two-year journey. Not all of it was due strictly to cross-discipline pair programming, but much of it was directly influenced by that work.
First, the team became much more consolidated and less antagonistic thanks to empathy and understanding that grew as team members sat down side-by-side to accomplish various tasks.
Close pairing collaboration was a critical influence in regularly achieving a zero-bugs-in-production state, something the team hadn’t been previously close to, ever. Moreover, that collaboration also boosted end-user satisfaction, as users were much happier with the software they were now being delivered.
Perhaps the most “meta” benefit was a culture that now focused on preventing bugs instead of finding them. Close collaboration across all roles dramatically boosted communication, and critical discussions were being held in very early planning meetings. Additionally, testers, developers, and business analysts were participating in Three Amigo discussions for every work item, in effect pairing before any code was written. This close collaboration ensured solid mutual understanding around feature expectations, acceptance criteria, dependencies, and testing approaches.
How to Get There
Please don’t read this article and assume that I’m trying to sell this approach as magic. It was hard work to get to the results at the end of my involvement, and by no means was I the main impetus behind this.
Start with small steps, especially if the organization’s culture hasn’t been supportive or open to this kind of interaction before. Perhaps start with something simple like a Three Amigos conversations for critical work items. (If you’re not familiar with Three Amigos conversations I encourage you to search out articles. You can find them on Scrum.Org, Agile Alliance, and many other sites. I even wrote an article on getting started with Three Amigos on my personal blog some time ago.
Don’t try to get pair programming, cross-discipline or not, running 100% of the time. It’s exhausting, even once you get past the psychological safety issues many will have. Focus on one test case, perhaps, or one specific part of a bug fix.
Small steps lead to trust, and trust will lead to wonderful results.
You may also consider giving mob programming a try if you find this idea interesting. Mobbing takes this collaborative approach several steps further and encourages a group of delivery team members to work together on specific tasks. All roles, even ones considered non-technical such as business analysts or program managers, are **expected** to participate. Again, there are many good articles and books on mobbing for you to investigate further.
Cross-discipline pair programming can bring tremendous benefits to your teams. It’s hard to get started, but it’s worth the investment!
Jim is an Executive Consultant at Pillar Technology where he works with organizations trying to improve their software delivery process. He’s also the owner/principal of Guidepost Systems which lets him engage directly with struggling organizations. He has been in various corners of the IT world since joining the US Air Force in 1982. He’s spent time in LAN/WAN and server management roles in addition to many years helping teams and customers deliver great systems. Jim has worked with organizations ranging from start-ups to Fortune 10 companies to improve their delivery processes and ship better value to their customers. When not at work you might find Jim in the kitchen with a glass of wine, playing Xbox, hiking with his family, or banished to the garage while trying to practice his guitar…..
