Mob programming is a software development approach where the whole team works on the same thing, at the same time, in the same space, and at the same computer. This is similar to Pair programming – an agile software development technique in which two programmers work together at one workstation. One, the Driver, writes code while the other, the Observer or Navigator, reviews each line of code as it is typed in. With Mob Programming the collaboration is extended to everyone on the team, while still using a single computer for writing the code and inputting it into the code base.
The Mob Programming approach relies on concepts such as face-to-face and side-by-side communication, team alignment, collaboration, whole team involvement, continuous code review, and self-organizing teams in order to be effective.
In addition to software coding, a mob programming team can work together to do almost all the work a typical software development team tackles, such as defining user stories or requirements, designing, testing, deploying software, and working with the customer and business experts. Almost all work is handled in working meetings or workshops, and all the people involved in creating the software are considered to be team members, including the customer and business experts.
Where did Mob Programming come from?
The original concept comes from Woody Zuill – Programmer, Consultant, Agile Expert and Coach, and the concept was developed by accident. 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”. In this technique, a small team sits around a screen and takes 4 or 5 minutes intervals at the keyboard. He liked the technique and began applying it to some tasks. The term “Mob Programming” also seems to have created by accident. He used the term jokingly and the team seemed to like it and it stuck.
How to set Mob Programming up?
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 and issues together, overcoming obstacles together; even taking breaks together.
Here are the key principles of Mob Programming:
• The team comes together in a meeting room with a set task due for the day. This group working together is called the mob.
• The entire code is developed on a single system.
• Just like Pair Programming, there’s the Driver and the Navigator.
• Only one member is allowed to operate the system. This means only the Driver can write the code or make any changes to the code.
• The other members are called “Navigator” and the expert among them for the problem at hand guides the Driver to write the code.
• Everyone keeps switching roles, meaning no one person will be at the system all the time.
• The session ends with all the aspects of the task getting successfully completed.
The success of mob programming depends on the collaborative nature of the developers coming together to form the Mob. A group of 5-6 members makes a good mob. For a productive session, each member needs to be familiar with software development concepts like testing, design patterns, software development life cycle, among others.
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.
What are the Benefits?
There 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. Working this close to a number of people for 8 hours a day will forge friendships over time. And this is great for team building.
• The team becomes risk takers. 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.
• The team becomes happier. This is probably stating the obvious with all the points above, but it’s important to mention. This methodology allows you to reduce any stress on the team and can greatly improve morale. 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.
• The team no longer needs to go to meetings. This is the golden statement that will make any developer happy. 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 canceled.
• The team never says die. 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. 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 synchronization 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 grow in knowledge, socially, emotionally, technically and personally. This is probably one of my favorite benefits, but working like this your team will share so much knowledge and collaboration will be at its peak. One person will learn a new skill and it will be quickly picked up by the rest of the team. It’s not just relevant to skills, but job relative tasks, developers will learn to deploy, testers will learn to code and even colleagues from the business part will understand technical architecture and restraints.
• 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.
Common Pitfalls
There are no set rules for mob programming; it’s more of an experimental approach and it’s not for everyone. If you are going to implement this methodology, you have to be aware that it’s going to take time to get right. Especially if it’s something that you are going to be using a lot. It has to become part of your culture.
There are things to consider when adopting Mob Programming:
• 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.
• Mob programming will only work if the team sees value in this approach and chooses to work in this manner. Because Mob Programming involves commitment and changes in work style for everyone involved, the change will not be nearly effective if people feel they are being forced to make the change.
Summary
Mob programming is a bit of a buzzword, and it’s 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 Morale.
Mob Programming challenges everything and it’s a very powerful tool that can increase the team’s overall throughput and remove the work in progress completely. It makes you and your team more effective, as long as you try to avoid some common mistakes. The productivity and fruitfulness of the approach lies in the credibility and dynamics of the members and not in the nature of the problem at hand. Hence the potential of this approach can be leveraged for solving difficult problems, given the best bunch of mobs to deal with it.
Even if you don’t believe any of this could possibly work I would argue it is worth a short experiment to find out. At the very least I promise you’ll learn something about yourselves and your team.
Thanks for reading and feel free to share your comments below!
