Mob Programming — What is it?
Mob Programming What is it?
As mobprgramming.org states:
“All the brilliant people working on the same thing, at the same time, in the same place and at the same computer”
And as the name suggests, Mob Programming is an approach in software development where the whole team works on the same thing. This is similar to pair-programming where two people sit at the same computer and work on a task or a problem at the same time. One usually does the coding and the other ‘navigates’.
This is not be be confused with ‘Swarming’, this is where the whole team gets together to plan a solution, but then go off to work individually. In mob programming the team stays together throughout.
It builds on principles of lean manufacturing, extreme programming, and lean software development. Early use of the phrase “Mob programming”, was made in “Extreme Programming Perspectives”
Mob programming is not restricted to any kind of work, it can be used for:
- User Stories
- Requirements
- Testing
- Designing
- Bug Fixing
- Trouble Shooting
- Testing
This can mean that a typical mob will design, develop, test and deploy all together.
Where did it come from?
The original concept comes from Woody Zuill, and the concept was developed by accident. It wasn’t purposely created or applied to solve a particular issue, it was developed of out his belief that “The team doing the work best can figure out how to do the work”. His team began experimenting with new ways of working in 2011 and engaged in training sessions using code kata techniques, originated in the book “Extreme Programming Perspectives” mentioned above. In this technique a small team sit around a screen and take 4 or 5 minutes intervals at the keyboard.
He liked the technique and began applying it so some tasks. He states “Something really good was happening. The team had figured out how to get the work done”. The term ‘Mob Programming’ also seems to have stuck by accident. He used the term jokingly and the team seemed to like it and it stuck.
How to set it up?
So the concept is that he entire team sits around one (or two) bug screens, and take turns sitting at the keyboard and everyone works together to solve a problem, develop a user story or whatever the situation might deem.
There are many levels to implementing mob programming; so some teams might use it to solve a single issue or bug, some teams would use it a few times a week, maybe on certain tasks or occasions and others will go the whole mile and use it for everything.
So as for the set up, most teams will implement something like this:
Granted, this setup is quite simple and relaxed, but can easily be set up in a meeting room or communal space — and you can see what I’m trying to get across. It doesn’t have to be like this, it could be using conferencing hardware you already have set up in a meeting room to gathering around one persons PC (depending on how many people you are).
The set up obviously also depends on how you are going to use it, it its infrequent then maybe set up a PC in a communal area; where team members can sporadically go to if they want to solve bug or review a design together. If its more frequent then you probably need to think about your layout a bit more.
See below some real life examples of mob programming set ups.
The goal of mob programming is that you become a unit, a collective that does everything together — this is not limited to just coding. When doing this exercise, it can be expanded to answering emails together, handling bugs / issues together, overcoming obstacles together; even taking breaks together.
If you are going to implement this methodology, you have to be aware that its going to take time to get right. Especially if its something that you are going to be using a lot. It has to become part of your culture. The team will take time to adapt to each other, understand boundaries and generally getting used to working so close to a group of people for a period of time.
In the beginning there will be arguments, discussions on methods, experience and knowledge, even things such as typing speed, coding methods and shortcuts and macros. Most people have their PCs set up in a certain way that allows them to work more efficiently — now you are sharing a computer with X amount of other people. Even these small issues need to be ironed out over time. Its always important to remember the objectives and the benefits of doing things this way.
What are the Benefits?
So what are the benefits? There are many benefits, and these will become obvious depending on the team. But these are some of the universal benefits I can see with using this methodology:
Teams become closer.
This might be obvious, but using this methodology your team will likely become better friends. Not that they aren’t already… but teams in my experience can always be closer and this is a great for team building. Working this close to a number of people for 8 hours a day will forge friendships over time. I have seen it many times in my career managing people — getting people to work in pairs to together on tasks I have seen many colleagues become close friends.
The team is no longer as strong as the weakest link.
OK, this statement might be a bit overkill, but you get the idea. Its daily common to have specialists in a team, or people who excel at certain things. No matter how hard you try to construct a full stack autonomous team, its human nature that some team members will be stronger in others in certain areas. When working this closely in a team, weaknesses that people may have are exposed early on. Now you might think this is a negative thing… but actually its not. Usually people try to hide their weaknesses and often they aren’t addressed or improved on. In this situation the team will work together to deal with them. You will find that over time the playing field becomes level and your team will start to improve as a unit.
The team becomes risk takers.
Following on from my previous statement about teams improving as a unit, you will also see that your team starts to become more confident and able to take on bigger risks. When facing challenges, sometimes it can feel daunting on your own; but with the full force of your team behind you. Pretty much every decision will be discussed, voted on and agreed so if something does go wrong the team takes on the consequences. You will find this can eradicate any blame culture and even these kind of situations can strengthen the bond of the team.
The team becomes happier.
This is probably stating the obvious with all the points above, but its important to mention. This methodology allows you to reduce any stress on the team and can greatly improve moral. Teams will no longer feel any sole responsibility and any issues are tackled quickly and together so you reduce instances when there is a problem and it goes unnoticed or not dealt with for a long amount of time. And we all know what ends up happening in these situations.
The team no longer needs to go to meetings.
This is the golden statement that will make any developer happy. But think about it for a moment…. if everyone is working on the same thing at the same time, everyone is on the same page and in the loop — how many meetings do you think will get cancelled. Sure there will be some meetings.. we can’t get rid of them all — but this format also means that because everyone knows everything whats going on, any member of the team can be a representative in any meeting.
The team never says die.
Or was that Goonies? Anyway, because the team is functioning as a team it does not matter if someone is sick, goes on holiday or has to leave in an emergency. The team will soldier on as a unit. This also has advantages when people come back from a long vacation or even new people to the team. You will find that they will quickly become part of the team socially and also their skills will come up to scratch quite quickly.
The team becomes more efficient.
Working this closely with members of your team will reduce any synchronisation that usually happens within a team. With colleagues being in constant communication and on the same level, you do not need to wait for a meeting to go over a design, wait for the stand up to discuss an issue. Your feedback loops become instant and you will see tasks move along quicker and improvements implemented quicker. Any types of issue or discussion can be done in real time. The team will also work a lot harder and more effectively. Because everyone is there with you, people will be less inclined to take their foot of the pedal or coast, and they will look together as a team to speed up mundane, repetitive manual tasks. It can spark some great innovation.
The team will grow.
Probably covered this a lot, and its obvious…. but the team will just grow. They will grow in knowledge, socially, emotionally, technically and personally. This is probably one of my favourite benefits, but working like this your team will share so much knowledge and collaboration will be at its peak. Strengths will be spread across the team and everyone will improve… and they will continue to improve. One person will learn a new skill and it will be quickly picked up by the rest of the team. Its not just relevant to skills, but job relative tasks, developers will learn to deploy, testers will learn to code and even colleagues form the business part of the business will understand technical architecture and restraints. I have seen it happen when testers and developers work closely together and see the problems each one has. As soon as a developer realises that he needs to test…. developments will become more test driven and probably automated.
The team becomes one.
You will go from a team of every unique member doing things a different way, to everyone doing it one way.. all together.
Summary
So mob programming is a bit of a buzz word, and its not a silver bullet to solve all team issues, but it is an alternative approach that can be used on occasion to combat issues such as:
- Communication
- Team members leaving
- Decision making
- Team Moral
There are no set rules for mob programming; its more of an experimental approach and its not for everyone. Your team may not have the right culture or type of work that this methodology would improve efficiency. For most teams, this would be something to use every now and again, something in your ‘tool box’ to use when you have a critical production issue or difficult obstacle to overcome. Other teams may use it at the beginning of a project, then as it advances start to separate and work individually.
If you want to try it, I would recommend trying it on a small task or bug. Its also good to try when you have a new starter in your team — this way you can see early if its beneficial for your team without committing or changing completely the way you do things.
This post was originally posted on: theproducthub.io
https://www.theproducthub.io/2019/12/14/product-tech-terms-mob-programming/
Please check my site to get the latest articles first!
About the Author
Ashley-Christian Hardy
theproducthub.io
Product Leader. Over 10 years in product development; with experience in product management, UX & UI, product design, product & delivery methodologies and product leadership. A strong advocate in innovation, experimentation and building great products with the use of qualitative and quantitative research, putting an emphasis on a customer centric design and approach.
Website: www.theproducthub.io
Twitter: www.twitter.com/achardypm
Facebook: https://www.facebook.com/theproducthubio
LinkedIn: mt.linkedin.com/in/achardypm
Medium: medium.com/@achardypm
Instagram: https://www.instagram.com/theproducthub.io/
Pinterest: pinterest.com/achardypm
SlideShare: slideshare.net/ashlychrstn
