How we tried mobbing

If you try to find mobbing or Mobbing in a search engine, then a significant part of the results will be about "psychological abuse of people." Therefore, it is better to immediately look for "mob programming". In the top 10 results of Yandex at the moment (02/27/2019) there is only one article in Russian (and that one is a translation), but there are many articles in English. If you look at them fluently, then most of them are a theory, not an analysis of any practical case. Everyone says that it will help the team become more effective, locally distribute project expertise, and develop soft skills in people. I myself tested mobbing in practice during one of the scrum trainings, and, frankly, was delighted! After consulting with the team, we decided to conduct our test mobbing session.

Among the advantages of this approach to work, we identified for ourselves such values ​​as the spread of expertise within the team and the development of additional skills for each participant. Having organized a meeting dedicated to mobbing, we set ourselves three goals: first, to try mobbing in practice. Secondly, to understand what disadvantages and negative factors are in it in our case. Thirdly, determine whether it will bring the above values ​​to our team.

What is mobbing

The founder of mobbing as a working style of Woody Zuill describes him as follows:

wonderful people working together on one task at one time in one place on one computer.

That is, Mobbing is a work style when a team constantly works together and together “pounces” on any tasks. At the same time, the task goes through all the necessary stages of its life cycle, and each team member works on it simultaneously with everyone. Thus, immersion and understanding of the task by the whole team is achieved.

There are several roles in mobbing:

• Driver: sits in a common workplace, does exactly what the navigator tells him.
• Navigator: gives instructions to the driver. If he does not know what to do, he consults with the mob (the rest of the team), broadcasts the necessary actions to the driver.
• Mob: participates in the development, tells the navigator what the driver should do.
• PO (product owner): knows exactly what should happen. Sets the desired direction for the movement of the team. It can be a driver and navigator.
• Facilitator: monitors compliance with the rules, announces shifts, parks ideas. It is desirable that there is one person in this role.

Mobbing consists of a session, which consists of cycles, each of which consists of shifts.
Session - a period of time during which a team works on a task. Before the session, the task is selected and divided into stages, and its goal is determined - what needs to be obtained as a result, for example, the increment of the functional.

Change - the time interval between changing the roles of the driver and the navigator. Change lasts, as a rule, 15-20 minutes. Shorter shifts contribute to higher speed and greater team engagement.

Rules of the game

During the shift, the driver sits at the shared computer and does exactly what the navigator tells him. The team observes and, if necessary, discusses what needs to be done. The navigator structures this discussion and broadcasts to the driver what exactly he needs to do now. The driver listens only to the instructions of the navigator and can ask him questions. The navigator can broadcast the question to the team. The facilitator “parks” ideas that were voiced but not used for one reason or another.

At the end of the change of role, the driver and navigator roles are transferred to other people in a predetermined order: the current navigator goes to the mob, the driver becomes the navigator, and the next person in turn becomes the driver from the mob. When each member of the team visited each of the roles, the “circle closes”, that is, the cycle ends.



After the mobbing session, each of us shared his impressions, on the basis of which certain conclusions were drawn. As a result, we got a result that gave an understanding of how and when it is better to use mobbing, and whether it suits our team. I'll start with negative impressions.

Negative

Sometimes the role of the navigator is not entirely clear. At some point, for example, the analyst could be in this role, and the developer could be the driver. The navigator retold what the team was telling him, not fully understanding “what all this means,” due to a lack of development experience. As a result, situations arose where the navigator simply did not make sense to transmit the instructions of the command, because, firstly, the developer hears the command, so why does he need an intermediary? Secondly, the driver understands how to act in this situation, but according to the rules of the role, his hands are tied.

We also noted that if the navigator needs to look at the next tab in the development environment to determine the next step, then he needs to voice this idea and wait for the driver to switch the tab. He himself would have done this while he voiced the request to the driver, with everyone “be so kind” and “please-thank you”.

The difficulty was that we have two developers working remotely. First of all, it added time for such an operation as “switching the rights to the cursor”: so that the remote administrator could show something on the screen, but at the same time not take control of the mouse. To do this, it was necessary to expand the conference control window, enable the right person to control the cursor, and minimize the window. It doesn’t take so long, but it distracts very much, knocks it out of a task (which it has just begun to plunge into), and generally interferes. As a result, after each shift, the new navigator had to ask the previous one what he wanted to do now, both had to remember this, “synchronize”, and only then move on.

Another difficulty due to the “remoteness” of some employees is their neighbors. At some point, a neighbor at the remote navigator decided to drill holes in the whole house, so we heard a full range of accompanying sounds with amplification. This, as you know, did not help us at all.

Since we were very limited in time (one hour per mobbing session), our shifts were very short - 5 minutes each (so that each participant had time to visit this or that role at least once). It is also strongly, in my opinion, reflected in the progress. As said earlier, all participants in the session were immersed in the task only at the end of the shift (1-2 minutes until the end), and after this short period of time everyone was distracted by the switch. It’s clear that you won’t do much in this way.

Another team would like more time to think “silently” and discuss ideas, but frequent shifts provoked trying to examine more with hands than hypothesized in theory.

We did not take the simplest case for an hour-long experiment: a task from another project that was not very familiar to our team. Most of the time we figured out how that piece of code that we need to change generally works. Over the total 7 hours of work (1 hour for each team member), we really did not understand which side to approach this task.

The factor was noted that the whole team sees the solution to the problem from a certain point of view, including a tester. We suggested that in the future (when we reached the appropriate stage) this could negatively affect the objectivity of testing, because we all would know “how it works”, and subconsciously we would try to avoid bottlenecks. Unfortunately, this is just an assumption.

But our other hypothesis was confirmed. Even before the session, we suggested that if people with different visions come across while working on the same task, then there will be a race of ideas. This is exactly what happened: some developers suggested conducting local debugging by means of integration tests, others - by fully implementing the business process that was supposed to be changed. Each side made convincing arguments. We got out of this situation due to the fact that we decided to try one approach first, and if, at the agreed time, we understand that this method requires more labor, then we will use an alternative option.

Settings in the development environment turned out to be a stumbling block: each of the developers is comfortable with their own specific parameters. In this case, there was only one development environment, and, of course, not everyone liked its settings.

We even managed to make a facilitation mistake: shortly before the end of the shift, the future driver went for tea. As a result, his navigator also left to brew tea, and we thus lost one shift in time.

As you can see, some negative factors arose as a result of organizational errors, but, nevertheless, they showed how to do better and why.

Positive

Participants noted that this style of work allows people who normally receive tasks from the business, analyze and test them, to delve into the process of directly solving these problems. They saw work on them from the other side: what steps a task goes through on the way to its implementation. It became obvious to them what actions the developers are doing in order to understand how to approach its solution. Thus, everyone sees and understands what is currently happening with the task.

It has become obvious to some of us why developers often require more in-depth analysis when describing a task, and why they sometimes ask rather absurd, at first glance, clarifying questions.

Undoubtedly, this is a new, valuable experience for each of us. In addition, such an unusual collaboration helps to strengthen the team, that is, it serves as a kind of team building: for the first time, someone saw the other person’s direct work, learned his thoughts in a certain situation.

results

Having discussed the feedback received from each other about the session, we came to certain conclusions.

According to our results, it turned out that in mobbing you should not work absolutely with the whole team, or at least not constantly. In our reality, if the whole team is working on only one task, then negotiations with contractors are not held and user requests are not processed. You can, of course, do this until your shift comes, but then you need to get distracted, switch to the task that everyone is solving, then drop out of it again and remember what you stopped before the shift.

It is necessary that the navigator is a little more experienced than the driver. Otherwise, it turns out to be a game of a broken phone, when the navigator tries to literally pass the driver what he said, not fully understanding "what it all means." You can, for example, change roles not in turn. If you can’t provide couples with more powerful navigators, but you need to teach people to work not only according to their specialization, then, in our opinion, pair programming will be more effective.

We got the impression that mobbing would work well when new developers appeared on the team, or someone on the team decidedly wanted to program. Then, when conducting mobbing with experienced developers, newcomers will quickly immerse themselves in team projects and understand generally accepted principles and rules of work.

In the same way, you can work on a task that only one person in a team possesses expertise in (yes, we have such a person and such a project) to spread knowledge among the rest.

We had the assumption that mobbing is good for tiger-teams: teams that are formed to solve some urgent task. But this can work if, at least, the team is in the same room and with the development environment prepared for the majority. Otherwise, there will be a loss of time due to unnecessary communication factors.
If a team has just formed, and ideally, a new project is being formed along with it, then mobbing can work well. In this case, each participant will see how and why certain conceptual, architectural and other decisions are made, there will be an imbalance in the knowledge about the project.

Ultimately, shifts are needed longer. At least 15-20 minutes, instead of our 5. And you need to do something with the rule that a driver is just the hands of a navigator, without its own head.

So, we tried mobbing in practice in the conditions of the work of our team. Some rules interfered with us, something we misunderstood, somewhere we made mistakes. Nevertheless, we felt on ourselves what it is, whether it is possible and whether we need to work in this style. According to the results of this experiment, we did not fully receive those values ​​that we identified for ourselves as the most important. It is worth considering that we tried mobbing for only one hour with too short shifts, because these results may not be the most reliable. When working on “full-time” mobbing, some problems will not arise, and some will be overcome after “adaptation” to the process. Probably, we simply did not manage to get the values ​​we needed in such a short time. To know this for sure, it is worth trying mobbing in other situations, but this will be a completely different story.

PS
You can read and see the following
related materials: GOTO 2017 - Mob Programming: A Whole Team Approach - Woody Zuill
Woody Zuill - A day of Mob Programming
Agilix Consulting Blog: How to kill queues and speed up a team using mobbing