Team-Focused Programming should be default
Should practices like Pair Programming or Mob Programming be the default way of working? That's why I think the response is yes.
Hello, developers! 🚀
Welcome back to the Learn Agile Practices newsletter, your weekly dose of insights to power up your software development journey through Agile Technical Practices and Methodologies!
Before starting, I quickly remind you that my brand new Test-Driven Development 101 5-day Email Course is available: it is the introduction to TDD I wish I had when I started learning it, so I think you will find it very useful!
As a subscriber to my newsletter, you can have it with a 10EUR discount! 👇
Now, let's dive into today's micro-topic!
In short
📈 Team-Focused Programming, including pair and mob programming, challenges the misconception that solo work is more productive. Collaboration removes bottlenecks by ensuring tasks are completed in real-time, avoiding delays like code reviews and task dependencies.
🤝 Collaborative coding creates shared ownership, reducing risks of relying on individual expertise. This approach ensures progress continues even when team members are unavailable, reducing stress and increasing adaptability.
💡 Collaborative programming prioritizes effectiveness by minimizing rework and enhancing solution quality. Teams deliver more innovative, cohesive results, improving long-term success and knowledge sharing.
Team-Focused Programming
Should practices like pair programming or mob programming be the default way of working? The most common feeling I usually see in people when discussing this is that such practices are overkill—reserved for exceptional moments like critical bugs or specific knowledge-sharing activities. Others think that multiple experienced developers collaborating on the same task is a waste and they can never outperform the same individuals working in parallel.
You can see an example of such debate in this LinkedIn post (and its comments) that inspired this issue.
I think most people doesn’t understand where real waste comes from in software development: Team-Focused Programming (collaborative coding practices such as pairing or mobbing, credits to Andrea Laforgia for the name!) it’s super effective and that’s why it should be the default. Let’s explore why this approach can transform your team and your outcomes.
Collaboration Removes Bottlenecks
How many times have you been stuck waiting for a code review? Or dependent on a teammate to finish a specific piece of work before you could move forward? In a traditional workflow, these delays are common.
Team-Focused Programming eliminates these bottlenecks by removing silos. Instead of one person owning a task and the rest waiting for their “turn”, the team works together to deliver incrementally. Code gets written, reviewed, and refined in real time. The result is not just faster delivery, but smoother handoffs and fewer errors.
More generically, working in Ensemble (especially) and Pair it’s coherent with the Queueing Theory.
Shared Ownership = Reduced Stress
One of the biggest benefits of collaborative programming is its impact on ownership. In many teams, specific tasks or areas of the codebase end up with an “owner”—whether intentional or not. This creates risks: what happens if that person is unavailable?
When the team works collaboratively, the team owns the work. No one person carries the burden alone, and everyone has context. If someone is out sick, on vacation, or has to leave for an hour, progress doesn’t stop. This shared responsibility reduces stress for individuals while making the team more resilient and adaptable.
A Team Outperforms Individuals
It’s tempting to think that individuals working in parallel will always deliver more. But that assumes one thing: that everyone has the same level of information, context, and clarity. In reality, solo work often leads to fragmented solutions, misaligned goals, and rework. This also underestimate the impact of having different version of the system progressing in parallel, and especially the impact of merging everything together when done.
When developers work together, they bring diverse perspectives to the table. Complex problems are tackled faster because ideas are challenged, refined, and validated in real time. The solutions created collaboratively are not only more robust but often more innovative than what individuals would have achieved on their own, and work is naturally created and put together with no need to sync/merge it at some point (with the additional risk of conflicts).
The Misconception of Efficiency
A common critique of pair or mob programming is that it’s “inefficient.” Why pay multiple developers to work on the same task when they could each tackle different ones?
But here’s the truth: efficiency is much less important then effectiveness. While parallel work may feel faster, it often leads to downstream costs like debugging, rework, and unmaintainable code. It’s effectiveness that gives you speed, not efficiency, and Team-Focused Programming optimizes for effectiveness—delivering better solutions that require less fixing later. And as a bonus, it builds team knowledge and cohesion, reducing long-term risks.
Make It the Default
Team-Focused Programming doesn’t have to mean you’re pairing or mobbing 100% of the time, not necessarily (but why not?). It means making collaboration the norm and individual work the exception. It’s about fostering a team culture where alignment, shared ownership, and collective problem-solving come first.
Until next time, happy coding! 🤓👩💻👨💻