In the series “Back to Front” our consultant Eoghain looks at the latest developments, releases and news in technologies from (you guessed it) the Back-end to the Front.  In the latest installment, Eoghain gives his thoughts on mob programming. 


Ever since I first heard about Pair Programming and other Agile methodologies I have been fascinated in finding new ways of improving collaboration. Not only is pair programming an excellent way of improving your code and learning new tricks, it has the tendency to speed up the development process. A natural extension to this methodology is Mob Programming, very much of the same principle but instead of a ‘driver’ and a ‘navigator’, you have multiple ‘navigators’. This model extends on the traditional model of pair programming by integrating the whole team into the process. This means from the very start everyone is on the same page (stand-up meetings aren’t needed as frequently), the strengths of each team member are leveraged and most importantly it provides an excellent opportunity for learning directly from each other.

What you need:

Ok let’s get down to basics here; what you will need to get started is a good team first and foremost. You need to be able to work well together and work through disagreements in a civil manner (fist fights are generally frowned upon these days).

Secondly, you will need a computer… yes A computer, not one each, one for the team! Now, since everyone needs to see what’s going on you will also need either a projector or a (or several) large monitor(s).

Pizza is also highly recommended.



The rules were originally outlined by Woodie Zuill and his team who developed this concept after discovering that their regular Dojo sessions provided them with an environment that stimulated rapid progression and problem-solving.

Rule 1:

Treat each other with kindness, consideration, and respect. This should go without saying but I think we have all worked in environments at one time or another where this wasn’t the case and it caused a lot of friction.

For this to work there will be a lot of collaboration and constant communication, there will be disagreements but working together to find the solution that works for the team as a whole rather than the solution that an individual prefers is a great learning opportunity and needs to be treated as such

Rule 2:

The ‘Driver’ is the only person working on the computer! The rest of the team are ‘Navigators’, and as such are responsible for finding the solutions. As a navigator you will debate, discuss and collaborate, you are the collective brains of the project dictating its direction.

Rule 3:

Timed rotation. Everyone needs to do their time in the driver’s seat; this is about teamwork after all and the driver role can be fairly tiring so make sure that everyone does their duty.

Rule 4:

This is a ‘whole team’ work style, everyone is integral. Every stage of development from user stories to testing is done together. Importantly though, once the testing stage comes around all stakeholders should be included in order to cover all corner cases and scenarios that aren’t necessarily immediately obvious to the development team.

Rule 5:

Reflect, tune and adjust frequently. This rule is pretty straightforward, simply put, as a team you must examine what is and isn’t working, what could be done better and if you are getting the results you want.


Pros and cons

The advantages of mob programming are fairly clear. You get to pool all of the team’s experience and strengths to solving difficult problems and it affords the opportunity for team members to learn rapidly from each other.  It is a truly collaborative technique and tends to produce very high-quality code.

However, everything has some weaknesses; what I can foresee is that some individuals might not work well in an environment such as this. For introverts it could be very stressful and draining, I myself often do my best work when I sit down at my computer, put on my headphones and get into a flow state. I feel tense when I have to work closely with others for extended periods and that can cause friction in the team. For me, the idea of mob programming is appealing but I can see myself having to take breaks to clear my head and get back to a baseline where I feel relaxed enough to work on the problem. I would imagine that there are many others that would feel the same.

Overall I think there is a lot of promise with this technique but I also feel that it has its place in an overall system. I think it would be best applied to developing the core modules or the minimum viable product of a Greenfield project, or if the team comes up against some particularly tough problems on a project.


If you would like to find out more about the methodology of Mob Programming, I’d recommend having a look at these resources:


If you have any input on this topic, would like to get in contact about future topics or would like to discuss open roles drop me a line at or connect with me on LinkedIn Check out my previous articles here