Embracing mob mentality
Before I learned about mob programming at MYOB, I had very little experience in sitting with someone else and sharing the keyboard to make code happen. Pairing and mobbing to me were just fancy ideas under the hood of XP. In my previous projects, the only close collaboration outside of stand-ups and retros was code reviews, and I found it annoying when someone told me what to do.
Magically, mob programming was one of the cornerstones of Project Henry, which is now a service in use at MYOB. Mobbing made Henry a usable product in just 3.5 weeks of actual development, after spending the other 3.5 weeks spiking and learning about the process. Here’s what I have learnt about it.
Why we may refuse to try it in the first place
Although I can’t speak for anyone else, I sure struggled with the idea that several people sharing the keyboard and screen will magically make the project go faster than having people to work on their own. Because that doesn’t seem to make sense, right?
I could only imagine the mob being chaotic as the senior ones will be doing what they have in mind and fighting over the control of the code’s flow, whilst the less-experienced are confused, disengaged and failing to keep up.
To be fair, these are the common pitfalls of mob programming that we should avoid at all costs. But let’s have a look at the benefit of mob programming first.
Mob programming in a nutshell
(If you know what it is, just skip to the next section.)
What is it?
Mob programming at its core, is a group of people, possibly and preferably with different levels of experiences, coming together to use one keyboard to try to solve one problem together with code. There’s one person who controls the keyboard, and the rest will be navigators that engage with the problem, come up with solutions or approaches, and tell the typist exactly what to type. Yes, the typist should NOT be typing/driving and navigating at the same time.
The setup is usually simple:
- wireless keyboard
- wireless mouse
- monitor/TV big enough to share with the gang
- whiteboard as a map of attack plans and guide.
Mob programming is not just a fixed way of sharing the keyboard, it is a way of working together, facilitating conversation and communication, and most importantly, building trust and enhancing the team as a whole.
How is it done?
At the beginning of your daily mob, the mob group should break the story that will be worked on into smaller, executable tasks, ideally no longer than 2–4 hours worth of work. These tasks should be written on the whiteboard to guide the mob.
The portable keyboard, along with the role of typist, will be moved between each mob member in ‘rounds’. The person who is typing will be writing the code as directed by the rest of the mob, the navigators.
Each round usually takes about 5–15 mins. There’s no exact answer of how long it should take, but the idea is that it shouldn’t be so long that people are getting bored and disengaged.
The sweetness of mob programming
Enough with the intro, here’s the reasons why I liked mob programming:
1. Engagement:
Simply put, unlike when you are programming on your own, you will face fewer distractions in a mob session. When you are mob programming, you naturally become more focused.
Either you are the expert in the group and trying really hard to explain your solution and help others to put down the code, or you are the ‘white belt’ in the gang and trying to understand and learn from others so you can keep up with the conversation. You might also be busy typing and try to comprehend the logic behind navigators’ words. Most of the time you will find yourself giving 120 percent of your focus without realising it.
Remote mob programming can only make working and collaborating remotely better! Just open up a screen sharing tool with audio plugged in, you are good to go. Slack has really nice feature that support this.
2. Ownership:
Code is no longer owned separately by different members in the team, because mob programming makes the team have joint ownership of every line of code.
Although some may say the team owns the code regardless of the way they work, we all know sometimes it’s easy to say things like “oh he wrote this code”. You can’t do that in mob programming, because it guarantees that every class/module is written collectively.
Since the group makes decisions, the entire team has responsibility for the code’s integrity and functionality. The team will collectively own and solve any potential problems that may appear, leaving no room for blaming and finger pointing.
3. Enhanced Communication and Understanding
There’s no doubt that mob programming can be tiring since people are talking and coding at the same time, but the benefit of it is enormous. Rather than sitting in a corner and working on your own code, you get to talk and explain your thoughts to others. This:
- Helps you to build better relationships with the people you work with, which I believe is a huge team efficiency booster. In my experience, I tend to be more productive, collaborative and open to ideas and suggestions when I feel socially comfortable and accepted.
- Improves the team’s communication skills, making the crew members more aware of others’ habits, patterns and strength, and how to adjust yourself to make the team more productive. This ability to sense, communicate and adjust is crucial in large a organisation since there’s always information to be communicated and made transparent to allow collaboration at a lower cost.
4. Accelerated Learning in Production, with Fewer Roadblocks
Learning by Doing can sometimes be a myth when you don’t know much about the domain and can’t get enough instant feedback to accelerate your learning speed. However, mob programming makes it possible.
Furthermore, the collective knowledge base of a group is way greater than what an individual would know, helping the team to reduce the time wasted getting stuck when every member is contributing unique perspectives, ideas and implementations.
Imagine these 2 scenarios:
There’s an expert in the mob and a few beginners.
The beginners will be told what to do by the expert, and learn how the expert is approaching the problem.
The beginners will ask questions the moment they can’t comprehend the code, and answers/feedback will be provided the next moment, or the question will be marked on the whiteboard for later or more explanations.
This accelerated loop is very powerful for learning. And the fact that experts and beginners are working on the same codebase eliminates the cost of introduction and explanation before an in-depth conversation about the problem space can actually happen.
There’s no expert in the mob and everyone is kind of clueless.
No problem. Bring a few more laptops for researching and just carry on the mob. By having more inputs and controlled experiments the group will learn and progress faster. Just make sure a timer is set so each member has enough time to see his/her experimental approaches get carried out to the end and tested.
For the Henry project, we made a lot of swift progress learning and building software with Golang when we were all new to the tech stack.
Outcome
With exercises and practice, mob programming can create productive teams that:
- are engaged in solving the problem as a whole
- have crew members that trust each other, and can easily and openly talk and share with each other
- are constantly sharing knowledge and improving from other people’s experience
- start, work on and finish tasks together, and their members share the success and failure collectively
- produce high quality code because constructive critiques are voiced and addressed smoothly on the go
What to be careful of
Obviously mob programming, just like another other techniques and methods you may find, is not the magical spell that solves all your problems overnight and keeps the Voldemort away. Here are some prerequisites and tips that need addressing.
Prerequisites
1. Communication Skills
Since you will always be talking in mob programming, communication is the №1 key to success. You will be better off if you are able to express yourself and raise ideas and questions, while being mindful of how you are presenting it and how your audience may perceive it.
Later on, as the team progresses together and members build trust, the communication will get a lot smoother and more effortless.
Bottom line: be mindful of how you present arguments, questions and ideas, and try to build trust among the mobbing gang.
2. Ready to be Challenged and Learn
One may feel challenged during mob programming, since there may be ideas, approaches and critiques coming from the group that contradicts you.
Therefore try not to go into defensive mode too quickly. Hear the other person out. Try to look at the issue from his/her perspective, and take a step back and revisit the problem/code/issue and make the right call as a group. Being challenged is usually the first step to learning, so treat it like gold, not a threat.
Bear in mind that everyone has different backgrounds, mentalities, coding experiences and styles of communication, so be more open and less emotionally attached to the code / problems / issues.
If an argument is continuing way too long and making everyone a bit sketchy, then try to:
- find someone else outside of the crew to provide new perspectives
- quickly record possible approaches, pick one to implement and experiment with the rest later on
- compromise, and understand that it’s not a competition to prove who is right or wrong
Tips
These are the tips @Mark Pearl gave us for overcoming the issues we encountered during mobbing.
Communication is the Key:
1. Be direct, clear and specific.
When you are one of the navigators, speak directly and clearly and make sure you are being specific. Tell the group exactly which line you are referring to (say the line number), and what exactly you want the typist to put in there.
It also takes quite some time to mob smoothly as a group. It is expected that the first few mobbing sessions are a bit chaotic. Practice makes perfect.
Take advantage of the whiteboard:
1. Attack with a plan!
Use the whiteboard to lay out your attack plan for the battle. Write down what the team needs to accomplish, the priority of tasks, and the possible approaches. Having a visible plan on the board is significantly more efficient than relying on plans which have been only verbally communicated.
2. Write down facts and opinions.
Writing facts and opinions down on a white board can provide the group the visibility to how different approaches may affect the project, to make sure that you can resolve arguments and disagreements timely. Visibility is the cornerstone of the alignment that keeps the team going together.
3. Architecture and design.
To make sure that everybody is aligned with the design decisions and architecture, it’s better if there’s some documentation.
Having it on the board will allow people to point their fingers at the same piece of diagram, instead of having everyone referring to the architecture in their heads. The result of this approach can save a significant amount of time, which would otherwise be spent on explaining designs and establishing alignment.
When someone is not following:
1. Callout!
The first and most important step to getting on top of it is to stop being shy and feeling reserved just because you don’t understand what is going on.
Speak up and expose your inexperience, and invite the experienced to help you catch up. And usually they are more than willing to do so.
2. Be the driver / typist.
Go drive and let others to tell you where and what to type. Going around the codebase and putting code in there while asking questions is probably the most efficient way to be a master of the code base.
3. Take notes and dig deeper on it later.
Record the concepts and problems you couldn’t comprehensively understand during the mob, and revisit it and do more research in your own time to consolidate your learning.
When there’s an outstanding expert in the crew:
Sometimes there may be an expert who is more experienced than the rest of the crew. In order to prevent the expert from taking over the entire mob and leaving the rest of the crew disengaged (don’t get me wrong I love the experts), there’s a few tips that may come in handy:
1. Let the expert navigate more, and drive less.
Less driving will ensure that the expert won’t take over of the entire session, the expert will have to explain, direct and educate others to get the job done.
2. Demonstrate, delete, and do it again.
Another possible approach to encourage teaching and learning is to have the expert explain and demonstrate the implementation but delete it after its done, then have the rest of the team try to replicate it. This will give them a chance to consolidate the learning.
To Conclude
Mob programming can be a really powerful tool if you are doing it right. It has the potential to not just increase the efficiency of a crew and the quality of their code, but also enable the crew members to build healthy relationships and communication skills.
So try it out with your crew, you may be surprised what it will bring you :)
