Finding the Sweet Spot: Pros and Cons of Mob Programming, Pair Programming, and Solo Work in…

Finding the Sweet Spot: Pros and Cons of Mob Programming, Pair Programming, and Solo Work in Software Development

In the dynamic world of software development, striking a balance between collaboration and autonomy is essential for optimizing productivity, knowledge sharing, and team cohesion. Various working styles, such as Mob Programming, Pair Programming, and Solo Work, exist to address these needs. Drawing from my 15+ years of experience managing teams and implementing these working styles in various settings, this blog post will delve into the pros and cons of each working style and provide insights on how to find the sweet spot between collaboration and autonomy within your team.

Photo by Chang Duong on Unsplash

My Experience with Mob Programming, Pair Programming, and Solo Work

Throughout my career, I’ve had the great opportunity to work with teams that employed Mob Programming, Pair Programming, and Solo Work, witnessing the effectiveness of each approach firsthand:

• At MYOB, my team implemented Mob Programming, leading to a tenfold increase in performance and becoming the best-performing team in the company during my tenure.
• While working at Service NSW, I utilized principles of Mob Programming to teach Test-Driven Development (TDD) principles within five weeks for a team of 6 engineers.
• At Lexicon (while working at IAG), I acted as a Subject matter Expert on Mob Programming to help the teams with a successful migration project by orchestrating three Mob Programming groups simultaneously, achieving the desired results in an astonishing 3 months within the tight timeframes that many deemed impossible.

The Importance of Experience and Psychological Safety in Mob Programming

It’s crucial to have someone experienced in Mob Programming working with the team, as this ensures the approach is effectively implemented and increases the likelihood of success. Psychological Safety is a must, and the entire team needs to understand the value of trying Mob Programming for the task at hand, with a clear goal of solving the specific issues they are facing.

A top-down imposition of a working style rarely works and often reduces psychological safety. Google’s Project Aristotle, which studied the factors that contribute to team success, found that psychological safety was the most important element in high-performing teams.

Ensuring that team members feel comfortable taking risks, sharing ideas, and voicing concerns is vital for the success of Mob Programming or any collaborative working style.

Pair Programming (2 people working simultaneously on one task on one screen)

Pros:

• Sharing Experience and knowledge and speeding up domain learning
• More ideas to solve complex issues / can speed up task solution
• Ensures focus on debugging / Exploratory work / less procrastination
• Early Feedback in the design and code to decrease the cost of change exponentially (instead of increasing the cost of change exponentially)
• Minimizes the Truck Factor (team resiliency) / Work continuity if one team member gets sick, goes on leave, or has jury duty

Cons:

• Less freedom to explore a problem space without communication overhead quickly
• Pressure from peers for work completion might compromise on quality
• Breaks, coffee, and other needs can disrupt the session

Mob Programming (3+ people working simultaneously on one task on one screen)

Pros:

• Enhanced Sharing Experience, Knowledge Sharing, and Learning
• More ideas to solve complex issues than pairing/speed up task solutions significantly
• Ensures focus on debugging / Exploratory work / no procrastination
• Early Feedback in the design and code to decrease the cost of change
• Makes some rituals and meetings unnecessary; everyone is already together
• Nullifies the Truck Factor (team resiliency)
• Strong flow / Work continuity and easy context re-acquisition after breaks or absences
• Ensures team buy-in and early conflict resolution
• Breaks and personal needs can be managed individually without coordination

Cons:

• Not suitable for simple tasks
• The longer time spent on single tasks when multiple tasks could have been completed
• Staying in Mob Programming quiet for too long may hide individual performance problems and reduce accountability for an individual

Solo Work (1 person working on one task on one screen)

Pros:

• Easy to get into the flow
• Context Switch costs less / is Easier to switch
• Short-term conflict avoidance
• Working on one’s own time without coordination
• Zero reliance on the Internet for remote work

Cons:

• Truck Factor maximized / Knowledge retained on individuals instead of shared as a team
• More PR Review comments / Issues are solved async and too late / Increase WIP
• Thoroughness/Team Alignment on the design is weaker than working together with all minds
• Easier to get blocked staring at the "blank screen" / Hindered in problem-solving
• Procrastination is more likely

Finding the Right Balance

To find the sweet spot between collaboration and autonomy, consider the following factors:

1. Task complexity: Opt for Mob or Pair Programming for complex tasks; that is, when the problem doesn't have a clear cause/effect, and Solo Work for simpler tasks; that is when the solution has a clear cause/effect.
2. Team dynamics: Assess team members’ strengths, weaknesses, and communication styles to determine the most suitable working style.
3. Personal preferences: Take individual preferences into account and provide incentives for team members to work in their preferred mode when appropriate.
4. Time constraints: In time-sensitive situations where quality is not a goal, Solo Work or Pair Programming may be more suitable than Mob Programming.
5. Project goals: Consider the overall objectives of the project and the need for collaboration, knowledge sharing, and team alignment to guide the choice of working style.
6. Physical limits: Consider if the physical structure allows for a comfortable session for Pair Programming and Mob Programming. Most workspaces are optimised for siloed work.

Final Thoughts

There is no one-size-fits-all approach to software development, and finding the sweet spot between collaboration and autonomy depends on various factors unique to each team and project. By understanding the tradeoffs associated with Mob Programming, Pair Programming, and Solo Work, teams can make informed decisions about their working styles and ultimately improve productivity, knowledge sharing, and team cohesion.

My experience across different organizations, big and small, has reinforced the importance of tailoring these working styles to each team’s unique needs and circumstances to achieve the best possible outcomes.

Dogmas should be off the table.

Thanks for reading. If you have feedback, contact me on Twitter, LinkedIn or Github.