Seven Strategies for Pair Programming

November 8, 2012 · 0 comments

Of all the agile developer practices I teach, pair programming gets the most resistance from management. Managers often ask me how putting two developers on the same task can possible be more efficient than having them work independently on different tasks…but it most definitely is.

Well, you may not find a huge increase in the lines of code written per day but you will find developers get more done writing less code, which also drops the cost of maintenance, and you will see a huge decrease in the amount of bugs written, which will dramatically speed up the time to delivery. When done correctly, pair programming can be an effective way to propagate knowledge throughout a team, improve everyone’s skill level, and bring more job satisfaction. All these things will reduce the overall cost of building software. Here are seven strategies for effective pairing:

1. Try it, you’ll like it
The experience of doing pair programming correctly is different than what many people think. Trying it in a supportive environment where team members can learn how to do it properly can make all the difference between having a bad experience that will be avoided in the future and having a great experience that team members will continue to practice.

2. Engage driver and navigator
Pairing is not about taking turns doing the work. Each member of the pair has specific duties, working together, and in parallel. Both the person at the keyboard (driver) and the one looking over their shoulder (navigator) are actively engaged while pairing.

3. Swap roles frequently
Taking turns driving and navigating every 20-60 minutes helps keep collaboration at a maximum. “Handing off the keyboard” also helps propagate knowledge across the pair and ultimately, by pairing with other team members, propagates knowledge throughout the team.

4. Put in an honest day
Pairing takes a lot of energy; you are on and focused every minute of the day. You are far less likely to take breaks or get interrupted by others when pairing. At the end of a day of pair programming, I come home exhausted but I also feel supremely satisfied. I always gain a lot when I pair program, regardless of whether I am learning something from someone with more experience than me, teaching something to someone with less experience, or we are figuring things our together.

5. Try all configurations
There are a series of techniques and protocols for effective pairing. Knowing them can help pairs collaborate more effectively and efficiently. Try random pairing by story, task, hour, all the way down to 20 minutes. Often, people who wouldn’t think to pair with each other make the best and most productive pairs. See what works and what doesn’t but give all the options a try, the results may surprise you.

6. Let teams decide on the details
Pair programming or any of the agile practices cannot be forced on the team by management; team members have to discover the value for themselves. Not everyone is best suited for pairing, nor are all tasks. Some people need more alone time than others but contrary to popular belief, software development is very much a social activity, requiring a great deal of complex communication and pairing can help.

7. Track progress
Metrics speak louder than words. Pairing does not cut productivity in half; it can boost it, if you measure time-to-value. Keep track of velocity, defects, and code quality. They are productivity indicators and will show you the value of pairing in your organization.

Many hyper-productive teams I know pair all of the time. Don’t believe that pairing cuts productivity in half, which would only be true if the limiting factor in software development is typing. When done correctly, pairing can significantly increase the throughput of value created while slashing defects. I know of no other approach to software development that can radiate knowledge and skills throughout a team more rapidly than pairing.

{ 0 comments… add one now }

Leave a Comment

Previous post:

Next post: