On Slowing Down to Speed Up (and Pair Programming)

I've been contemplating writing up a blog post recently on pair and mob programming as it's a subject that I care about. I then found this arrive in my blog feed and thought 'they've said it all better than I ever could have!'

https://martinfowler.com/articles/on-pair-programming.html

Who is this article for?

• Managers/Senior managers - if you've not seen the impact of effective pairing, this is well worth a read. This is ultimately about flow of work and flow of value - it applies equally to things like supply chain, but is incredibly prevalent in software engineering
• Software Engineers - if you haven't yet tried pair programming, or it's not routinely used in your teams, have a read, share it with your teams, and experiement

The Too Long; Didn't Read (TL;DR) on this one won't be short - I love the subject!

Aside from the great content in this article, my own experience of helping teams introduce these practices over the past 10 years or so has seen teams move from overworked/stressed/juggling priorities to being high performers who have bonded and taken more joy in their roles. Pairing and Mobbing helped massively in that shift.

Firstly, Pairing vs. Mobbing?

This article describes 'pair programming' or 'pairing' very well, so I won't elaborate on it. Mob programming (or mobbing) involves 'more than 2' - some of the approaches are different, but this article applies well to both, and I've seen the benefits mentioned in this article apply equally well to mobbing. When talking of the benefits/costs, please treat pairing and mobbing as synonymous.

When should teams mob? pair? go solo? There isn't really a 'one size fits all' here, but I think the article highlights the approach I've seen work best - make pairing the 'sensible default'. I found with teams I've worked with:

• Sprint 0 / New Architectural Challenges - mobbing by default worked well here. Teams all gained context and understood the struggle together.
• Complex work - pairing by default worked well here, and increased flow.
• Trivial work - teams made judgement calls on this, sometimes solo, sometimes pairing with junior staff to upskill them.

Bold Claim

I think given the past experiences, I'd agree with this article, and I'd suggest:

Teams that routinely practice pairing and mobbing will categorically deliver better flow of value to the customer than those who don't

And you can quote me on that ;)

Ultimately, we're all here to deliver value to the customer (whomever that is), and we're none of us good at multi-tasking - there's significant evidence to suggest that we lose approximately 20% of our effectiveness when juggling 2 tasks, up to 40% when juggling 3. There's also growing evidence (the document links to a great article) to suggest that diverse groups solve problems more effectively together.

Cultural Impact

We cannot underestimate the cultural impact of pairing/mobbing on problems too. Putting people together to solve problems really does help build trust, relationships, and when done well, brings about great challenge and improves overall quality.

Next Steps?

I'd love to hear others' views - either positive or negative on the subject.

• If you're in an engineering team that doesn't yet practice this, share this article around and have a group chat about it - could it benefit?
• If you're a manager of a team that isn't doing it, do the same - engage in the chat and suggest it as a pathway in your continuous improvement.

You may not see results straight away, it's not the easiest thing to get right, but experiement for a month or two on it, and measure - see if you are indeed increasing your flow efficiency. and value delivery.