Pair first
Think pair programming first by making it default for all tasks, not the optional occasional pairing which is how most places fake pairing.
Why pair
I have already ranted why pairing is so beneficial in "Pair up now". I have since worked in pair-always teams for another two years and really can’t fathom the waste of not pairing in any future projects.
Don’t do optional pairing
Many places, and I used to work at a few, do optional pairing. They say they pair occasionally as and when the team members think they want to.
I call this fake pairing. As it does not happen very often, and is more like as a second opinion or help when someone gets stuck on a task for a short time. That is not what pairing is. Please read the blog post mentioned above what pairing actually means. (code quality, knowledge share, low bus factor, best practices, egalitarian technology, feature speed)
Optional pairing lets people find excuses to not pair even when they think the tasks may be more suitable as a pairing tasks. Or wait until people are available which is wasteful as well as context switch cost for the other temporary pair member.
Optional pairing is better than no pairing, but only slightly.
Default to pair
By making it default you avoid discussion if one should pair or not. It is less ambiguous and the team just gets on with the tasks straight away. You realise most tasks can be paired on.
You also then start to see the big benefits of everyone pairing over time. You will start to notice higher quality code, that less bugs creep through and the code start to be quite lean as unnecessary code does not even get written. And the flow of tasks is steady as there is less bottlenecks of people with sole knowledge of some part of the system as the knowledge is spread across the team
You will have a team that knows each other better, that really work as a team. A team that has shared their own ideas and niche knowledge of technology. The code base now also looks more homogeneous and evolved as the team has improved their abilities unilaterally.
Non pair tasks
Sure as mentioned in my previous post there are still tasks that does not need to paired on. But there are fewer of these than you think. Mostly research tasks etc can be done alone. Or a pair may not sit together whilst ‘googling’ separately for a bit.
If someone is working solo on a task it is important that these tasks are minimised and time boxed as they often become time sinks and over complicated solutions thought of.
Odd number of team members
Often though through holiday, sickness, meetings, team rotation etc there is an odd number of members in the team making pairing everyone mathematically impossible.
You could triple up on one task. It can be done, though often end up with too many cooks in the kitchen. There may be suitably encapsulated sub tasks that the third triple member can work on his/her own and sync with the others frequently instead.
You could let the odd team member pick up a normal task as an individual. This can also work but I recommend highly against it. Many times I have seen this just result in the problems pairing was meant to solve. They get too entrenched in the task and it takes longer than planned. Or get defensive about it. Or it gets over-engineered. Or they take shortcuts or bad technology choices that would not have happened if paired on.
If there are some obvious non pair tasks to pick up then it might be a suitable filler until pair rotation happens again or a new member becomes available. Tasks such as perhaps some rare support or monitoring, or evaluate some low priority PRs.
Or they can work on some fun but non priority technical debt. Such as automating wall displays, or support scripts or tools to simplify/automate a process. It provides a nice break from the other normal tasks, and also hopefully helps the team in the future and reduces paper cuts.
Don’t chicken out
So do not chicken out by agreeing only to pair when the task's problem is suitable. Instead always plan to pair unless it is a rare hands off research task or similar.
