How we tried mobbing

If the search engine to try to find mobbing or Mobbing, then a significant part of the results will be about "psychological violence against people." Therefore, it is better to immediately search 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 is the translation), but many articles in English. If you look at them briefly, then most of them are theory, and not a practical case study. Everyone says that it will help the team become more efficient, locally spread the project expertise, and develop soft skills in people. I myself tried mobbing in practice during one of the scrum trainings, and was, frankly, delighted! After consulting with the team, we decided to hold our mobbing test session.



Among the advantages of this approach to work, we have identified 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, try mobbing in practice. Secondly, to understand what are the minuses and negative factors in it exactly in our case. Third, determine whether he will bring the above values ​​to our team.

What is mobbing

The founder of mobbing as a work style Woody Zuill describes it as follows:

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

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

')

There are several roles in mobbing:

• Driver: sits on a common workplace, does strictly 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 right direction for team movement. It can be a driver and a navigator.
• Facilitator: monitors compliance with the rules, announces shifts, parks ideas. It is desirable that there was one person in this role.

Mobbing consists of a session, which consists of cycles, each of which consists of shifts.

A session is a period of time during which a team is working on a task. Before the session, the task is selected and divided into stages, and its goal is determined - what should be obtained as a result, for example, the increment of the functional.



Change - the time interval between the change of the driver and navigator roles. The shift usually lasts 15-20 minutes. Shorter shifts promote higher speeds and greater team involvement.

Rules of the game

During the shift, the driver sits at the common computer and does strictly 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 the role of the driver and navigator, they are transferred to other people in a predetermined queue: the current navigator goes to the mobile phone, the driver becomes the mobile browser, and the next person from the mobile phone becomes the driver. When each team member has visited each of the roles, the “circle closes”, that is, the cycle is completed.







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

Negative

Sometimes not quite understand the role of the navigator. At some point, for example, an analyst could be in this role, and the driver could be a developer. Navigator retold what the team tells him, not fully understanding “what it all means,” due to lack of development experience. As a result, there were situations when the navigator simply had no reason to send instructions to the team, because, first, the developer hears the command, so why should he need a mediator? Secondly, the driver understands how to act in this situation, but according to the rules of the role he has “hands tied”.



We also noted that if the navigator to determine the next step, you need to look at the next tab in the development environment, then you need to voice this thought and wait for the driver to switch the tab. He himself would have done it for the time when he voiced the request to the driver, with all "be so kind" and "please-thank you."



The difficulty was added by the fact that we have two developers working remotely. First of all, it added time to such an operation as “switching the rights to the cursor”: so that the remote control could show something on the screen, but not intercept the mouse control. To do this, it was necessary to expand the conference management window, enable the right person to control the cursor, and minimize the window. It happens not so long, but it is very distracting, knocks it out of the task (in which it has just started to dive), 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 it, “synchronize”, and only then move on.



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



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



Another team would like more time to think "silently" and discuss ideas, but frequent shifts provoked to try to explore more with their hands than they did in theory.



We took a case that was not the easiest for an hour-long experiment: a task from another project that was little known to our team. Most of the time, we figured out how that section of code in general works that we need to change. For the total 7 hours of work (1 hour for each team member), we didn’t really figure out which side to approach to solving this task.



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



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



The stumbling block was the settings in the development environment: each of the developers are comfortable with their own specific parameters. In this case, the development environment was one, and not everyone liked the settings, of course.



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



As you can see, some negative factors arose due to organization errors, but, nevertheless, they showed how to do better and why.

Positive

Participants noted that this style of work allows people who, in normal times, receive tasks from business, analyze them and test, to delve into the process of directly solving these tasks. They saw the work on them from the other side: what steps does the task go through in the way of 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 happening with the task at the moment.



It became obvious to some of us why developers often require a deeper 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, serves as a kind of team building: for the first time someone saw the direct work of another person, recognized the course of his thoughts in a certain situation.

results

After discussing the feedback from each other about the session, we came to certain conclusions.



According to our results, it turned out that in the mobbing it is not necessary to work with the entire team or, at least, not constantly. In our reality, if the whole team works only on one task, then negotiations with contractors are not held and applications from users are not processed. You can, of course, do this until your shift comes, but then you have to get distracted, switch to the task solved by everyone, then fall out of it again and remember where you stopped before the shift.



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



We had the impression that mobbing would work well when there were new developers in the team, or someone in the team decided to program. Then, when carrying out mobbing with experienced developers, beginners will quickly immerse themselves in the projects of the team, they will understand the generally accepted principles and rules of work.



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



We had an assumption that mobbing would work well in tiger-teams: teams that are formed to solve some urgent task. But it can work if, at a minimum, the team is in the same room and with the development environment prepared for the majority. Otherwise there will be a waste of time for unnecessary communication factors.

If the team has just been 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 no imbalance in knowledge about the project.



Of course, shifts are needed longer. At least 15-20 minutes, instead of our 5. And it is necessary to do something with the rule that the driver is only the hands of the navigator, without its head.



So, we tried mobbing in practice in the working conditions of our team. Some rules hindered us, we misunderstood something, we made mistakes somewhere. Nevertheless, we felt for ourselves what it is, whether it is possible and necessary for us 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 should be borne in mind 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 the “adaptation” to the process. Probably, we just did not have time to get the values ​​we needed in such a short time. To find out for sure, it is worth trying mobbing in other situations, but it will be a completely different story.



PS

You can read and see the following materials on the topic:

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 with mobbing