Pairing in Agile (also know as Pair Programming) is the concept of two Developers sharing the same desk, computer, keyboard and mouse to write code. It is a means of sharing views, opinions and approach to ‘problem solving’. Sounds nice but should Agile pairing be reserved for Developers only? Is there any value if a BA and Developer pair? How about a QA and Product Owner? Does it always have to be around programming?
Point of Pairing
Firstly, the purpose of pair programming is to write code which results in fewer bugs. How? The idea is that whilst one Developer writes code (known as the Driver), the second is observing (the Passenger). This idea of Driver and Passenger helps to review code as it is being written.
Let’s take a moment to talk about the benefits of Agile pairing and the effects it may have on a team.
Pitfalls of Pairing
Where there is love, there is also hate.
When pairing, you are effectively reducing your man-hours by half as there are two Developers working on the same task at the same time. This may potentially cause only half the amount of tasks to be completed in the same time if no pairing had taken place. In addition to this, both Developers must be available at the same time in order to pair. If either Developer become unavailable for a period of time, the other Developer may be blocked and unable to proceed.
Pairing is also a subscribed method. In order to pair effectively, both parties must be ‘willing’ to pair. If either party do not wish to pair but are ‘forced’ into it, they may not communicate as effectively, they may not want to learn or teach etc. Pairing in this instance can become more of a laxative than a enhancement.
What about it’s benefits?
Power of Pairing
To almost every disadvantage to Agile pairing, there is a flipped advantage.
Let’s take the concept discussed above of reduced man-hours. Yes, pairing can lead to reduced man-hours but at the same time having two Developers looking at the same problem at the same time can lead to them both going faster. What does it mean to ‘go faster’?
Let’s assume a long discussion needs to happen on a task, is it easier to work through the problem together or to talk about it over email or some ‘chatting’ application? How about if a Developer is stomped by a problem whilst in the middle of coding? Would they be able to delivery the task quicker if two had worked on the same problem instead?
By having two Developers working on the same problem at the same time, you are essentially increasing the probability of delivery that task in an allocated amount of time since the problem is shared. Factually, shared problems are easier to solve.
Going back to the concept of reduced man-hours, it is certainly better to delivery say 10 tasks than to be stuck on 20. Sharing knowledge between the 10 tasks and talking to each other is also better than having 20 tasks in flight in isolation.
Pairing Between Non-Developers
Let’s spin the idea of pairing and get into the meat of this post.
How about pairing between people who ‘may’ not code? For instance, paring between Developers and QA, Developers and PO, Scrum Master and QA, QA and QA etc. Is there any room for paring between multiple disciplines?
The pairing concept was founded on the idea of writing code together fundamentally. Given a Scrum Master and QA who ‘may’ not code, is pairing a valid method for them to perform? Naturally no. Most likely the value of coding would not be achieved if they were to pair. However, what about the other benefits of pairing i.e. knowledge transfer, talking about ideas etc. Is pairing then a valid method between a Scrum Master and QA?
Perhaps a little tongue in cheek, can pairing be considering pairing if no coding is taking place?
Let’s try to list the benefits of pairing:
* Shared problem
* Knowledge transfer
* More communication
* Review of work
* Increase probability of delivery
If we remove the concept of coding and simple apply pairing as a concept to any task, this means pairing can be performed between any two disciplines.
Conclusion
Pairing has many benefits, ‘instant code review’ and ‘knowledge sharing’ being the biggest contenders but it’s real value can only be achieved if ‘people’ are willing to pair. It is after all a subscribed method that can be undertaken by any Agile member in the team.
The core benefit of Agile Pairing is to write code together but that does not have to be the case. Any Agile team can reap the rewards of pairing when pairing takes places between any disciplines. For instance, the PO and QA may write stories together, Scrum Master and Developer can pair on upcoming work, QA and QA can review current testing strategies etc.
Pairing is a powerful tool and can easily be used to increase knowledge, speed up delivery and meet expectations.
The process of pairing can be seen as an evolving method, on that note what are your thoughts?
