Doing Agile with Pairing

11 July 2012

One of the most important and commonly ignored practices of Agile is pair programming. Under the exciting cloud of planning, Scrums, sprints, backlogs, and demos, organizations tend to ignore the importance of the pair-programming principle.

Pair programming is one of the 12 Extreme Programming (XP) Agile framework principles. The main purpose behind this technique is to produce high-quality artifacts. In pair programming, two people work collaboratively on the same task on a single computer. This encourages better communication, better clarification of the problem, and better understanding of its solution. The person who controls the mouse and keyboard is called the "driver." The other person, who sits beside the driver and makes sure that solution is implemented in an effective and efficient manner, is called the "navigator." The members of the pair can switch with other members within the team to take on a different task in another iteration.

This technique helps avoid the situation of a developer seeing his or her own code after a few months or years and wondering what was in their mind while writing that piece of code. It could have been written so much better! An alert and active navigator can point out the flaws while the driver is writing the piece of code. This collaboration leads to cleaner design and implementation, and this use of resources for a common task results in a higher-quality product with fewer defects.

 

Pair-programming benefits

  • No separate code reviews required
  • Better code quality
  • Effective communication
  • Higher team spirit
  • Better coding practice adherence
  • Less dependence on particular individuals
  • More effective inclusion of new team members
  • Greater knowledge sharing among members

Pair programming eliminates the need for separate code reviews and thus helps produce higher-quality code. By avoiding rework in subsequent iterations, the time to market is tremendously reduced.

Closer communication encourages highly bonded teams, who share tasks among themselves rather than assigning them to a specific member.

Better communication and shared responsibility bring trust and create an environment with I and me replaced by us. Completion of tasks or stories becomes a shared responsibility, and thus a reason for team success rather individual success. Members share required knowledge and everything they gained during a story execution, thus creating a broader knowledge base within the team.

Pair programming also leads to better adherence to the organization's coding practices, as either member of the pair can identify and correct any breach of a coding guideline or standard best practice that might otherwise be missed. This practice also helps establish a creative environment and promotes better design principles based on the shared knowledge and experience of the paired members.

In my experience with teams using pair programming, team bonding, accountability, work ownership, product knowledge, and quality was always high. The team dynamics and overall product quality appeared to show high maturity levels. In some cases, we paired new members of the team with existing members; the knowledge-sharing process was effective and enabled the new team members to contribute more quickly and effectively toward product improvement. Pair programming was extremely useful in enabling both teams and organizations to provide business value to end users more quickly and efficiently.

Pair programming is part of the essence of the Agile mind-set, and I recommend its use whenever possible in Agile projects.

Let's go, pair up!

Article Rating

Current rating: 0 (0 ratings)

Comments

Andreea TOMOIAGA, CSM, 7/12/2012 6:32:19 AM
Hi Prashant, I fully agree with this interesting presentation on pair programming and indeed this technique is an important foundation for project success and team growing. What I could see so far from experience is that pair programming can be used for training and coaching purposes when a senior team member pairs with a junior one (acting as a mentor for learning a new technology/framework used in the project) and through constant and iterative rotation of pair programming inside the team collective code ownership is achieved.
Prashant Kumar, CSP,CSM, 7/12/2012 1:55:47 PM
Thanks Andreea! You are right about importance of pair programming for inclusion of new team members and collective code ownership. I've seen some places where this practice is not promoted and rather seen as redundant or waste of time/effort. We found it useful for building high team spirit and for reduction of technical debt in long term.
Leslie Lowman, CSP,CSM,CSD,CSPO, 7/12/2012 2:36:41 PM
Prashant, I agree with Andreea here--you have a very interesting take on pair programming and some great insight. Sounds like you have had good luck with it and your teams have benefited from it as well. I'm wondering how long it took for the "high team spirit" to be achieved as most of the teams that I have mentioned this approach to have not been very accepting due to personality differences. Thanks for this viewpoint!
Prashant Kumar, CSP,CSM, 7/12/2012 5:22:13 PM
Thanks Leslie, yes it takes some time and effort for higher participation of team members. I've noticed that it's more challenging with "highly experienced" team members who transition from waterfall projects environment. I've not seen 100% pair programming engagement from sprint 1. Even if 50% team members start pairing up by 2-3 sprints, then it does not take too long before others get engaged.

Usually positive results are visible after 3-4 sprints and few complex stories. Besides, initially the pairs can distribute writing tests (unit/automated) and actual code between the pair members. This work distribution can facilitate collaboration effort required for pair programming.
Bob Allen, CSM, 7/15/2012 12:53:10 PM
Hi Prashant,
Great post and thanks for pointing out the multiple reasons for pairing. In that regard I would add one more. These days pairing is often used as means of conducting a technical interview; pair the candidate with a team member (or more than one) and get feedback directly from the team on the candidate. This covers not only technical knowledge but also "how is this person to work with?"

I would add one other note regarding pairing: continuos forced pairing is almost certain to fail. Situational and needs-based pairing is by far the most effective way to introduce the practice. If developers don't see the value, they're right to resist. Showing the value can be as simple as explaining the different reasons for pairing and can be illustrated by pointing out that developers are already doing it without realizing it.

Here's an example I like to use: ask a developer what they do when they're stuck on a problem and have been for a while. The inevitable response is call someone over and say something like "I've been beating my head against this problem for over an hour and I just can't see it. Maybe a fresh set of eyes will help." This is an all too familiar scenario that anyone can identify with. What often happens next is that in explaining what the problem is, the 1st developer has an "aha" moment and realizes what the problem is. Often can happen even before the 2nd developer has said anything. THATS the power of pairing on a situational/needs basis. The bottom line is that pairing evolves in order to solve a problem, i.e. the need must be intrinsic and not imposed.
Prashant Kumar, CSP,CSM, 7/17/2012 6:47:35 AM
Thanks Bob for mentioning additional use of pair programming as technical interview. I completely agree with you view about not trying to enforce pair programming in the team. If team realizes its value but thinks it's not appropriate to practice in certain tasks/stories then they have the right to do so. Definitely, the practice of pair programming does evolve over time and has big dependency upon the story's requirement, size and complexity.
Maciej Stanek, CSM, 7/31/2012 3:03:22 AM
I fully agree with presentation on pair programming and indeed this technique is an important foundation for project success and team growing.

You must Login or Signup to comment.