Ensemble, pairing, solo; what to choose and when

There’s more than one way to write code within a team, whether that’s as an ensemble (mob), in pairs or working solo with code reviews. Teams and individuals often have preferences over which they prefer, but (at least in my experience) don’t always talk about the implications of that choice.

What follows is a summary of the advantages and disadvantages for each of the different options. For these, I’ve assumed that you’re working within a team and that code changes need to be seen by at least one other person.

So, which is better? The quote above from Jez Humble sums it up nicely. Teams should pick what works best for them at that time, keeping in mind those basic principles, while understanding how the choice affects the team as a whole and each of the individual team members. Many teams use just one of these approaches all of the time and it works fine for them, others pick and chose depending the problem and the mood within the team. Taking a mix and match approach is also an option, for example by working as an ensemble with one or two people dropping out to work solo or in a pair at different times.

This is based on a blog post and talk by Andy L https://blogs.blueskyline.com/2020/08/31/pull-the-other-one/

Ensemble

Also called mobbing

• Provides the most contextual knowledge; whether that’s of the tech stack, domain, etc
• Optimises for flow
• Good for risk mitigation, as knowledge transfer is built in
• Good for learning; whether that’s a new domain or how more experienced people work
• Not so good if the sole expert is on holiday
• Need to be comfortable working in a group
• Synchronous, with options to break out and work solo without interrupting the flow of work

See https://linuxlucy.dev/post/remote-mobbing/

Also https://github.com/JayBazuzi/Mobbing-Pattern-Language

Pairing

• Lower contextual knowledge; usually two engineers, which misses other disciplines
• Provides some knowledge sharing. Can rotate pairs to increase knowledge sharing, but this slows delivery
• Good for learning when senior/junior paired together
• Work progresses at roughly the same speed as working solo with PRs
• Need to be comfortable working in a (small) group
• Synchronous

Good advice https://hatwell.github.io/tips-for-remote-pairing/

Solo (with pull requests)

• Low contextual knowledge; reliant on the knowledge of a single engineer, with occasional communication out to other colleagues
• Limited knowledge transfer. Any context is usually lost
• Slow feedback loop; with most feedback usually at the end of the work
• Learning is slower
• Pull requests can be painful. Needs skill to be done well
• Good for low bandwidth connections/slow equipment
• Can be good for neurodiverse people or those just not wanting to work in a group for a bit
• Can be used to solidify learning done in larger groups
• If everyone works solo, there will be more work in progress, so more context switching and longer cycle times
• Mostly asynchronous. Work when it suits you