There are times when working with a single other person – pair management – is better than working alone or with a team.
Some professions such as police have a long tradition of working in pairs. Recently software programmers have started to practice pair programming where two people sit together and alternate roles of writing and reviewing software code. The resulting quality improvements can make this process more productive overall.
Pair management has some of the benefits of teams. A pair will generate more ideas than one person working alone. A pair generates a greater diversity of ideas, increasing the chances of having better ideas. A pair can work in parallel, going faster by simultaneously working on two related tasks. A pair can improve quality by working together on the same task. A pair of people can morally support each other, and people feel more satisfaction and learn more when working in pairs than alone.
A pair can work more quickly than a team because communication and coordination between two people is easier than among a team.
Do it now
Begin with a defined project or task that can benefit from more than one person but doesn’t require a team to complete. Collaborate with someone who has complimentary skills and select an interaction style from the list below.
Work with a partner who has complimentary skills, such as:
- Different skills with the same perspective, such as a more creative person to compliment a more analytical person
- Similar skills with a different perspective, such as knowledge from inside the organization to compliment knowledge from outside the organization
- Broader or deeper skills, such a range of relevant experience to compliment deep expertise in a particular area
When working with a partner, choose an interaction style suited to the activity at hand, for example:
- In continuous review one person does the work and the partner continuously reviews the quality of the work. The pair periodically switches roles.
- In problem solving both partners work together to solve a problem through tasks like generating ideas and building an analytical model.
- In complimentary tasks each partner does a different task that benefits from real-time communication with the other partner. For example, if you’re testing a prototype one person can run the test and the other person records the results.
The main pitfall to avoid when working in a pair is groupthink. Partners need to feel comfortable showing healthy skepticism toward each other’s ideas. Careful matching of personalities is important in forming effective pairs. For example, it can be difficult for someone to provide honest feedback to another person higher up in the organizational hierarchy.
There are times when working alone or with a proper team is better, see Work Alone and Work as a Team.
Responses
I was just looking for some sources about that and here there is one – and fresh.
I just almost fell asleep on my keyboard and recollected how I used to work pair programming from time to time in my previous work and some vague memories of pair programming being part of Extreme Programming methodology. I thought maybe that is a more general thing. I remembered that at school you are often asked to work in pairs and it is also often a great thing for training and to introduce people to a new work place, so maybe there is some theory behind that? Science? Sociology? Management? Psychology? There should be something about that somewhere, but I only keep finding training materials for schools.
There is a lot of research in pair programming coming out of software development literature, particularly those associated with the new “agile” software development processes. I assume much of what they are finding would work for pairs in other contexts too…
Pair programming studies:
Nicolescu, R. and R. Plummer, A Pair Programming Experiment in a Large Computer Course. Romanian Journal of Information Science and Technology, 2003. 6(1-2): p. 199-216.
Pair Programming: When and Why it Works. Chong, J.; Plummer, R.; Leifer L.; Klemmer, S.R.; Eris, O.; Toye, G.;
Williams, L., et al., Strengthening the Case for Pair-Programming. IEEE Software, 2000. 17: p. 19-25.
Cockburn, A. and L. Williams. The Costs and Benefits of Pair Programming. in First International Conference on Extreme Programming and Flexible Processes in Software Engineering (XP2000). 2001.
Williams, L. and R. Kessler, Pair Programming Illuminated. 2003, Boston, MA: Addison Wesley.
Hanks, B., Empirical Studies of Pair Programming, in 2nd International Workshop on Empirical Evaluation of Agile Processes (EEAP 2003). 2003.
Nosek, J.T., The Case for Collaborative Programming. Communications of the ACM, 1998. 41(3): p. 105-108.
Williams, L. and Kessler, R. All I really need to know about pair program-
ming I learned in kindergarten. Commun. ACM 43, 5 (May 2000),
108–114.
Hanks, B., et al. Program Quality with Pair Programming in CS1. in 9th Annual SIGCSE Conference on Innovation and Technology in Computer Science Education. 2004.
McDowell, C., et al. The Impact of Pair Programming on Student Performance, Perception, and Persistance. in 25th International Conference on Software Engineering. 2003.
I’m rolling in references because I’m doing my thesis on agile software development. :-P
Thanks Elizabeth! I’m coming at it from another direction, thinking about how Agile programming can make general management more agile.
I’d love to see your thesis when it’s done.
I’mm interested in both Elizabeth’s thesis and any similar work on pair management that may be out there. As a non-profit advisior to government agencies, I value anything that I can find to help them.
You can keep up with Elizabeth’s work on her university site:
http://hot.carleton.ca/~ewhitworth/