How to make mob programming work for your whole team

When we think about the impact of good teamwork, business consultant and author Ken Blanchard said it best: “None of us is as smart as all of us.”

Recently, I was working on a project with my team members where we needed a new way to collaborate on solving a problem. After building a service in a dev environment, we needed to promote it to a different testing environment for the external testing team. In the process, we came across a few error messages that we needed to solve, which was blocking other work on the sprint board.

To get a more complete understanding of what we needed to do to fix them, we all got on a call at the same time and worked through the problems together. This meant we were able to fix the errors and deliver the service more quickly.

This is a software development approach known as mob programming. But what is mob programming — and how can you make it work for your whole team? In this blog post, I’ll explore the benefits of this approach, its potential pitfalls and provide some tips on how to avoid them.

What is mob programming?

Mob programming is the software development approach whereby all the team are all looking at the same screen, and working together to deliver a feature or solve a software problem that impacts the whole team. Traditionally there is a driver, who controls the keyboard, whilst the other team members direct what should be typed. It requires all members of the team, including stakeholders, to get involved with the process to ensure that all communication is in one place. This avoids the need for having separate meetings about the feature away from the mob.

What are the benefits of mob programming?

Mob programming may be undertaken by a team for a number of reasons, including delivery of a large feature, solving a bug that is impacting development across the team, or to upskill all members of the team on the different aspects of the project. Mob programming has been very beneficial in government departments as well as the private sector (including us at Made Tech!). Here are three key reasons why we think it’s useful:

It cuts down on communication issues

During mobbing sessions, each member of the team is available to participate. In addition, all knowledge is shared amongst the team, so there are no additional meetings or email chains. A lot of teams have benefited from having stakeholders involved in the mobbing sessions. This is because then the team can directly query those who have knowledge of customer journeys and the application of this software by the business.

It fosters shared ownership

In teams, there can be a tendency for one person to become the authority on a certain section of the code base, but with mob programming the whole team is involved from the beginning increasing collaborative software development. The entire team is responsible for each line of code, meaning that there is a shared sense of ownership of what is being produced.

It encourages more frequent knowledge transfer

In a mobbing session, upskilling and knowledge transfer occurs more frequently as the team develops together, meaning information isn’t siloed but shared. Junior members of the team are encouraged to actively participate in the process to soften the learning curve. This increased collaborative style of working means that there isn’t a reliance of one engineer to complete a ticket, but a competency among all the team members to be able to pick up tasks.

What are the pitfalls of mob programming?

As with all software development practices, there are likely to be a few potential issues that arise in implementation. A regular retrospective and constant feedback loop is required to ensure that any concerns are caught quickly and addressed. Some common pitfalls include:

Managing different opinions

Too many voices and inputs can make it difficult to address the problem at hand. Each member of the team will have their own individual area of interest, and if these are not navigated successfully, it can mean the mobbing sessions can produce little output.

Team comfort levels

Certain individuals may feel uncomfortable working in large teams, and more inexperienced members of the team may feel that they have less to contribute so don’t participate in the discussions. This leads to more confident senior members of the team driving the sessions, negatively impacting the shared knowledge aspect of the mobbing sessions.

Waning enthusiasm

Often the enthusiasm for mobbing sessions is high at the beginning, but quickly fades as the team suffers from burnout. Mobbing sessions can be quite intensive, which can lead to the team suffering from feeling exhausted and later abandoning the process.

5 top tips for a successful mob programming session

It’s important to enter mobbing sessions with an open mind and a collaborative spirit, otherwise you’re more likely to encounter a few of the pitfalls listed above. This requires all individual team members to buy into the process otherwise it cannot succeed. Here are our top five tips on how to get the most out of the mobbing process:

1. Focus on communication

If the mobbing software development approach is new to the team, then focus efforts on ensuring communication flows well within the team. Make daily goals very manageable, and focus on building confidence in the process. Having a consistent feedback loop run throughout the sessions will highlight issues more quickly, and allow for the team to find a way to navigate these concerns early on.

2. Establish clear requirements

Strive towards a minimal viable product rather than a perfect end product from the session. This ensures that the team has a clear set of requirements they have to meet, and a shared common goal to achieve.

3. Take regular breaks

Mob programming can be intense and draining on team members, so taking a break every half hour, even if just for 5-10 minutes, can vastly decrease the burnout that engineers often experience.

4. Be mindful of the driver

Being in the driving seat can be quite a lot of pressure, and swapping every 10-15 minutes is encouraged. When the driver is regularly rotated, this encourages other participants, including junior members, to become active participants.

5. Be ready to pause the timer for the driver

Being a driver is a key feature of the learning process in a mob session, but often, a technical discussion can carry on longer than just a couple of minutes. When this happens and no active development is taking place, pause the timer so that your driver has the same opportunities for learning as the rest of the team.

Mob programming has been an enormously beneficial tool I’ve used in many projects — but I’ve also encountered many of the pitfalls in my career. I hope that these tips will help you to implement mobbing sessions that work for every member of your team — increasing collaboration, cohesion, and communication.

If you liked this post, check out our previous blogs on development strategies: