Six members of a development team I was working with were discussing pair programming and debating whether it was right for them. My advice to the team was in line with my general philosophy about new ideas: One learns more by doing then by talking. So I suggested that we try it for a few sprints, and then review our experience. Given that no one was being asked to make a long-term commitment, the team fairly quickly agreed to try pair programming for a couple of months.
I was impressed with the externally visible results. When organized as three pairs of developers, the team was more productive than when organized as six individuals. The number of delivered bugs went down, and features were delivered more quickly.
At the end of the agreed-upon trial period, the team members met to discuss their experiences. As expected, they agreed to continue pair programming. The interesting observation came when I asked, "Why? Why do you want to continue pair programming?"
In answer to the question, one of the developers walked up to the whiteboard and drew the following two pictures.
I had never seen this simple, elegant argument for pair programming before. Most arguments focus on the benefits to the pair, but this team felt that, for them, the major benefit of pair programming was in improving team communication. Before pair programming, communication was error prone and consumed too much time. The simplified lines of communication after pair programming resulted in fewer missteps and better work flow.
This argument seems to get stronger as team size increases. With six members, there are 6!/4!2! = 15 potential lines of pairwise communication. With eight members this increases to 8!/6!2! = 28. Daily stand-ups help, but too many communication lines can dampen effective team swarming. Smaller team sizes are often more productive per person, but they lack the needed breadth to be fully cross-functional. Pair programming (in addition to its numerous other benefits) seems to be an effective way to keep many of the benefits of small team size, yet have the throughput and collective skill set of a larger team.
What is your experience?