Keywords

1 Introduction

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 [1]. Mob Programming, as Zuill [1] describes, is similar to pair programming [3], where two persons work on the same computer and collaborate on the same code at the same time.

The main difference, compared to pair programming is that the whole team works together as part of the pairing. In addition to software coding, Mob Programming teams work together on almost all tasks that a typical software development team tackles, such as defining stories, designing, testing, deploying software, and collaborating with the customer [1].

Since the popularization of Mob Programming by Zuill [1] there has been Mob sessions experiences described in some papers [1, 5, 11,12,13, 15, 17, 18]. Mob Programming techniques also resembles the Randori [4] style of programming popular at Coding Dojos commonly used during sessions to learn new technologies and techniques [5].

This report describes common practices that could serve as standards in the Mob Programming sessions. We reviewed the most relevant Mob Programming literature and carried out experiments with teams practicing the technique. Our motivation is to find a way to develop quality software in the most productive way possible. The goal of this paper is to deepen the knowledge about Mob Programming by the conduction of case studies in an academic setting with three different teams and discover what we could learn about Mob Programming in practice.

2 Research Method and Organization of the Work

The authors have experience practicing Mob Programming [16]. The scope of the research involved a review of the literature and application examples to learn in the practice [6,7,8]. The literature review aimed to identify, analyze, interpret and report the relevant studies available to answer the research question “What are the practices used in the industry on Mob Programming?”.

The sources of the search for this paper are IEEE Xplore (ieeexplore.ieee.org), ACM Digital Library (dl.acm.org), SpringerLink (springerlink.com), Elsevier, others websites like Agile Alliance, Google, and Portal for Periodicals of the CAPES (periodicos.capes.gov.br). The search string used was ‘Mob Programming’ that found thirteen studies, that were evaluated based on the inclusion and exclusion criteria described in Table 1, with emphasis on EC3, to exclude abstracts and slides. The eight accepted papers passed in all inclusion criteria and the five rejected papers did fail in either one of the exclusion criteria.

Table 1. Inclusion and exclusion criteria.
Full size table

We conducted Case Studies of Mob Programming with three teams in an academic setting, trying to validate the literature findings and also to provide new insights. We looked for common aspects and practices involved. The Participant Selection process was: who had enrollment at LabXP and voluntarily did accept to collaborate with this research. Fourteen people participated, thirteen men, and only one woman. The fourteen people were members of the three teams and answered all the questions, twelve individual questions, and forty-one team questions (two questionnaires). The response rate for the survey was 100%.

The survey design split into two parts, a first about one questionnaire with individual questions, and a second with questions thought to the team, looking for examining their experience practicing Mob Programming about relevant aspects described in the literature.

The first questionnaire got fifty-six individual answers of the all fourteen participants. The team questions of the second got one hundred twenty-three answers of the three teams. Below are more details about the two questionnaires.

Individual Questions of the First Questionnaire:

  • How many years have you been programming? (educational and professional experience in any language)

  • How do you evaluate your current level of knowledge in the programming language used currently?

  • Do you like Mob Programming? Did you Have practical experience with Mob Programming before this course?

  • How would you compare Mob Programming with other practices?

The Second Questionnaire is About the Experience with Mob Programming at LAB XP Was Answered by Each Team and Had Questions Related to:

  • The setup of the room and also a description of the Mob setting;

  • Driver rotation;

  • Retrospectives and mini-retrospectives;

  • Automation of the job;

  • Avoiding idle time;

  • Learning as a team;

  • Groupthink;

  • Collective intelligence;

  • Learning and mentoring;

  • Continuous Improvement.

All projects are open source. The consent term, photos, two questionnaires and all answers of the fourteen members of the three teams are available online at the IME-USP CCSL Wiki [28].

The paper has six sections. The literature review is following, in the next section, and looking for aspects related to Mob Programming. In the fourth section, are the details of the case studies. After that, in the fifth section, is the analysis of the results. In the last section of this paper, we conclude and address the limitations. The acknowledgments are in the end before the references.

3 State of the Art

We review the literature of Mob Programming looking for patterns of relevant aspects and practices involved most frequently used that guided the case studies. The next subsection is the background. Subsequently, Mob Programming aspects are analyzed.

3.1 Background

Tens and hundreds of interactions between people occur every day in their work. The people express ideas, discuss problems, explore possible solutions, and share thoughts all day long. To make it possible and to keep this high level of communication happening throughout the day, the team must adopt the principle of treating each other with kindness, consideration, and respect [1].

Retrospectives are used in Mob Programming sessions [1]. In these ceremonies, the team frequently evaluates what is working for them, what problems they might be having, and how they can improve. These are usually quick and focused on one item.

A possibility to Mob Programming is adopting the Driver/Navigators pattern adapted from Llewellyn Falco’s “strong” pair programming style [10]. The basic rule is for an idea to go from your head into the computer it MUST go through someone else’s hands.

There are two roles: the Driver, and the Navigator. The Driver has the possession of the keyboard. The Navigators discuss the idea being coded and guide the Driver in creating the code [1].

The team adopting Mob Programming has the possibility of a timed rotation. Each team member plays the role of Driver with the possession of the keyboard for a short time. The timer remembers the current driver when can pass the possession of the keyboard to the next driver when their turn ends up [1].

Another important aspect is the configuration of the room. The room must be physically comfortable while the team members work relatively close to each other, using shared monitors, keyboards, computer setup, and programming tools. There is only one computer in use for programming [1].

A set up of the room possible is two projectors or monitors. The goal is to keep the screens at about the same size, general position, resolution, and brightness to make them comfortable to work with all day long. There are also two keyboards and two mouses (a simple one and another ergonomic one).

Everyone has the choice to suit him/herself in the better way. Each team member has its own chair which is moved around on the different roles (Driver or Navigator). Thus, the people not need constantly readjust the chair settings making each one stay as comfortable as possible [2].

Finally, the room has a rolling magnetic whiteboard to keep track the work in an informative workspace. Figure 1 illustrates a setup that worked very well and had been seen it at some companies [2]. A possibility is to have one, two, or more monitors. The readjustment of the monitor height to be a height suitable for everyone.

Fig. 1.
figure 1

A setup that has been used it at some companies [2].

Full size image

3.2 Aspects and Practices Involved in Mob Programming

Here, we present the results of the literature review about aspects and practices involved in Mob Programming. Table 2 is a correlation of the selected papers for this study and all others papers. We only consider a common aspect when is cited in at least two papers.

Table 2. Practices versus papers.
Full size table

Setup of the Room. The setup of the room is one of the pillars of Mob Programming [1] and the configurations are described in details by all papers [1, 5, 11,12,13, 15].

According to Boekhout [12], the team found the screen too small, so it was hard to get everyone in a position near enough to it, due to all the desks. Distractions from outside were an issue that causes many interruptions. They have a room designed for training that was a little more isolated, with fewer interruptions, a projector and a big monitor for presentations. The team quickly discovered that the resolution of the projector was low and harmful. A high-resolution projector is a suitable solution. Then they had to use the big monitor. The team also decided to use proper office chairs, and have everybody move around keeping their chair to save time and avoid continuously fiddling with the chair configuration. Figure 2 illustrates a setup of the room using one projector.

Fig. 2.
figure 2

The setup of the room using one projector [12].

Full size image

Wilson [5] also describes an issue about the lower resolution of television or projector. The solution was to supplement paired workstation with an additional 50-in monitor that was a mirror of the workstation screen. It has been placed at right angles to the actual monitor, with the intention of the team watching the big screen and the driver can see both the screen and the rest of the team. Figure 3 illustrates this possible configuration.

Fig. 3.
figure 3

Running a four people mob. The driver is in the background [5].

Full size image

Driver Rotation. In the opinion of Wilson [5], the ideal time of rotation for a Mob of 4–6 people seems to be 5 min. But, for a Mob of 3 people, ten minutes was more appropriate.

In the report of Kerney [11], a team consisting of five people rotates who has the possession of the keyboard at each fifteen minutes. But, not always means that the team must rotate when the timer is up, the team decides in each case and sometimes not use fifteen-minute rotations. Change the time of rotation in special circumstances, such as for visitors or learning sessions.

In the report of Boekhout [12], the team copying Woody’s video [19] started with a rotation of ten minutes. Unfortunately, it seemed to them that every change of driver and navigator became an interruption and it took the team time to get back to focus on the problem at hand. There was clearly no sign of flow. So, they followed a tip that Boekhout [12] got from Llewellyn at Agile 2015 [33] and proved to be very important: lower the rotation cycle from ten to four minutes. By rotating so quickly, the switch has to go smoothly, so that you really need to make sure the workspace is good, you have a good timer and most important, that everybody is fully involved all the time. After a while, another team slowed to five minutes and declared that worked better for them too.

Retrospectives. In the view of Zuill [1], the team always looks for ‘action items’, and limit themselves to only one or two that they can use to ‘tune and adjust’ the process. They have found that having more than one or two ‘action items’ is almost always counter-productive. The team also set aside from half an hour to an hour to reflect on the last week or two. In these sessions, they gather information on sticky notes, do affinity groupings, dot-voting, and have conversations about the things they have observed and new things they would like to try.

There are also Just-In-Time Ad-hoc retrospectives. When anyone on the team notices something they feel we should reflect on, the team simply go ahead and do it while the experience is fresh. These are usually quick and focused on one item [14].

Kerney [11] described that the team does the retrospectives immediately when they found a problem. For example, the team realized that the projectors they had were constantly going dim, and it made the text hard to read. The immediately team tried several adjustments to fix it until they found a solution.

According to Boekhout [12], a core practice for the teams was the hourly retrospectives. An hourly retro needs to be short and to go to-the-point. The team started with a simple positive/negative items system and made sure this was visualized on their daily scrum board. Figure 4 illustrates this board.

Fig. 4.
figure 4

An early task and retro board - notice the focus on the hourly retro [12].

Full size image

The Fig. 4 shows the basis of the board is the horizontal axis for the hourly blocks. According to Boekhout, every hour the corresponding column is used. The top part for positive, the lower part of the improvements. The left of the board is a basic scrum board (To Do/In Progress/Done), turned on its side, where the team keeps track of the tasks about the user story of the day [12].

Automation. Kerney [11] mentioned that the team strives to make things as fluid as possible so that they do not have to break their flow. Some benefits as such as the team have an environment that is easy to maintain, and people cannot focus all the time on something that is tedious.

Structured Breaks. According to Boekhout [12] and Griffith [13], full involvement all the time can be exhausting. So the team made sure that every hour there was a 5–10 min break after the retrospective where people weren’t allowed to be behind the screen. Even then a full day can feel like a marathon [12].

4 Case Studies of Open Source Software

The programmers are attendees of LABXP, a regular course offered by the University of Sao Paulo, to graduate and undergraduate Computer Science students. First, the teams watched a lecture about Mob Programming with Alfredo Goldman and Joseph Yoder. They showed one video to the attendees about the time-lapse of a full day of work of a team of Mob Programmers [19].

The course requires a minimum of at least eight hours per week of dedication, and there is a lunch once a week, to allow the students to share experiences. The conduction of these examples of Mob Programming application in an academic setting with three different teams began in 08/08/2016 and finished on 12/12/2016. All the projects are open source. A questionnaire was applied to deepen the knowledge about the experience of the fourteen team members.

4.1 GeoXPerience: gitlab.com/geoxperience

A georeferencing platform for Casa dos Meninos, a social project [27]. It is a web georeferencing system that allows the user to create customized maps [26].

The website through a CSV file upload latitude and longitude data on a map to show the coordinates of the Basic Health Units of the City of Sao Paulo, as well as any other point on the map of interest of the user.

4.2 The Game of Life: github.com/Automata-Life

Automata.Life is a multiplayer web-based game based on JohnConway’s Game of Life where several players need to fight for the survival of their single-celled species in an arena like Agar.io.

You can ‘program’ your cells to better try to dominate your space, or yield under the forces of Darwinism [24, 25].

Figure 5 is a photo of the team of the game of life working in the programming, note that they are using a laser pointer, making easier to point an issue in the source code to be fixed. They had two projectors available and computers to parallel searches.

Fig. 5.
figure 5

The team of the game of life is working in the programming, note that they are using a laser pointer, making easier to point an issue in the source code to be fixed.

Full size image

4.3 Mezuro: mezuro.org

Mezuro is a free/libre web platform for collaborative source code evaluation. Able to evaluate source code with the most popular SCMs (like Git and SVN), just by providing its URL.

For now, it can evaluate C, C++, Java, Ruby, Python, and PHP source codes, but the Mezuro team are looking forward to supporting more languages in the future. Mezuro is continuously under development [20,21,22,23].

4.4 Questionnaire: ccsl.ime.usp.br/wiki/SwarmQuestionnaire

Consent term, photos, two questionnaires and all answers of the fourteen members of the three teams, are available online at the CCSL Wiki of the IME-USP [28].

5 Result Analysis

Table 3 correlates the answers of the questionnaires with the aspects that were considered relevant by previous works and explanations emerged using the axial code technique of Grounded Theory.

Table 3. The answers that justify the aspects and new insights.
Full size table

During all process, we (the researchers) takes photos and wrote memos. These memos contain the key points observed to help us in their categorization. After, we reviewed again the literature looking for answers that would contribute to formulating a theory based on the results produced by the questionnaires and metrics. Figure 6 shows the programming experience of all the fourteen members (thirteen men and one woman).

Fig. 6.
figure 6

Programming experience of team members.

Full size image
Fig. 7.
figure 7

One member of the team is pointing with the hands an issue in the source code.

Full size image

Mob Programming reflects very well the Weinberg [32] idea of ego-less programming, where the software is owned by the team as a whole, instead of the individuals being responsible for problems with the code.

We agree that different types of collaboration are suited to different kinds of problems. If the particular problem stem from the team not having a shared understanding of the project, Mob Programming that involve the entire team is a great approach [1, 5, 11,12,13, 15, 16, 29]. Western Electric made experiments attempted to determine the relationship between light levels and worker efficiency. The data compiled by the Illumination Experiments indicated only a minor correlation between light levels and worker productivity [30]. However, one interesting observation is sometimes when increasing the light level, the productivity grows up and when decrease the light level the productivity grow up too. Thus, the light experiment showed that increased interest of the workers increased productivity. Mob Programming increase the satisfaction, bond among team members, and learning of the software developer. These are factors of productivity that could justify the use of Mob Programming.

Mob Programming in an open work-space environment increases the Integration Among Teams in the LABXP course, that is one relevant factor to Inter-team Knowledge Sharing and open work-space environment provide great value, but software developers have to deal with the problem of noise [31].

Overall, there was a very positive experience to all teams. Figure 7 is showing the team of the Mezuro working in the programming. In the photo, one member of the team is pointing with the hands, an issue in the source code. A laser-pointer seems to be a good idea.

6 Conclusion and Limitations

We confirm the literature reviewed about the advantages of the use of Mob Programming over other techniques to sharing knowledge, learning, and satisfaction of the programmer. We also confirm that sometimes it is better to alternate with other techniques like pair programming. Additionally, we noted that collaboration among teams is improved and the bond formed among the team members.

Our answers to questionnaire did not confirm the literature that most programmers have practically non-existent moments of frustration in a Mob Programming session. We observed that in moments when nobody of the team knows a tool/framework was exhaustive to the whole group to approach these situations. When no one of the team knows a specific technology, it is better to do individuals searches to learn and after regroup again.

Limitations. The case studies performed are a qualitative research strategy and not permit generalizations, but all our data (source code hosted at Gitlab or Github, metrics, and questionnaires) are open source, thus could be audited. Our questionnaire is very extensive because we tried to confirm all details observed, these data are auditable observations available publicly in the Wiki.