My Mobbing thoughts…

I left the army a little over 6 years ago and my learning curve has been steep to say the least since. I worked in the world of GIS within the army so it felt like a natural step to stay within the world of maps and spatial data and try my best to navigate my way to a new career.

Over time I noticed that I was starting to learn more and more things such as what a database is, I failed that module on my class 1 military trade course. Learn what shell scripts are and how cron is good for scheduling things rather than a diary. I was mesmerised by languages such as Python, Java, JavaScript and many more. Thankfully I started using some of them and people I worked with were legends and helped me learn as we went. This was done in a couple of simplistic ways:

• Simple tasks where you just worked on things until they became easier such as querying databases, create cron tasks etc.
• Thrown in at the deep end, told to get on with it and shout if you get really stuck! I hated and loved these times in not so equal measure.
• Pairing. A common enough approach and a pretty good technique although its success will always depend upon the dynamic of the pair.

These I am sure are all situations that we have found ourselves in and we have all learned from them as well as bear the scars from them. The latest technique I have come across is Mobbing! This technique has been championed by individuals such as Woody Zuill, Simon Harrer, Jochen Christ, and Martin Huber. Within the developer world I have been in this has stirred many heated debates about its value, use and results.

For me, I think it is a great tool and like all tools will have its place to be used. Overuse is wrong and becomes detrimental but so too can be not using it at the right time and place!

For me where it wins as a tool is in the following areas:

• onboarding
• upskilling individuals and teams
• building and improving team trust
• dynamics within a team
• just getting a difficult task done

There are far smarter people who can spend hours going into great detail about the pros and cons of the technique. The guys at Mob Mentality Show have collated a plethora of resources here that would be useful. If you would like to read about it when you are on holiday, Woody recommended his book when we met and I must admit I enjoyed the copy we had in the office.

The reasons I love it are as follows:

No two people are the same: While this is a really obvious statement, it is in fact one that is often overlooked. If we tackle a problem on our own we have only one person’s perspective, one person’s approach and one person’s application to solve it. Yes tech reviews go some way to solving this but typically they will look for obvious issues, address standardisation and a little knowledge dissemination. Pairing will be quoted here I am sure but I have seen so many examples of a more experienced developer just taking the lead and doing all the typing, leaving us at square one again.

Having a few people looking at a problem can bring unexpected and innovative solutions to the fore. It can reduce time as everyone has input, developers, testers, business users and devops for deploying the completed work.

Every Team member is a leader: There are times when we will all be expected to take charge of something; a ticket, a bug or a presentation are examples. Not necessarily standing at the bottom of a trench waiting to go over the top!

Mobbing allows us all to grow, to learn and build trust within our team. This is vital for building strong healthy teams and can be seen in many walks of life such as the military, specialist hospital wards, fire service and many more. I am of the belief that a team with strong trust in each other will always deliver better than a team that doesn’t!

Accountability delivers: If you are navigating there is a little bit of pressure for you to deliver during your time in the seat! This means you have to be engaged even if you are not driving or navigating. Each individual must be thinking of how they can make a contribution. Contributions can be in the form of a test that is needed, identify a scenario not previously thought of, refactoring of code that has been produced, researching an area where there isn’t much knowledge but is vital to the task. The list is endless but at some point you will have to take your turn and navigate the team through the next steps. This can only be a good thing in the form of better tested, more efficient code and more rounded individuals.

There is a common misconception that lies here in the belief if you are not navigating or driving then you are doing nothing. If this is happening then you are not applying the tool correctly and you need to look at how you are doing the task. In the few lines I have hopefully given a clear steer that if done correctly then people should be engaged and productive. There is nothing in the ‘rules’ that says a mob cannot break off and do other tasks, in fact one of our golden rules was:

You can leave anytime, but you take the responsibility to catch up without slowing the mob.

Investment in others is investment in you: If you as a business are toying with the idea of introducing mobbing then I believe mobbing is embodied by this single statement! What better and cheaper way to improve individuals and reap the rewards; let me give you a quick example.

I was in a team of mixed experience and skills. Some of us, myself included, had never even written Python in anger. As such we relied on three individuals to write all our APIs and know exactly what was going on. This worked fine until, one developer left, one developer went to another team and was gone to us and the third was about to go on holidays and paternity! So who would maintain and correct any issues while he was off for a month? Well we all thought we would try mobbing and by the end of a tough two weeks mobbing we had reduced the fact that we had one person out of seven who could work on all APIs to having seven who could work on that API plus could now take what they had learnt and build new APIs as well.

Three extremely positive things happened here:

• The business placed trust in the team’s desire to learn and improve. This was repaid by the work that has since come to pass.
• The individual taking the time to invest in sharing his knowledge and help guide the team as they learned the context and practised their coding.
• The team made a commitment to learn no matter how difficult or hard it would be. The team built a sense of belief and trust within each other that they would succeed.

Communication is the life blood: No team in any walk of life will thrive if they cannot communicate effectively. Working in isolation will never improve how we interact with others but with mobbing it is an essential skill. The navigator must word how they talk so the driver can follow their instructions. Diagrams and walk-throughs are vital before sitting down to start coding to ensure everyone understands the problem. Wash up sessions (retros) are essential to improve how everyone works together! Mobbing allows you to do this for free.

In summary, mobbing will not solve all your problems! It is a tool that you can pick up or put down at anytime. In fact I would argue that knowing when to use a tool is often the greater skill. It is definitely a technique that teams will always need to work at and refine to make it better for them. We refined it every time we used it for nearly six months and it is still evolving now.

If you make it a dogma as some suggest then you will introduce more problems than you are trying to fix and you will never reap the benefits from it. It is an adaptable technique that you can shape to fit your team and the task it is trying to solve. The flexibility of it is one of the things I love about this technique. There should never be a dictatorial approach to it but one where everyone’s opinion is valid. Even if you know that the navigator is very very wrong, allow them to explore that idea. To quote one of Woody’s phrases and a rule we held above others:

“Don’t steal someone else’s learning!” Woody Zuill 2019

It is an environment that will build trust and knowledge within the team giving everyone a sense of ownership across the entire landscape of the solution instead of a silo’d area!

People are emotional beings, this will allow your team to know each other better, find ways for them to work together or not, which can be as important in large organisations. You will see people grow and flourish in this environment which is only ever positive.

I believe it is something that all software teams should try and have as a tool in its arsenal.