Many Agile folks love pair programming, and a lot has been written on how great this technique is for Agile teams. However, if misused or allowed to get out of control, pair programming can do serious harm.

 Pair programming involves two developers working as a pair at the same keyboard, one “driving”, i.e. writing code and explaining why certain statements were used, etc., and the other “observing” – paying close attention to what is happening on the screen and providing early feedback. This approach enables early discovery of obvious design issues, before the code is even first compiled. By asking the right questions (the ones a sole developer would probably never ask himself), the “observer” can identify early functional problems as well. This saves time on QA/debugging down the road, and the overall feature delivery time can be reduced.

However, simply pairing people up and letting them loose isn’t enough. In certain cases, using (misusing?) this technique can have unwanted consequences.

The first case is two junior developers working as a pair. Neither one has the knowledge of the solution structure and patterns applicable to the system. When they start implementing a feature, they are likely to try to reinvent the wheel multiple times and embed their code into the overall application in ways that will make it very difficult to maintain. Even if the feature conforms to the test cases, it will consume more time in future through debugging and refactoring.

The second case is a pair consisting of an experienced developer and a junior developer. This is actually done quite frequently for training purposes. The mistake would be to have the junior developer observe only, without doing any driving. While writing the code, the senior developer would explain why certain methods were used, how this or that class interacts with other components, where the right place in the application is to implement required changes, etc. However, if the junior guy doesn’t get to drive, to try all those things himself, it is unlikely that all those useful coding techniques and tricks will actually be learned and used properly in the future. As a result, the time spent pair programming will not benefit the junior developer, instead making things even more complicated and confusing for him, leading to growing frustration.

The last case is a situation when the project is dramatically late, and the management demands aggressive ramp-up and maximum velocity. The scrum master decides to make developers work in pairs in order to increase code ownership, strengthen product quality and mitigate the risk of loss of key people. Very soon, team velocity goes down (which is normal, as it may require several months for the benefits of pair programming to materialize). Presented with the burndown chart at the next steering meeting, the management puts pressure on the scrum master to “un-pair” developers so they can work independently and close more hours. The scrum master caves under pressure and releases the pairs. Ultimately, he or she may decide that the pair programming is simply useless.

Pair programming not as just a fashionable agile technique to be adopted unthinkingly. In order to produce the desired impact, it requires proper environment, the right skills, and finally, continuous monitoring and support from a knowledgeable scrum master or a technical lead.

Download Case Study

Contact Us



Cambridge MA

1 Broadway,
14th Floor,
Cambridge MA 02142 +1 877-737-7178


San Mateo CA

400 Concar Dr,
San Mateo California
94403 +1 877-737-7178


The Hague

Louis Couperusplein 2,
4th floor 2514HP,
The Hague +31 70 512 1899


Sydney | Brisbane

12 Creek Street,
Brisbane QLD 4000 +61 2 8111 5900
United Kingdom

United Kingdom


Cowley House,
12 Black Jack Street Cirencester
Gloucestershire, GL7 2AA +44 7771 787840
Czech Republic

Czech Republic


Na Hřebenech
II 1718/8,
140 00 Praha 4 +420 721 537 689
Czech Republic

Czech Republic


Centrum, Šumavská,
Šumavská 416/15,
602 00 Brno +420 721 537 689



Narodnog Fronta Bb, Becici +382 67 136 640

Send us a note

We'll do our best to answer within one hour