It’s becoming more and more common to hear stories of Agile being used to transform the world of teams and business outside the traditional Agile world of software and product development. Often, recommendations for “nontechnical business groups” stop short of some of the engineering practices in the Agile framework. At least one of these practices – “pairing” deserves consideration by general business teams as they adopt an Agile framework.
In the world of software development, “pair programming” refers to the practice of two software developers creating software by sharing one workstation. One developer is the “driver” – sitting at the workstation, entering code into the system. The second developer is the “navigator” – operating at a more abstract level of discussing requirements, implementation options, testing approaches and so on. Ideally, the two developers collaborate to create and implement an elegant, high quality solution that is superior to what one person would produce in solo developer mode.
Management often questions the value of pair programming – believing that the productivity of the team must be halved since two people are working one workstation. Studies show, though, that any extra time expended in implementation are more than offset by improved code quality, performance and supportability.
So how might this work outside the world of development? I once worked in a consulting group who agreed to use “pairing” as part of the practice of closing the company’s financials in Quickbooks each month. Please understand – for me – this was a big deal. As far as I was concerned – Quickbooks is an evil application designed to torment business owners. Every monthly closing seems to be challenged with oddball corner cases and weird transactions resulting in chasing 59 cents across multiple reports to get everything to balance correctly. I avoided being part of the “closing pair” as long as I possibly could.
Then one month – EVERYONE else was out of the office and I was the only choice to pair with the Operations manager on the monthly close. The choice was to avoid pairing and a story in our sprint would be incomplete – or bite the bullet and pair on the closing. I gritted my teeth, warmed up my calculator, and sat down to pair. I was the navigator and immediately was drowning in terminology, reports and transactions that made no sense to me. I worried that I was killing our productivity when my partner had to start explaining everything beyond “profit is good; loss is bad” to me.
We made slow but steady progress until we hit a point where data from previous months seemed to be changing and it looked like Quickbooks was locked a battle with Event Brite. We rolled up our sleeves and I started asking troubleshooting questions to help trace the path of the conflict between the two systems. All of a sudden, a light bulb went on for my partner – and the issues were quickly resolved and the month closed perfectly. My partner turned to me and said, “Thank you for working with me on this. Your questions helped us find the issue way faster than if I had had to do that on my own.” What she really meant was “Thank you for asking all those naïve, simplistic questions. Despite the time sink of teaching you the basics of Quickbooks, pairing with you actually saved me some time. Yay us.” Or at least that’s what I think she would have said!
So what’s the moral of this story? Even outside the world of product development, pairing can be a powerful tool for Agile teams. Pairing can reduce the amount of time needed to debug issues and create solutions. It can result in higher quality results. It definitely facilitates team communication and helps cross training on the team. And in the case of Quickbooks, it gives team members moral support when they are chasing those pesky 59 cents across P&L statements to get the numbers to balance!