The Agile Pocket Guide: A Quick Start to Making Your Business Agile Using Scrum and Beyond

Chapter 21

Paired Programming—Team Kaizen

I've received numerous questions about the engineering principle of paired programming, often centered on its feasibility and “real” benefits. For many people, this inquiry is simply a probing question and not something that they'll ever act on or employ. Budget constraints cause businesses to balk at such misunderstood waste: “I mean, seriously, why have two programmers work on a workstation when two independent programmers can do twice as much?” I get it; it's a tough question to answer and an even harder practice to test in your organization. Imagine speaking with the president of your IT department and telling her that you are going to slow down production a little bit to have two developers work on the same piece of work. How long do you think you'll be working for that company? But ideally, management will be very informed and open to your suggestion—you'll keep your job and be recognized for coming up with a great idea.

I was recently given an article written by Stuart Wray ¹ that really helped my explanation of paired programming, and I have leveraged his writing in this chapter. In terms of my own experience, I've not only seen it work but have deployed this engineering practice with great success. There are pros and cons to paired programming. The most obvious negative is the thought that “one guy programs and the other just sits there.” Well, we can only hope that is not happening in your environment, but let me offer six reasons ...