Too Many Individuals and Interactions

8 August 2013

Timothy Korson
Qualsys Solution


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.

080813-Too-Many-Individuals-and-Interactions-Korson-IMAGE.jpg

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?
 
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 5 (4 ratings)

Comments

Glen Wang, CSM, 8/8/2013 2:45:19 AM
good explanation of pair programming from individuals and interactions perspective!
Bhoodev Singh, CSP,CSM,CSPO, 8/8/2013 1:28:04 PM
I agree, that's the right way to adapt pair programming or any other best practices. If the teams want to see the real ingredients in the process then I advise to have a features over components based teams which would help the teams to evade of having 'I'&'Them' in their behavior instead they would work as a collective wisdom/ownership.
Pedro Ángel Serrano, CSM, 8/13/2013 6:43:20 AM
Thanks! It's a good example and a good way to understand the benefits of pair programming.
Tobias Hemmerling, CSM, 9/12/2013 4:02:59 PM
I don't think what you're describing is truly "pair programming," and therefore the graphical representation oversimplifies the issue. In true pair programming two developers share one machine and work on the same code, with one individual writing code, and the other peer reviewing it. Is this how your team worked? I didn't get that impression from the article :)

The benefits of pair programming tend to be fewer defects and better design, especially as task complexity increases, as well as removing single points of failure from the task/project (or at least reducing ramp up time). But I think it would be a stretch - in most cases - to make the argument that taking a 6 person team and organizing them as 3 programming pairs (using 3 work stations) wouldn't have a negative effect on throughput.
Timothy Korson, CST,CSP,CSM,CSPO,REP, 10/4/2013 2:28:58 PM
In our case, the pairs worked in the classical pair programming style with two developers sharing one machine.

I agree that one case study does not prove anything, but in our case the numbers were good.

Throughput in terms of LOC/programming-hour may have gone down, but throughput in terms of units of delivered functionality per team day definitely went up.
Timothy Korson, CST,CSP,CSM,CSPO,REP, 10/4/2013 3:57:44 PM
In our case, the pairs worked in the classical pair programming style with two developers sharing one machine.

I agree that one case study does not prove anything, but in our case the numbers were good.

Throughput in terms of LOC/programming-hour may have gone down, but throughput in terms of units of delivered functionality per team day definitely went up.

You must Login or Signup to comment.