The productivity effect is variable, for pair programming teams as well as for self-organizing teams. Although we should trust that the pair programming team and the members will organize their work best (Schwaber and Beedle 2002), as far as we understand that, the tasks of decisions on design and coding are so discretionary that the team should systematically adopt a way of pair programming.
Here is a summary of some guidelines on coaching pair programming teams:
Principle 1. When adopting pair programming in conventional project management, we have to identify time-critical tasks and shorten them (see Section 5.2.6).
Principle 2. In pair programming, asking your partner open-ended ques- tions minimizes your influence on him/her when you want advice, not consent. For example, how long will it take for others to understand the code? Instead, is it readable? (see Section 5.2.7).
Principle 3. A pair should resolve conflicts by postponing decisions; leave them for a while and let them rethink before deciding to ask for help from others (Section 5.2.7).
Principle 4. Ensure that the requirements are fully understood. Although pair programming results in fewer errors in requirement comprehen- sion, mistakes of this kind will cost much more than in solo program- ming (Sections 5.2.8 and 5.3.3).
Principle 5. Team members who work in pairs with partner rotation should meet in a short, standup meeting in the morning (Section 5.3.2).
Principle 6. The purpose of the standup meeting is to solve tricky technical problems. Dont rely on each pair to individually work out solutions to them. Remember that 2 and 4 is still 4 (Section 5.3.2).
Principle 7. During the standup meeting, if there is a need to collect opinions from the participants, they should give feedback in descend- ing order of their confidence or experience (Section 5.2.7).
Principle 8. To ensure that paired programmers are making efforts that make the project move forward, continuous integration is necessary (Section 5.3.4).
Principle 9. Bring your pencil and paper with you to pair (Section 5.4.2).
Principle 10. Exchange your partner when a pair has reached a design solution and call for an ex-partner exchange when the design solution has been revised (Section 5.4.3).
PAIR PROGRAMMING TEAM COACHED 161
We have yet to discuss pair programming productivity, although in looking for software development rhythms, we have come to see that productivity levels for single pair programming and team pair programming are very different. Exploring productivity insingle pair programmingwill open more issues than we expect. Will the productivity rise and then drop along the development time if a paired team develops an application with unchanged requirements adopting pair programming practice? Will the productivity of novice–novice pairs be the same as that of expert–expert pairs? Will triple programming (sometimes calledtriplet programming) be just as productive as or less productive than pair programming? Chapter 6 deals with the produc- tivity of single pair programming. Most importantly, we consider the situa- tion in which single pair programming can be productive.
This chapter presents the work in the groups rhythm as a unit. However, we should be mindful of the natural ebb and flow of peoples motivation. In addition, groups take time to gel. Once the group reaches its stage of high productivity, provided it is given positive feedback, it can often remain in that stage for a long period of time. Chapter 7 discusses the rhythm of the groups and how they usually go through four phases of productivity, followed by reduced productivity.
REFERENCES
Bisant D and Lyle J. A two-person inspection method to improve programming productivity.IEEE Transactions on Software Engineering1989;15(10):1294–1304.
Bruce K. Thoughts on computer science education.ACM Computing Surveys1996;
28A(4).
Carr NG. IT doesnt matter.Harvard Business Review2003;81(5):41–49.
Cockburn A and Williams L. The costs and benefits of pair programming.Proceedings of First International Conference on Extreme Programming and Flexible Processes in Software Engineering, Cagliari, Sardinia, Italy, June 2000.
Constantine LL.Constantine on Peopleware. Englewood Cliffs, NJ: Yourdon Press; 1995.
DeMacro T and Lister T.Peopleware: Productive Projects and Teams. New York: Dorset House; 1987.
Flor NV and Hutchins E. Analyzing distributed cognition in software teams: A case study of team programming during perfective software maintenance. In:
Koenemann-Belliveau J, Moher T, and Robertson S, editors. Empirical Studies of Programmers: Fourth Workshop. Norwood, NJ: Ablex; 1991.
Gladwell M.Blink: The Power of Thinking without Thinking. New York: Little, Brown; 2005.
Go¨del K. Ontological proof. In: Feferman S, Dawson JW, Goldfarb W, Parsons C, and Solovay R, editors.Collected Works: Unpublished Essays & Lectures, Vol III, New York:
Oxford University Press; 1995, pp. 403–404.
162 PAIR PROGRAMMING
Hansen J. Music enhances reasoning. In: Hoffman B, editor.Encyclopedia of Educational Technology. 2001; retrieved Sept. 1, 2006, from http://coe.sdsu.edu/eet/
Articles/mozarteffect/start.htm.
Harold ER.Java Secrets. Foster City, CA: IDG Books Worldwide; 1997.
Kameda T and Tindale RS. Groups as adaptive devices: Human docility and group aggregation mechanisms in evolutionary context. In: Schaller M, Kenrick DT, and Simpson JA, editors.Evolution and Social Psychology. New York: Psychology Press;
2006.
Keefer G. Extreme programming considered harmful for reliable software.Proceedings of the 6th Conference on Quality Engineering in Software Technology, 2002, pp. 129–141.
Luger G and Stubblefield W.Artificial Intelligence and the Design of Expert Systems.
Benjamin/Cummings: 1989.
Nawrocki J and Wojciechowski A. Experimental evaluation of pair programming, Proceedings of the 12th European Software Control and Metrics Conference, 2001, pp. 269–276.
Nosek JT. The case for collaborative programming.Communications of the ACM1998;
41(3):105–108.
Robert M.Agile Software Development: Principles, Patterns, and Practices. Upper Saddle River, NJ: Prentice Hall; 2003.
Schwaber K and Beedle M.Agile Software Development with Scrum. Upper Saddle River, NJ: Prentice Hall; 2002.
Stasser G and Dietz-Uhler B. Collective choice, judgment and problem solving. In:
Hogg MA and Tindale S, editors.Blackwell Handbook of Social Psychology: Group Processes: Oxford: Blackwell; 2001, pp. 31–55.
Steiner ID.Group Process and Productivity. New York: Academic Press:1972.
Tan G, Gallo PB, and Jacobs GM. Using cooperative learning to integrate thinking and information technology in a content-based writing lesson.The Internet TESL Journal 1999;5(8).
Wald RM.General Relativity. Chicago: University of Chicago Press; 1984.
Williams L and Kessler R. Pair Programming Illuminated Reading. Reading, MA:
Addison-Wesley; 2003.
Williams LA, Kessler RR, Cunningham W, and Jeffries R. Strengthening the case for pair programming.IEEE Software2000;17(4):19–25.
REFERENCES 163
6