When we had a colleague explain to us at a development day what mob programming is — more than two developers working together on the same computer on the same piece of code — we shook our heads for the first time. Nonsense! Waste of time and resources! The idea alone sounds strange! Dot!
That was the end of the issue. Almost at least. Because then we just tried it out.
Everyone loves pair programming
We love pair programming. You set yourself a task. One of the pair — the pilot — grabs the keyboard and starts talking about what he is doing right now. The other — in his name Navigator — sits next to it and gives a clue or two. After a few minutes, or when a method or test is complete, the partners switch roles. The other one writes and explains. One gives tips. Until the next change. And so on.
After the joint session, two colleagues know how the task was completed. The solution is potentially better and developed in less time than if only one of the two had taken care of the development. And the resulting code is probably also of good quality due to the four-eyes principle. The downside [1] — at least for the management group — is that the time of two colleagues has gone into the same task.
Pair programming in a team?
What works in pairs can definitely not work with three or four. Only one person can use the keyboard. Do two/three navigators then give tips and argue about who is right? The pilot can simply continue typing there.
It was the same with us. There were three of us and wanted to make a task that only one colleague had worked on so far transparent to the other colleagues and thus give ourselves the opportunity to finish the task in a distributed manner. We discussed all three of them and were satisfied with the solution and method — mob programming — in the end.
What we hadn't taken to heart was that in the mob, the pilot is actually just the typist (typist) and he should type what his colleagues say. This avoids too much diversity of opinion and too lengthy discussions. There are also no many navigators, just the rest of the mob.
If the mob consists of more than three people, the current typist does not participate in the discussion, but implements what the rest of the mob prompts him. It doesn't work for three people! If the typist only writes, we have extended Pair Programming to include a typist. Don't!
How to start?
Take:
- A useful topic: From our point of view, a kata was unsuitable because, on the one hand, it would have been potentially very short and there would have been no real problem connection between mob and kata.
- An appointment: One or two time slots of several hours in which the topic set can be advanced.
- A starting signal: Simply outline the goal and briefly outline the necessary steps.
And off you go. At some point, the session is interrupted and a break is taken. And at the end of the second session, it will be decided together whether you
- You've come far enough
- found a good solution
- It may be possible to do residual work outside the mob.
A reflection on what went well/bad and what can be done better next time won't hurt either.
After six bullying sessions
After the first few sessions, we learned that bullying works well for us based on our needs. It was out of the question for us as a default working model. We often split the sessions in two, for example before and after the lunch break, and went well with it. The general exhaustion was limited.
We have always learned something from each other and have, for example, moved closer to each other methodically. There were no fixed rules for changing roles between typist and rest of the mob, nor were they necessary. Group decisions, on the other hand, were necessary and decision-making was sometimes exhausting. Yet every bullying session and its respective outcome felt good in the end.
We have not made a general decision on a subsequent review. Sometimes there wasn't one — kind of demand-oriented.
Wouldn't that be the question of resources
How do I convince my manager that working with several colleagues on the same task is worthwhile? There is exactly one compelling argument for this: Speed!
Anyone who works in an environment where the rapid provision of features is the measure of all things should at least get to grips with mob programming.
For whom speed is not a valid argument, but optimal resource utilization is an important criterion, you may be able to score points with an even distribution of knowledge, training of less experienced colleagues, higher code quality, swarm intelligence and risk minimization [2].
Swarm intelligence means the quality of the expected solution, which is usually better achieved in a team than with lone fighters or couples.
Remote bullying — e.g. in the home office — may be a desirable alternative to constant travel to the customer.
A big mob doesn't necessarily mean high speed. The more colleagues are involved, the more communication takes place and the more opinions/points of view must be addressed. A mob size of three to a maximum of five people seems optimal to us. If the mob is bigger, the speed drops. If you don't believe it, try it out!
Remote mob programming
One of our neighboring teams took the bullying approach a bit further and practiced remote bullying for a while. There was a critical project phase in which the six team members sitting at a distance from each other had to work together remotely. The locations of the colleagues — Krakow, Cottbus and Chemnitz — played a decisive role in this.
The team worked on their problems for several days in a row: one typed, the others discussed. The team had decided that at least three team members should always be online and work as a mob. The others were free to opt out for a few hours for other activities.
For Remote Mob Programming to work, the following requirements must be met:
- Stable video service
- Good network bandwidth
- It must be possible to hand over control to one/all colleagues (e.g. with ZOOM, WHEREBY, etc.).
- Using the same IDE helps; the operating system used was (almost) irrelevant when handing over control, for example, because the keyboard shortcuts between macOS and Windows are usually similar for the same IDE.
A recommendation for remote mob programming is to also do a git handover on his computer when a physical handover to a colleague is — i.e. check in the current code and let the build pipeline run. You should be prepared to accept the resulting time delay.
The team also recommended holding design sessions or architecture stories in general as a remote bullying session — it's worth it.
The team's conclusion about remote mob programming was: Good progress, high quality and no need to carry out a code review after completing a functionality.
There are teams for which is Remote mob programming the default working model (innoq podcast). Also other game types such as Remote Mob Testing sound exciting.
Flow
Pair programming is intensive and exhausting even during individual sessions. Both partners are constantly discussing, highly concentrated and never let an eye off the screen. Anyone who has done this for a whole day and isn't used to it may just want to rest at the end of the day.
A mob programming session is also intensive. But felt less intense than pair programming. There are a number of reasons why. If the rest of the mob consists of several people, one person can dictate to the typist, another person can just Google a detailed problem. The third person just sits back and watches? No problem
Someone from the mob needs a short break? No problem either. The remaining mob stays on the ball. Or does someone have to make a short phone call or even to the meeting? Pair programming would now be over. With mob programming, the remaining people can continue the task. When the meeting is over or the phone call is over, the returnee can let the mob briefly “pull him on” and should be there again in terms of content after a short time.
As mentioned briefly at the beginning, it is a good idea not to stubbornly maintain the distribution of tasks over a longer period of time, but to switch over at relatively short intervals. This can happen after solving a subtask, a certain number of previous minutes, or based on feeling, although we preferred the latter so as not to be limited too much by rules.
Especially for career beginners and junior developers, this variety offers a high learning factor, as theory and practice are taught in an entertaining way — without letting any part become too dominant. Because long before something like boredom can arise, you have another role. You also get pretty exclusive insights into the work rhythm of your more experienced colleagues, because when else do you look over their shoulders in such detail when solving a task? Even if you only pick up small tips and tricks — such as previously unknown IDE shortcuts — from a session: every instructive experience is valuable, especially when starting out in everyday development work.
Of course, the mob also needs sufficient breaks overall: gladly focusing on other topics in order to then relax in the mob and resume speed. But detached from breaks, a mob is certainly more productive than a pair or lone fighter. In our experience, more productive doesn't really mean faster. Similar to pair programming, the solution not only feels better, the code is of higher quality. Downstream quality assurance costs are lower. And the knowledge about the solved task is in any case better distributed than with a lone fighter or with a pair. However, you shouldn't fall into the trap of believing that an additional review is automatically omitted. Because even six or more eyes can overlook mistakes in the heat of battle, which you notice immediately after two days of “sleeping over them.”
In most cases, discussions must be time-boxed — otherwise too much time is lost and the quality of the solution does not improve.
Anyone who has to deal with disturbances from outside the mob can use a Batman. Batman is the scrum master of the mob. His job is to keep disturbances away from the mob. If someone wants to access resources from the mob, they can only do so via Batman. The Batman role in the mob should change at least daily. At the same time, it must be clear who currently plays the Batman role outside the mob so as not to disturb the mob unnecessarily. And: Batman must not be a mob typist on that day, otherwise the flow will be further disrupted.
The bullying space
A mob needs enough space to work. A normal office workplace is rather unsuitable for this because it rarely seats more than two people comfortably. Making a second row is not an option.
When it comes to bullying, peace — for everyone outside the mob — is absolutely necessary. If three or four or more people are discussing loudly, the rest of the organization must not suffer as a result. Anyone who can hijack a meeting room and the setting in the meeting room matches mob programming to top it all off, better get on with it quickly.
When the mob has to move because a meeting room is occupied by others, it disrupts the flow. Try to avoid this by swapping booked rooms.
The monitor (s) should be as large as possible. So big. How It's possible. Not as big as needed. If your bullying space has a 65-inch television, it won't hurt. Ideally, there is a fixed workplace in your room with an IDE and network connections set up so that you can directly access all relevant resources without having to carry around your own notebooks.
In the end — What's left
A few last points are difficult to fit into what has been described so far.
Try to keep the mob constant. A changing mob team goes through the same team creation process as a Scrum team, for example. If the mob composition changes, the dynamics in the mob change and you may lose speed.
When it comes to mob programming, don't impose rules that don't help you or, in the worst case, even slow you down (review, typist doesn't discuss, nonsensical process, etc.). Do what helps you the most and separate yourself from such regulatory obstacles. Mob programming is more of a loose concept than a strictly regulated process — and that's a good thing!
[1] Rumor has it that software developers don't like vermouth.
[2] Truck factor, see https://deacademic.com/dic.nsf/dewiki/1414528
