Variations on Pair Programming

Text book: Switch your programming partners frequently, preferrably more than once per day.

In this post I'd like to discuss variations on the topic that teams I work with have tried.

For instance, assume you have a large number of new people on the team. Everything is new to them, system design, technology, tools, and process. Where to start? To the newcomer the environment might be an insurmountable road block.

One option is to leave the newcomer on a story until the story is finished, and then swap the experienced person between stories. The benefit of this approach is that the newbie can stay focused on just what is needed to complete this story. The drawback is that the experienced person has almost learn from the start when swapping from one story to the next. Remember that the newbie isn't used yet to giving a 10 minutes run-down of what has happened so far.

Another option is to leave the experienced person on the story and swap the newbies around. Benefit: The experience person becomes the knowledge carrier and ensures consistency in completing the story. The drawback is that the newbie has to start all over again, which might add to the frustration.

A compromise might be to select stories in such a way that newbies can work as a pair by themselves on a simple story. They might be slower but they will make progress. If they get stuck they can get the coach or another experienced developer involved. The pair of newbies can stay on the story until completion.

Pairs that consist of experienced people can continue to work at full speed except when they need to mentor a pair of newbies.

This is by far a complete list. I wanted to show that there are variations on pair programming that are worth trying. And over time you will observe whether it works or whether you want to discuss with your team how to adapt.

Among my teams, there is not one approach that is used by all of them. Different teams use different approaches towards pair programming and inducting newbies. But that is ok as long as the underlying agile principles are followed.