Pair Programming in Agile Software Development

We all know there is more to agile than simply following the Agile Principles and Agile Manifesto. Successful agile software development requires organizations and teams to take ownership of the basics of agile methodologies.

In this ownership, smart organizations and team learn what in agile does and doesn’t work for their own unique needs. Essentially, creating their own flavor of agile that fits into their organizational and client goals.

With agile software development practices becoming the de facto standard, we’re now seeing teams shifting how they do their development. The traditional approach of development, of each person having ownership for their piece of the code puzzle – worked for a while but as with all things agile, soon new software development methods emerged.

In an effort to reduce technical debt, time spent on debugging, eliminating blockers early, and to improve the overall quality of the software – more and more teams are seeing the value in pair programming.

It’s this emphasis on quality that gives pair programming the strength it needs to be a real game-changer for organizations and teams. The primary goal is always front-and-center – keeping development, quality assurance, documentation, and PMO on-focus.

Why Pair Programming?

At its most simplest definition, pair programming consist of two developers working together on one unit of code. However, to provide additional context, it helps to understand the Agile Alliance definition of pair programming:

Pair programming consists of two programmers sharing a single workstation (one screen, keyboard, and mouse among the pair). The programmer at the keyboard is usually called the “driver”, the other, also actively involved in the programming task but focusing more on the overall direction is the “navigator”; it is expected that the programmers swap roles every few minutes or so. 

The naysayers or stalwarts in your organization will scan this definition and quickly point out some of these commonly touted cons to pair programming:

• Two people to do one job. This can raise resource demands.
• It’s noisy. This approach to programming demands constant and fluid conversation.
• Some people just don’t want to do it.
• It breaks down when one member of the pair is away or simply not engaged.

Yes, it’s true nothing is perfect. However, when the right people are put together and there is a common understanding that this is the team’s approach to software development – slowly but surely the kinks get worked out and the benefits trump the negatives. And, as for the noise – well, this is when organizations have the chance to get creative with workstation layouts and floor plans.

Pair Programming for Success

So, we’ve got the cons covered – now for the benefits of pair programming.

• Quality. This is the big one, for every organization and team. The better the quality, the better the success rate, and the higher the overall satisfaction across the board from upper management to the client. Pair programming naturally lends itself to quality with its reduced number of defects, better instant analysis of programming decisions, and the chance to immediately catch errors. In this programming practice, four eyes really are better than two.
• Rewarding. It’s not easy to work alone all the time. It’s easy to become isolated and disconnected from colleagues. Pair programming is ideal for developers who benefit from stimulation and engagement. It also creates an environment that supports healthy debate and feedback.
• Agile. Yes, pair programming helps put the agility back in agile software development. With two programmers working together, it’s easier to adjust goals and priorities on-the-fly. Or to take one pair member off on an emergency fix while the other member continues on as planned. Fires and blockers become less of a stressor.
• Mentorship. It’s not easy to be the junior or new programmer in an established team. When the teams are created correctly, natural leaders and mentors soon emerge, helping those who are new to the company or to development. The risk factor is erased for the new team member, giving them inherent support to make suggestions. It’s also a natural environment for those with leadership and teaching skills to help share their knowledge.
• Productivity. The more productive the team, the better. This overflows into team satisfaction and a commitment to the overall organization, PMO, and team goals. Less time is spent on finding and fixing bugs and performing code reviews.

Our goal, in this is to give you the information you need to make an informed decision about what is right your organization and team – there is no right or wrong in agile software management – it’s in finding the right path at the right time for your team and organization.

A Whole Team Approach to Agile Software Development 

Some organizations and teams are taking pair programming to the next level by integrating quality assurance, design, and documentation in the very early cycles of programming. While the quality assurance team for example, is not able to test the code, a QA expert can lend another set of eyes to the code, help to solve problems, and identify potentials for errors, and then use this early look at the code to develop user-acceptance test plans. For the UI designer and documentation specialist, each can get early looks at the GUI and software, giving another perspective on the work and to better able complete their individual roles.

When the focus is on quality and not quantity – the ability of the agile software development team to work as a cohesive unit happens naturally and easily. However you and your colleagues manage your software development processes, remember that there are no rights or wrongs – there is only the right fit for your team.