The value from pairing on the build when its in its infancy shouldn’t be underrated - the build plays a vital role on projects - providing a decisive point of success or failure for the running of our code.

I have worked on teams where the velocity has plummeted due to a fragile build, eventually ending up in development being frozen while we put it back together again.

While I’m not saying these problems would be 100% avoided by having a pair working on the build - certainly having two people working on it (at least initially) helps reduce the possibility of crazy decisions being made.

If it’s not possible to put a pair on this then at least ensure that the approach being taken with the build is well communicated to the rest of the team so that suggestions can be made and then applied.

Verdict: Pair initially to get it setup. Maybe work alone for small fixes later on.

I have noticed that there are two types of 'spiking' that we typically end up doing:

If the library to investigate is clear then it may be more beneficial to take a pairing approach. I have worked with colleagues before who had a much different approach to working out how an API should be used than I did and our combined approach has led to quicker understanding than working separately may have done.

When we need to investigate a lot of options then this investigation will certainly be completed more quickly if a pair splits up and investigates the options between them before coming back together to discuss their findings. When this initial (brief) investigation has been done then I have noticed it works quite effectively to revert to pairing to drill down into a specific library.

Verdict: Decide based on the spiking situation

If we’re doing our job properly as agile developers bugs should be relatively easy to pin down to a specific area of the code.

For these types of bugs the value of taking a pairing approach is that we’ll probably write a test to prove the existence of the problem and from my experience we get better tests when pairing.

An approach taken on a previous project was to have one pair focused on bugs and just going through them all until we cleared out the highest priority ones. Another interesting part of this for me is that I would normally consider bug fixing to be very boring but when done with a pair I actually quite enjoyed it and it was often fun hunting down problems.

Verdict: Have a bug fixing pair to clear out high priority bugs

Despite working in an agile environment there are times when we need to write some documentation - whether this be writing some information onto the Wiki regarding use of APIs or creating architecture diagrams for discussion.

This is one area where I feel there is actually very little value in pairing. We tried to pair on this on one project I worked on but the navigator often found it to be very boring and we saw more value in one person driving the initial document and then someone else reviewing it afterwards.

Verdict: Don’t pair

This has often ended up being a task taken on by the Tech Lead or a Senior Developer in previous teams I have worked on.

A lot of the work is similar to writing documentation for which I would advocate a non pairing approach but have someone else look over the release document before sending it out.

However, knowing the production environment and how it all fits together is useful information for other members of the team to know so there may be room for some pairing for part of this process.

This way if/when problems arise in production and the Tech Lead isn’t around the team will still be able to address them.

Verdict: Don’t pair for the documents but maybe for other parts of the process

That’s just some of the grey areas of pairing that I could think of from a quick brain storm. I’m sure there are others too.