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.
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:
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.
So, we’ve got the cons covered – now for the benefits of pair programming.
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.
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.