The first person who is very qualified to do the work, and a second person who
is new to that area. We did this for knowledge transfer purposes mostly, and to
have two people potentially working on two different areas of the task.
Sure enough, this week we have numerous people out for various reasons for
various lengths of time. We’ve been able to keep nearly all of our tasks moving
forward without any slowdown. I was quite impressed with how well this worked.
If none of our tasks were “doubled up”, our two week sprint would have been in
serious trouble.
From attempting pair programming at previous companies,
there can be a lot of resistance to it from the developers, who find it annoying
to have someone looking over their shoulder. Management can be uncomfortable
with pair programming, since they may see it as getting half of the productivity
and not realize the quality, communication, and rich mitigation improvements.
In most of the situations that I’ve seen pair programming fail or not be
useful were when it was forced for many tasks. My current team just allows
anyone to sign up for a task that someone else has signed up for. I’d say about
25% of our tasks are done through pair programming, usually the more challenging
tasks.
I encourage people to not be shy about pair
programming, especially if it’s a complicated area or just an area that you’d
like to learn more about.