Faculty of Technology Department of Informatics

(1)

Mob Programming and its impact on the developer's well-being and individual performance

Author: Philip Björklund Author: Jacob Fridebo Supervisor: Fisnik Dalipi

Examiner: Sadaf Salavati & Patrik Elm Term: VT20

Subject: Informatics Level: Bachelor

(2)

Abstract

Mob Programming has become increasingly used in today's software development teams due to its new and innovative work approach. Mob Programming is a collaborative work method that was first introduced in 2002 and was described as a team consisting of two or more developers working together in the same space, at the same time, on the same issue and at the same computer. The Driver and Navigator roles are often used in conjunction with the work method to enable a dynamic work structure.

The previous research carried out regarding Mob Programming has focused on its general structure, benefits, and risks when using it. Previous research has also investigated how the work method is being used in different software development teams. A lot of previous research has been studying the subject in a general manner which fails to bring up the individual in relation to the work method.

This study aimed to evaluate the impact of using Mob Programming on a daily or occasional basis regarding employee well-being and individual performance. The study also intended to investigate differences between the daily and occasional users of Mob Programming. A qualitative method with semi-structured interviews and observations was applied for its ability to extract in-depth and valuable information.

The participants chosen for this study derived from four different development teams who worked at Fortnox in Växjö where one of four teams used Mob Programming on a daily basis. A thematic analysis was used to organize and create a structure regarding the information from the interviews. Three themes with specific sub-codes were created using the thematic analysis: Learning, Team dynamics, Individual dynamics, which derived from the interview questionnaire.

The study found that the majority of the informants were impacted in a positive way regarding well-being when using Mob Programming. Reduced individual work pressure and stress were two of the prominent factors that contributed to this.

However, some individuals felt negative about the work method. This was often due to the feeling of being constantly watched or not being comfortable with the team- based structure of Mob Programming. The most noticeable findings regarding individual performance were positive in relation to knowledge sharing and problem- solving due to the "one-piece flow” that helped the teams streamline their work process from start to finish. The study found that the use of the Driver and Navigator roles was the most pronounced differentiation between the daily and occasional users of Mob Programming. The findings pointed towards a more structured and proper use of the roles when observing the daily users in comparison to the occasional users.

(3)

Sammanfattning

Mobbprogrammering används alltmer av dagens mjukvaruutvecklingsteams på grund av dess nya och innovativa arbetsmetod. Mobbprogrammering är en samarbetsmetod som introducerades första gången 2002 och beskrivs som ett team bestående av två eller flera utvecklare som arbetar tillsammans i samma utrymme, samtidigt, på samma problem och på samma dator. Driver- och Navigator-rollerna används ofta i samband med arbetsmetoden för att möjliggöra en dynamisk arbetsstruktur.

Tidigare forskningen utförd kring Mobbprogrammering har fokuserat på dess allmänna struktur, fördelar och risker vid användning. Tidigare forskning har också undersökt hur arbetsmetoden används i olika mjukvaruutvecklingsteam. Mycket av den tidigare forskningen har studerat ämnet på en generell nivå som inte utforskar individens förhållande till arbetsmetoden.

Denna studie syftade till att utvärdera effekterna av att använda Mobbprogrammering dagligen eller emellanåt gällande anställdas välmående och individuella prestationer.

Studien avsåg också att undersöka skillnader mellan de dagliga och tillfälliga användarna av Mobbprogrammering. En kvalitativ metod med semistrukturerade intervjuer och observationer tillämpades för dess förmåga att utvinna djup och värdefull information. Deltagarna som valts för denna studie härstammade från fyra olika utvecklingsteam som arbetade på Fortnox i Växjö. Ett av dessa fyra team använde Mobbprogrammering dagligen. En tematisk analys användes för att organisera och skapa en struktur gällande informationen från intervjuerna. Tre teman med specifika underkoder skapades med hjälp av den tematiska analysen: Lärande, Team dynamik, Individuell dynamik, som härstammande från intervjufrågeformuläret.

Studien fann att majoriteten av informanterna påverkades på ett positivt sätt angående individernas välmående vid användning av Mobbprogrammering. Minskad individuell arbetspress och stress var två av de framträdande faktorerna som bidrog till detta. Vissa individer kände sig dock negativt inställda till arbetsmetoden. Detta berodde ofta på att individerna kände sig ständigt iakttagna eller inte trivdes med den teambaserade strukturen. De mest märkbara fynden angående individuell prestanda var positiva i förhållande till kunskapsdelning och problemlösning på grund av "one- piece flow" som hjälpte teamen att effektivisera sin arbetsprocess från början till slut.

Studien upptäckte att användningen av Driver- och Navigator-rollerna var den mest uttalade differentieringen mellan de dagliga och tillfälliga användarna av Mobbprogrammering. Resultaten pekade på en mer strukturerad och korrekt användning av rollerna när de dagliga användarna observerades i jämförelse med de tillfälliga användarna.

(4)

Keywords

Mob Programming, Well-being, Individual performance, Qualitative study, Thematic analysis.

Acknowledgments

First and foremost, we want to thank Fortnox for the opportunity to perform our qualitative study at the offices. In addition, we also want to thank the 13 informants from the development department at Fortnox who kindly took time out of their day to assist us, making the qualitative study valuable. We also want to give a big thank you to our contacts at Fortnox, Victor Grevik, and Niklas Gärdebrand who supported us along the way with valuable information and guidance. Lastly, we want to thank Fisnik Dalipi for the supervision and input over the course of this thesis.

Växjö, 2020-06-12

Philip Björklund & Jacob Fridebo

(5)

Appendices

Appendix 1: Questionnaire

(7)

1 Introduction

Software development is becoming increasingly relevant and important part of today's business. This results in a higher interest regarding how the employees work and which work methods are most effective. Mob Programming is a collaborative work method that can be used in a variety of different situations and for all types of issues.

Many of today's IT-departments are utilizing team-structure as an approach to divide workload and domain expertise. This way of working often requires teamwork and communication. Mob Programming enables development teams to take their teamwork to a whole new level with its unique work methods.

According to Stephenson (2019), Mob Programming also known as MP is a new work method commonly used in software development teams. The method was first introduced in 2002 and was described as a team consisting of two or more developers working together. Zuill (2014) further describes it as a team working in the same space, at the same time, on the same thing and on the same computer. The work method can be used and applied to all kinds of tasks a typical software development team comes across such as story building, designing, testing, and deploying.

One of the most important hardware that is being used by a software development team practicing Mob Programming is the computer. All the code that is written by the team is entered through a single computer as well as other operations such as designing, testing, and other actions involving the whole team. A secondary computer is also commonly used for other activities such as email, looking at databases, and trying things out in relation to the mob (Zuill 2014).

Mob Programming commonly uses the Driver and Navigator arrangement. The driver as a role is responsible for typing in the code while the Navigators guide the Driver and discuss the code being created. Thus, the Driver is responsible for all the mechanical actions in relation to the mob. Therefore, the Navigators must articulate and express their ideas slowly and methodically to make the Driver's job as simple as possible. A role rotation is often implemented (15 to 20 minutes) to make it more stimulating for the workers within the team (Zuill 2014).

Team size is a frequently asked question when it comes to Mob Programming. There is no single answer to this question therefore it is up to the team to decide what works best in the specific scenario. A valuable way of analysing if the team size is too big or small is to consider this question "Am I contributing or learning something when working in the mob?”. If the answer is no, it is a good idea to start working on your own or maybe consider splitting the mob into two different ones for more and improved work-efficiency (Zuill 2014).

(8)

Mob Programming is often considered to be a part of or associated with the Agile workflow. An important aspect of Agile workflow is the use of Retrospectives.

Software development teams often use these kinds of methods on a routine basis to become more effective regarding Mob Programming. It is common to reflect for 30 to 45 minutes on the last two or three weeks of the team's work. Typically, the information will be written down on sticky notes, using dot-voting and discussing the different topics the team has observed along with things the team wants to try. To make information more structured the information will be placed in different categories such as "What needs help", "What we want less of" and "What is working".

This makes it easier for the development team to get a grasp of what is meaningful to the team. An essential part of the Retrospective is to find "action items". The purpose of the actions is to tune and adjust specific areas regarding Mob Programming to make the work method more effective. Limiting the “action items” to a maximum of two ensures that the team stays focused on the specific items and prevents the workflow from getting counterproductive (Zuill 2014).

Mob Programming is considered to be a new and innovative way of working as a software development team. Teams around the world are using the work method in many different ways such as on a daily basis or several times a week. It is also suitable to use Mob Programming for particular tasks when emergencies or hard problems need to get solved (Zuill 2014).

1.1 Purpose of the study

The purpose of this study is to investigate the well-being and individual performance of employees using Mob Programming as a work method daily or occasionally. The main focus is to examine these two variables on an individual level, to attain more information regarding the employees, not the company or division. These two variables are relevant and important to study because of the impact it has on development teams. Well-being and individual performance have the potential to make or break a successful development team. Individuals can potentially be affected positively while others may be affected negatively regarding well-being and individual performance when using Mob Programming. The work method can become a problem when individuals react negatively. Moreover, the study's goal is also to examine the difference between employees using Mob Programming daily and employees using Mob Programming occasionally. This will help the study to find potential differences between daily or occasional users of Mob Programming regarding well-being and individual performance, which are the two main variables most interesting and relevant for this study. The ambition is to also fill a knowledge gap regarding the comparison between teams using Mob Programming on a daily basis and teams using Mob Programming occasionally. This area of the subject has a small amount of existing research which further supports and strengthens the purpose of this thesis. Mob Programming is a new way of working and therefore lacks history as well as background. To get a better understanding of Mob Programming as a work method further research needs to be done. This is also one of the main reasons why this thesis is initiated, to further develop the subject and contribute information to the area.

(9)

1.2

Research questions

The thesis study intends to resolve the following questions:

RQ 1: What is the impact of using Mob Programming on a daily or occasional basis regarding employee well-being?

RQ 2: What is the impact of using Mob Programming on a daily or occasional basis regarding individual performance?

RQ 3: How does the impact regarding well-being and individual performance differentiate between daily or occasional use of Mob Programming?

1.3

Definition of research concepts

The research questions chosen for this study revolves around the two main variables, employee well-being, and individual performance. In this study, the intention is to evaluate the variables with these concepts to give a better understanding of how the employees are affected by Mob Programming. The two concepts are further described in the next subsections.

1.3.1 Employee well-being

The employee well-being is concentrated on evaluating and exploring how the individual employee’s well-being is affected by working within a mob. Below we explain the different elements of employee well-being that we are studying.

• Ergonomics - is referring to the employee's experience of ergonomics when working in a mob. Ergonomics is a big part of physical health in the workspace.

It is important to have a composition that is designed for the way you work. An awkward posture, extreme temperature, or repeated movement affect the body negatively and result in fatigue, discomfort, or pain (State of Oregon 2020).

• Mentality - is believed to be mutable according to Daun (1996). The mentality can also change in correlation with society and other outside influences.

However, because the mentality is transferred through generations in the form of upbringing it is believed to guarantee a historical continuity. In our study, the mentality will be referring to the attitude and mindset of the individuals towards work and their ability to provide results within a mob.

• Communication (Social aspect) - can be defined as the behaviour that enables the sharing of information between interacting entities according to Scott-Phillips (2008). In our study, the concept is referring to the ability to build work relationships with team members to have a positive work atmosphere within the mob.

• Flexibility - concerning work is often related to time and location elements according to Gibson (2003). In our study the concept is referring to individual flexibility as a team member in a mob, the possibility to, for example, individually work, use sick days, go to individual meetings, or take breaks.

(10)

• Stress - is often linked to the emotional and physiological reaction to stressors which can be circumstances that initiate the stress response according to Lloyd et al. (2002). In our study, stress is referring to the level of stress an individual experiences from work and the pressure from workload or deadlines when working in a mob.

1.3.2 Individual performance

The individual performance focuses on finding out how Mob Programming affects the performance of individual members in a mob team. Below we explain the different elements of individual performance that are included in the study.

• Knowledge development - is according to Adenfelt and Lagerström (2008) argued as being a multilevel phenomenon, including the individual, the group, and/or the organisation. It occurs through operating procedures, practices, and routines that are understood and shared. This thesis views knowledge development as the knowledge procurement of an employee while being a part of a mob.

• Knowledge sharing - is defined by Adenfelt and Lagerström (2008) as the provision and receipt of knowledge, shaped by both the sharing and receiving units. In this thesis, knowledge sharing is viewed as the activity of knowledge being exchanged between employees within a mob.

• Communication (Work aspect) - can according to Scott-Phillips (2008) be explained as the transfer of information between a sender and a receiver and the behaviour by which one member conveys information to another member. In this thesis, communication-related to the work aspect is referred to as the employee's expertise in using communication as a tool to solve tasks in a mob environment.

• Quality of work (e.g. Code) - of members within the mob refers to the quality of code produced. According to Greiler et. al. (2015) can code quality be measured by counting the number of bug fixes that are linked to a code artifact. Assuming a higher number of bug fixes lowers the code quality of that artifact. In this thesis, the quality of work is an employee's ability to contribute work with high-quality standards within a mob.

• Effectiveness - can be defined as accomplishing goals and obtaining needed resources according to Cameron (2015). In our study effectiveness is referring to the employee’s ability to successfully produce desirable results in a mob setting.

• Accountability - is defined by Frink and Klimoski (2004) using two themes. The first concerns the context, who and what is involved in a given situation. The second involves the notion of an evaluation and feedback activity in some form.

This thesis will combine the two themes and referee accountability to the employee’s ability to take personal responsibility in a mob environment.

• Agile ability - is related to the agile principles that according to Dingsøyr et. al.

(2012) can be defined as relying on technical excellence and simple designs, creating business value by delivering working software to users at regular short

(11)

intervals. In this thesis, the agile ability is referred to as the employee's ability to exercise agile methods in a mob setting.

1.4

Limitations

The study is limited to the developer employees of Fortnox regarding the interview and observation population. This results in a limited demographic and number of people being interviewed and observed.

This study will not further explore the concept of health and its implications as we only intend to investigate the well-being of individuals on a base level concerning using Mob Programming.

(12)

2 Literature Review

In this section, a review of the literature regarding Mob Programming as a work method is conducted. This includes literature mentioning Mob Programming's origin, positive and negative aspects of Mob Programming, employee well-being, individual performance, and experiences about Mob Programming.

2.1

The origin of Mob Programming

The work method Mob Programming emerged in 2002 as a response to a development team getting assigned to restart the work on a previous project. The project had been put on hold for several months as the need had been to focus on more critical projects.

The team had previously tested and used different work methods such as Extreme Programming’s pair programming, Test-Driven Development, and a Coding Dojo approach to further enhance their work procedure and processes (Zuill 2014).

In the initial meeting, the team decided to familiarize themselves with the project by collectively analysing it in a meeting room using a projector and a single computer.

As a result of the team previously using different work methods that are based on working together the processes of analysing the code, database tables, and documents developed naturally. The team started to come up with new ideas for the project, writing tests, and changing code together as a group. At the end of the day, the team held a "mini-retrospective" meeting and found that the result of the new team-based work method was very productive so the decision was to continue the same way for the next day. Due to the productivity found in the new work method the team continued to work the same way the following two weeks. The team felt that they were rapidly improving the ability to communicate with each other, as well as their overall knowledge and the ability to find better solutions. The work method gave the team a deep and shared understanding of the project and the involved technologies.

Over the next 3 years the team continued to work with the basic pattern of collaboration delivering many different projects and over that period the name “Mob Programming” came about to summarize the method used (Zuill 2014).

Mob programming can be seen as an evolution of the pair programming method used in Extreme Programming (Zuill 2014). The basis of Extreme Programming also known as XP is to work together in pairs, having two programmers work together on one computer and shifting the Driver role between the two. With Extreme Programming testing stands as a fundamental role, writing unit tests before programming and keeping all of the tests running at all times, testing and integrating the whole system several times a day, and starting projects with a simple design that constantly evolves making it more flexible and reducing unneeded complexity (Beck 2000). The idea behind pair programming is that two brains and four eyes are better than one brain and two eyes. Quicker response and continuous to problems that would otherwise stop one person in their work. Teams that have used pair programming have the result of increased quality and by working through problems quicker being able to create less and more effective code to accomplish the same thing (Agile Alliance n.d.). Mob Programming also takes the communication and whole team element from Extreme Programming (Zuill 2014). Valuing that face-to-face is the best communication form, having an open space for the team without barriers such as

(13)

cubicle walls to limit the communication. Team functionally is valued as a key element in both Extreme Programming and Mob Programming, having a well- functioning with necessary roles for a product to form and satisfy the needs of the team so they can be able to work together on a daily basis to accomplish a specific outcome (Agile Alliance n.d.).

2.2

Potential Benefits of Mob Programming

At first glance, mobbing appears to be a waste of resources and time when a whole team is working on the same task instead of everyone working independently on different tasks. There are a few potential benefits to this arrangement. The first one is to reduce managerial overhead. This means that the employees in a team using Mob Programming and talking to each other all the time have a much lesser need for emails, meetings, code reviews and code mergers, etc. This is because all of the individuals are constantly working together, and every line of code is created by the team is therefore analysed and discussed by the present members of the development team (Balijepally et al. 2017).

Another potential benefit that has shown to be present when using Mob Programming is reduced communication bottlenecks. This is surprisingly a big and important part of a developer's work. Time wasting is often linked to information or clarification being needed on a user story or requirement. The time needed to get an answer to a question blocking the developer from proceeding can vary widely depending on what type of question it is. This type of time-wasting can escalate quickly when it starts to affect productivity at the project level. To stay busy, developers will often tend to take up new tasks from the "to do" section. This type of work can be the cause of reduced productivity in regards to the original task. When the developer receives the answer to the original task it can take a toll on their cognitive stamina as they must switch back and get up to speed on the task again. This type of queue times to get an answer to a question is often drastically reduced when teams are using Mob Programming (Balijepally et al. 2017).

By using Mob Programming as a work method, development teams often tend to simplify code design, minimizing feature creep, and reduce test bloating without even knowing it. “One-piece flow" is a term used regarding Mob Programming as the workflow is boiled down to a single piece of workflow that the mob is working on.

The members of the mob are always working on a task until it is completed and merged/delivered to the stakeholder before moving on to the next task. This type of workflow allows the mob to instantly give the code a live assessment and feedback.

Thus, helping the team to pinpoint what type of useful feature or task to work on next (Zuill & Meadows 2016).

Mob Programming generally helps with reducing the technical debt in a development team. This refers to different shortcuts and quick fixes that are done when developers are out of time and need to get something done in the shortest amount of time. When this type of behaviour is allowed to grow it becomes increasingly hard to make changes or debug the code. When using Mob Programming this behaviour is quickly discarded because of the constant inspection and review of the code done by the

(14)

navigators. This will also encourage the team to create coding standards and overall cleaner code (Zuill & Meadows 2016).

Working together in a mob will generally make everyday distractions and interruptions less prominent. This is because the team decides when working in the mob how they are going to deal with the interruptions. Thus, a team decision on every interruption is being made and how the matter is going to be dealt with. This can mean that one person in the team goes and deals with the problem or the whole mob drops everything and takes care of the problem to address the issue as quickly as possible.

The negative impact of distractions is less noticeable this way when using Mob Programming because of the “group memory”. Since every member of the team knows exactly what is going on it is much easier for the team to get back to the original task after a brief interruption (Zuill & Meadows 2016).

Development teams using the individual work method have an inherent problem when it comes to finding the time and helping others who may be seeking it. This problem is usually the result of individual workload and the pressure to get it done.

Mob Programming takes care of this problem since everything the team delivers or releases is being worked on by every single member of the mob, therefore it is very unlikely that individual workload is a present or noticeable problem. It is the other way around when using Mob Programming. Answering questions and similar activities is not a distraction but a benefit to the whole mob. By raising questions and getting answers encourages knowledge sharing remarkably (Balijepally et al. 2017).

This leads us to the next potential benefit of Mob Programming. As mentioned before, continuous learning is often increased in a team using Mob Programming as a work method. This is possible because of the way Mob Programming is structured. When a whole team with different developers are working together on the same task, they are bringing their skills, ideas, and approaches to the table. This way of working will often result in new requirements regarding things such as tool usage, coding solutions, design patterns, shortcuts, and many more (Balijepally et al. 2017).

In a case study done by Buchan & Pearl (2018), the result was also found that Mob Programming helps with onboarding new novice programmers (graduates) to a development team. The team leader experienced that the learning was at an accelerated rate after a few months compared to similar graduates that did not take part in a mobbing development team. The possibility to learn from team members while still being an active part of a project helps graduates or novice programmers increase their knowledge within the subject. About having the novice member in the driver role assumptions can be made that it would slow down the processes due to their lack of knowledge, but the result disapproved of these assumptions. The result was that the novice got accelerated learning from it, the discussion was more diverse and included a novice point of view all to benefit the team.

(15)

2.3

Potential Risks of Mob Programming

Early adopters of Mob Programming experience multiple benefits and ways of working with the method. However, there are potential risks and uncertainty regarding Mob Programming that could negate the benefits. Therefore, the work method needs to be carefully managed to attain the sustainable results Mob Programming potentially brings (Balijepally et al. 2017).

Mob Programming can be tough to implement if the organizational culture is structured top-down. This means that the decision-making is often done by the higher up staff and therefore leaves little to no room for decision making for the employees further down the hierarchy. Since Mob Programming is structured as a self-organizing method, the top-down culture can be dreadful to the development teams using Mob Programming since they must wait for answers or decisions higher up in the hierarchy. This can result in reduced productivity regarding the mob (Balijepally et al. 2017).

If an organization is not using any agile methods and not familiar with the way of working, this can also affect the company's understanding of Mob Programming and thus not wanting to adopt it. However, if an organization is using some type of Extreme Programming such as Pair Programming, the switch to Mob Programming could be a lot smoother due to the similarities between the work methods (Balijepally et al. 2017).

Certain individuals can have a hard time adapting to the ways of Mob Programming.

This is often the case for people with a dominant personality. This dominant personality trait can result in talking over the other team members and steering the mob in a certain way. This can potentially result in an atmosphere where members start losing interest in the mob and want to start working on their own. Working together in a mob is generally voluntary and is therefore reliant on the members creating a hospitable environment for everybody to enjoy (Zuill & Meadows 2016).

It is also important to mention the importance of developer safety and fatigue. Teams working with Mob Programming are constantly around each other all day and are therefore very dependent on the setup and gear available. Having the right equipment such as comfortable chairs, electric desks, and appropriate monitors is key for long working days without straining the body. Office space is also an important factor that is crucial if teams are going to be able to talk out loud without disturbing other teams or employees nearby (Balijepally et al. 2017).

2.4

Experiences from using Mob Programming

The reason for adopting Mob Programming as a work method may vary from team to team. In a case study by Buchan & Pearl (2018), they focus on the experiences of one of around 50 different development teams in a well-established company. The organization supports the development teams to self-organize and work in different ways that suit their preferences, so the team in focus chose to adopt Mob Programming as one of their software development practices. The initial motivation for the team to adopt the practice was to use it as a means to skill up members in both coding and testing practices, as well as for the team to together get a shared

(16)

understanding of expectations of code quality. What the team experienced over the 18 months of mobbing together was a broad understanding including the elements of mobbing and its evolution, workspace, work types best suited for mobbing, and long- term productivity.

What emerged as the most optimal team size for the team was a mob of 3-4 people.

Unless the element being processed involved complex coding a team of over 4 people often felt overwhelming, members feeling that they were not contributing much and the trade-off between a reduced pace in a larger team and code quality was not worth it in terms of productivity. The occasional need for people to come and go for various reasons during mobbing was, in the beginning, a challenge as it disrupted the workflow of the team. But over time with more experience, the ability to smoothly leave and re-join grew to a benefit for the team as it gave the member flexibility and had a low impact on productivity. Due to the team consisting of members with different levels of coding experience, the tendency early on during the mobbing was to let the "experts" occupy the driver role a longer period since they made progress quickly. This easily resulted in the rest of the mob becoming passive spectators, while they watched the "experts" solve the problem. Over time the team shifted this behaviour to even distribution of the driver role and prefer to have a more novice driver as it gave a new perspective to the code and more diverse discussion. The usage of time-boxed mobbing sessions was found by the team to be an effective tool to use.

Having a set time for a maximum of 2 hours dedicated to mobbing, during this time the member would take regular short breaks roughly every 30 min to keep them fresh.

Members would often take their breaks at different times, allowing the work to continuously progress increasing the flow of work. During the time of using Mob Programming, all team members’ experience with mobbing increased. The team collectively progressed from novices to skilled in the actions and procedures of mobbing, being less determined by rules, and becoming more intuitive in the procedures (Buchan & Pearl 2018).

2.5

Conclusion

Mob Programming emerged in 2002 and can be seen as an evolution of the pair programming method used in Extreme Programming (Zuill 2014). With pair programming developers work in teams of two on one computer, shifting the driver role between the two. The idea behind it is that two brains and four eyes are better than one brain and two eyes. A quicker response to continuous problems that would otherwise stop one person in their work, generating an increase in quality and more effective code (Agile Alliance n.d.). Mob Programming takes the communication, whole team element, and team functionally from XP, valuing that face-to-face is the best communication form and defining necessary team roles (Agile Alliance n.d.).

The “one-piece flow" is one of the most prominent workflows that occurs when Mob Programming is being used. The term refers to the mob working on a task from start to finish while moving on to the next one. This will ensure that continuous feedback and live assessment take place throughout the development process. Individual workload will also be reduced when working together as a mob because every team member is working on the same issue. This results in fewer distractions and encourages questions that lead to an increase in knowledge sharing. Due to the

(17)

encouragement of asking questions and spreading knowledge between the members of the mob, the onboarding process of new novice programmers will also be affected in a positive way (Balijepally et al. 2017).

Mob Programming can sometimes be hard to implement if the organizational structure is top-down which means that the decision making is often done by the higher up staff. This makes it harder for the mob to make their own decisions regarding issues that undermine the whole work method. If the organization is not familiar with agile methods and have not practiced similar work methods, it can affect the implementation of Mob Programming negative. Certain individuals may not like the way Mob Programming is structured thus not feel comfortable working with it.

Dominant personalities can also be a problem for Mob Programming since the work method revolves around teamwork where every person of the team needs to be seen and heard (Zuill & Meadows 2016).

(18)

3 Research Method

This section describes and defines the research design and methodology used in the study. The section will also specify the different instruments and techniques used to collect, analyse, and process the data obtained.

3.1

Individualistic reasoning

Individualism is an important part of this study as the research methods result is based on the participants' answers. Individualistic reasoning implies that specific people are the most important data source through what they say or what they do. This means that organisations, markets, or companies can only be looked at as a unit or a summary of what the individual’s actions and thoughts are (Jacobsen 2002).

3.2

Qualitative method

The main reason for selecting the qualitative method for this thesis is due to its ability to extract in-depth and valuable information. We believed that this was the key to accumulate relevant information from specific individuals that possess knowledge and experience of Mob Programming. Therefore, we decided to focus on individuals within different teams to understand their perception of the subject.

Qualitative methods emphasize closeness as the main element when it comes to the understanding of an individual's perception of reality. To examine and investigate social phenomena’s we need to understand how humans perceive social reality. This cannot be done without observing the individuals, what they do, what they say, and let them speak by their own words. Observations and open interviews have therefore been praised as the ideal way of conducting this kind of research (Jacobsen 2002).

The qualitative approaches are structured in a way that makes them diverse, complex, and nuanced. Thematic analysis is often mentioned as the foundation for qualitative analysis. Thus, researchers need to learn and understand the concept as it provides valuable knowledge and skills that are useful when executing various forms of qualitative analysis. It is therefore believed to be a powerful tool across different methods (Braun and Clarke 2006).

3.3

Research design - Qualitative questionnaire and interviews

A questionnaire form was created to define specific questions that could potentially acquire information about the three different research questions. The questions were formed and designed to acquire information about the concepts mentioned in chapter 1.4 which helped answer the three research questions for the thesis. The questions in the questionnaire were divided into three different sections. The purpose of the first section with questions was about getting the interviewee in a comfortable state and warmed up. The second section of the questionnaire contained questions regarding well-being. The third and last section of the questionnaire involved questions regarding individual performance. This structure ensured that the questionnaire had questions that would answer the thesis research questions.

(19)

The interviews took place in a closed setting, meaning one individual at a time from the specific mob answered the questionnaire. Semi-structured interviews were selected in this case to enhance the data analysis of the information given by the interviewees. Therefore, it was easier to compare and analyse different answers given to the same questions.

3.3.1 Interview participants

The participants chosen for the interviews derive from a minority population after the limitations were applied to Fortnox’s development teams. A total of thirteen interviews were carried out at the Fortnox office. Interviews were carried out on four members in the only development team that used Mob Programming on a daily basis and as their primary work method. A total of nine different interviews took place in relation to the other three teams that used Mob Programming on an occasional basis.

This contributed to further enhance the comprehensive experience from the interviewees.

3.3.2 Data Collection

The interviews were recorded using smartphone devices to pick up the audio. Swedish was used during the interviews since the vast majority of the interviewees' native language was Swedish. This made it possible for individuals to express themselves in the best way possible. Smartphones were also used as a media share tool when files needed to be uploaded on the cloud for easier access.

3.4

Research design - Observations

The observations were selected in this thesis to help answer the third research question about the differences between teams using Mob Programming daily or occasionally.

To find the difference between daily and occasional users of Mob Programming, we believed that observations were necessary to acquire the proper information. Since interviews are often not able to reveal certain behaviours and habits that are linked to specific teams or individuals, we wanted to complement with observations to fill that information gap. Based on Mack et al. (2005) research, observations are useful in the sense of understanding and learning about the participant's social, cultural, and economic contexts. This makes it easier to extract interesting findings between the people, contexts, norms, and how they behave with each other.

Observations also enable the researchers to get more familiar with the setting in which the participants live. This will provide a nuanced understanding of the context that can only come from the personal experience of observations. Through the observations, important factors can be uncovered for a thorough understanding of the research subject that was unknown when the study was designed. This gives a great advantage as it helps with understanding the data collected through other methods e.g. interviews (Mack et al. 2005).

The observations were modelled after the research concepts mentioned in chapter 1.4.

This made it easier to create a structure when notes were taken during the observations. The notes from the two different observations were compared with each other to find the potential differences regarding the behaviours and habits of the different teams.

(20)

3.4.1 Observation participants

Observations were performed on two teams, the team that uses Mob Programming on a daily basis and one of the teams that use it occasionally. The goal was to perform observations on all four teams but as a consequence of the current situation with the Coronavirus, the goal could not be reached.

3.4.2 Data collection

The observations were recorded using a smartphone device to record the audio of the specific mobbing team. Smartphones were once again used as a media share tool when files needed to be uploaded on the cloud for easier access. Laptops were used to take notes on and also work as a reminder of what to look for during the observations since the research concepts were available on the computers.

3.5

Thematic analysis

A thematic analysis was used to organize and create a structure regarding the information from the interviews. This process made the information easier to handle and view as we went on to analysing the information.

Since the interviews were audio-recorded, we could later transcribe the interviews word by word which gave us a detailed description of the conversations. Jacobsen (2002) mentioned that it is very important for researchers to acquire a grounded and detailed rich description of the accumulated data and information from the qualitative study. Situations, interviews, and conversations should be registered as detailed as possible. This process is called “thick descriptions” and often contains plenty of details, analysis, and variations.

The concepts of 1.4 were used to make it easier to find interesting topics and information that was relevant for this study. This helped us systemize the accumulated information and made the screening process more precise and smoother. Jacobsen (2002) explained that it is important to set a rule to systemize and reduce indefinite information. In every process of analysing information, there is always a phase that includes screening and simplification of the accumulated information. This is a critical part of the analysis process to get an overview of the information. The "thick descriptions" is way too comprehensive and therefore impenetrable to others except for the researchers. Systematisation is necessary to be able to convey what has been found in terms of information.

After the concepts of chapter 1.4 were applied and implemented onto the information we started to look for patterns and similarities between the interviews. This process went on for a few iterations to find hidden correlations. When the iterations were done, we started creating different sub-codes that derived from the patterns and correlations found in the previous stage. Braun and Clarke (2006) mentioned it is important to give each data item the same level of attention to easier recognize interesting aspects that may form repeating patterns. These sub-codes were later categorized into themes that consisted of several sub-codes that had a connection with each other.

(21)

Themes capture valuable and important data concerning the research questions. The themes are structured in a way that represents a patterned meaning within the data set from the qualitative study. It is important to review and refine in this process to identify themes that do not fit or blend into each other. This is important to capture and identify the essence of what each theme is about and what aspect of the data they represent (Braun and Clarke 2006).

3.6

Validity and reliability

Using and performing interviews and observations on employees from different teams gave a more general understanding of the subject that could hopefully be applied to different developers. The questions asked in the interviews were carefully analysed beforehand to ensure that they were impartially phrased and gave the interviewees an unbiased basis when answering.

3.7

Ethics

Each team that took part in the qualitative study received an email asking for permission and explaining what the qualitative study was about. This made sure that the participants were well informed about the study before accepting and choosing to take part. The participants were also informed that they had the opportunity and right to withdraw from the study if they wanted to. Based on Willig and Stainton-Rogers (2017) research, informed consent is the definition of informing the participants of the research study about the general purpose of the investigation and the main features of the study. It is also important to mention about confidentiality and who will have access to the material of the interviews. Informed consent is also about clarifying the participant's right to withdraw from the study at any given time.

To secure and keep the accumulated information from the participants safe, a few different measures were taken. The first action was to store the information on our smartphones that were password secured. The information was also transferred to Google drive which also used a password mechanism. This measure made sure that unauthorized individuals did not have access to the information. The second action was to never mention or show the information to anybody else. This further strengthened the security of the information from the qualitative study. The last step that was taken to protect and secure the participant's information was anonymity regarding all of the information in the qualitative study. Thus, no team- or personal names were being stated in the thesis.

(22)

4 Results

This chapter will introduce the accumulated empirical information from the qualitative interviews and observations. The information regarding the interviews was divided into different themes and sub-codes to present it in a more structured way.

4.1 Results - Qualitative interviews

Table 4.1 Themes and Sub-Codes

Theme Sub-Code

Learning Knowledge sharing

Problem-solving Shared work-understanding

Team dynamics Competence

Responsibility Start-up period Interest collision Social interaction

Individual dynamics Stress

Motivation

This section includes relevant information from the accomplished interviews. Themes and codes are presented from chapter 3.5 with further explanations to declare the thought process behind them.

4.1.1 Learning

Learning is an interesting topic when it comes to Mob Programming because of its huge impact. The information that was collected through the interviews pointed towards a positive impact on the learning aspect concerning Mob Programming.

Knowledge sharing

The majority of the interviewees agreed that an increase in knowledge sharing was one of the most prominent and important aspects that Mob Programming contributes.

Below are a few examples of what the interviewees said regarding knowledge sharing:

“Mob Programming is a good foundation for it. The knowledge is also deepening inside of me when I am transferring it. New solutions and information about the knowledge come to mind that I don't normally think about when I'm working alone.”

Another interviewee talked about Mob Programming improving the onboarding process:

(23)

“I was new to the team and it was difficult to get an overall understanding of the system when you just sit by yourself even if you are not shy and get support from the team. Mob Programming is a good way of learning as we go through many parts of the project. This helps you learn a lot so that you are more familiar with the project.”

Problem Solving

All the interviewees expressed that mob programming positively impacted the problem-solving aspect and recognized that it was enhanced when working together within a mob.

“I think it’s positive with a mob because you always get different angles.

When you are alone you sometimes only come up with one idea and you must solve it that way. But when you work with others it brings in other ideas and you get different angles, so it's interesting and you learn things from that too.”

The development teams that occasionally use Mob Programming expressed the need for the work method when dealing with complex issues that require complicated solutions. An interviewee explained it as:

“That's why we run with mob programming on complex problems precisely because you have four to five people's skills. You can discuss a solution instead of sitting and pondering for three hours. It is faster to arrive at the solution if there are several people. So that part I think works very well, much better.”

Shared work-understanding

Several interviewees talked about the impact on shared work-understanding concerning Mob Programming. They believed that shared work-understanding improved in several ways when using Mob Programming:

“The team has a collective understanding and view of where we are regarding an issue. The members who are a part of a mob have an easier time achieving a shared work-understanding.”

Another interviewee explained the remarks regarding how communication is done:

“We don’t need pronounced communication in the same way. Everyone knows what we have done, and everyone knows what to do now.

Knowledge does not need to be passed on to others in the same way, everyone already has it. So, you skip a step in that way."

4.1.2 Team Dynamics

This topic was very important and relevant according to the interviewees since Mob Programming is a work method that relies heavily on the team and its dynamics. The

(24)

interviewees explained that depending on how successful the team dynamics are, Mob Programming will show different results for different teams.

Competence

Collective competence has proven to be one of the explicit and clear benefits of using Mob Programming. The interviewees explained that since the whole team is working on the same issue, it is much easier for the team to know what is being worked on and how it is being solved. The majority of the interviewees regarded this as a positive aspect for the team.

One interviewee talked about Mob Programming results in less of a need for documentation regarding issues:

“You may not need to document as well if it is just a thing that affects the team. There is a bit of writing but everyone who has been involved already has a hum about it.”

Another interviewee expressed that collective competence helps new members get a good feel for the system and its structure:

"We have a couple of new members in the team, it's very easy for them to be a part of the mob and get a better feel for how the codebase is structured and how systems interact."

Responsibility

Several interviewees explained that working in a mob means sharing the workload and doing all tasks together which affects the way responsibility is dealt with within the team. One interviewee explained the responsibility aspect of Mob Programming as:

“It's pretty nice because you no longer have the sole responsibility for something. Before we used Mob Programming, I always had the responsibility to help other people with issues that I was involved in. This led to a lot of interruptions which affected my work negatively. However, when we use Mob Programming everyone is involved and takes equal responsibility. This also means that everyone can help solve problems that you have been involved in. You can at least point to one or two people that excelled and contributed a lot to the task."

Another interviewee expressed their opinion on responsibility and what possible negative effects it could have for a team:

“I think the responsibility is more collectively, therefore you take more responsibility towards the team than before. But it's also because it's fun and usually it comes naturally. One of the dangers of Mob Programming is that you can have people just sitting passively. It doesn't feel like we've had that, everyone is contributing. Those who feel they are not contributing have done something else instead.”

(25)

Start-up period

A few interviewees pointed out that Mob Programming was very inefficient at the start with different kinds of problems that made the work method less attractive and inefficient:

“One day all of a sudden we started mob programming and the team prioritized one case at a time. This threw me off because you are used to working at your own pace and with multiple issues at the same time. That part was really hard for me to get used to. So, the start was stressful, you get used to a slower pace, so it gets better with time.”

Interest collision

Many interviewees explained that Mob Programming is a work method that brought the team together and demanded more communicative teamwork from the individuals e.g. how an issue was going to be solved. Below are a few takes on the topic from different interviewees.

This interviewee highlights that interest collisions do happen sometimes but there are models and work methods that can solve those types of situations:

"The closest conflict we have had is where we cannot agree on how to solve an issue. But there is a good model for that, we tested both solutions and decided what to do after that."

Another interviewee thought that Mob Programming helped and made the process more efficient when interest collisions do happen:

"It feels like people have an easier time expressing themselves. So even if there is an interest clash it has been easier to handle it in that group because you have more opinions on it straight away."

Social Interaction

The majority of the interviewees agreed that communication is key when it comes to Mob Programming. They believe that the members of the mob have to be more social and communicative in their way of working since the behaviour can impact the social interaction between the team members.

This interviewee talked about how Mob Programming made it easier for newcomers to socialize with the other members of the team and sped up the onboarding process:

“We take regular breaks where we can chit chat with each other and it helps to get to know each other, so I appreciate it as a newcomer. I think it is a great activity to speed up the onboarding process in the team.”

(26)

This citation from another interviewee brought up the social impact of Mob Programming in the way of communicating with members that they usually do not talk to that much:

“you talk to the people you don't usually talk to in the group. So, it became like a good relationship-building thing for us, so now we have an easier time communicating than before."

4.1.3 Individual dynamics

Individual dynamics is an interesting theme that focuses more on evaluating how the members feel when working within the mob. Many interviewees mentioned factors such as stress, motivation, and mindset affecting the wellness within a team.

Stress

The result from the interviews revealed that stress concerning Mob Programming can be affected both positively and negatively depending on the individual.

This citation from an interviewee brought up a positive impact on stress about Mob Programming:

“I do not feel the same pressure to perform when I am mob programming as I do when I am sitting alone. It feels like I can sit with an issue for several days and feel like I should be done with it at that point, which stresses me out. It’s quite the opposite while we are mobbing, everyone knows that it will take a certain amount of time for the specific issue and therefore it will not be quite the same stress for the tasks we do together as a mob.”

Another interviewee pointed out the constant overlooking of what you are doing as a Driver in the mob:

“The concept means that everyone is watching what you do. If you sit by yourself, you can make mistakes or do lots of tests without people looking. If everyone is looking at what you are doing, you want to be able to be quick and find everything the Navigators are pointing out which can be hard if you're new to the team.”

Motivation

Interviewees pointed out that the motivation towards work is affected by using Mob Programming. The ability within the team to motivate each other was something that stood out from the interviews as a key argument as it was a reliable source of motivation.

An interviewee described their relation to motivation with Mob Programming as:

“I feel that the motivation gets better because, if you need a 10 min break or something, you can do it and there are still other members who continue to work. So, there is always someone who is motivated and who

(27)

motivates others. Therefore, it is easier to be motivated when you need to help others than when you sit at the computer by yourself. So, I think it helps a lot that way.”

One interviewee referred to the flexibility within the mob regarding the continuous work done by the team.

“It’s quite common that I need to go away and do other things, and then it is very easy to get into the task again when you are using Mob Programming. You also get a feeling that you are contributing even if you can’t be with the team all the time.”

4.2

Results - Observations

This section includes the result of the observations that was carried out at Fortnox.

The result is divided between the daily and occasional users of Mob Programming to present the information in a structured way.

4.2.1 Daily use of Mob Programming

One of the most prominent behaviours observed from the team using Mob programming on a daily basis was the use of the roles Driver and Navigator. There was a clear structure shown and a set of rules regarding these two roles that all of the team members obeyed by. To stimulate role switching, the team used a timer of 20 minutes. This showed that all of the members had the same opportunity working with the different roles. This ensured that the code was written by all members of the team.

Another prominent behaviour that was shown was the use of code-line feedback.

When Navigators told the Driver what to do, they often specifically referred to the exact line of code to help the Driver along the way. This demonstrated that the feedback became more direct and explicit.

4.2.2 Occasional use of Mob Programming

The behaviour identified that differentiated the most in a team using Mob Programming occasional from a team using it on a daily basis was the lack of structure and rules regarding the two roles, Driver and Navigator. This was shown in a scenario where the person with the keyboard both typed and thought for themselves which undermined the purpose of the Driver and Navigator roles. This resulted in one or two persons doing the majority of the work while the rest of the mob was forced to act more passive. In addition to this, we observed that no timer was used for role- switching.

Another identified differentiation between occasional and daily use of Mob Programming was the use of code-line feedback. The observations showed that this technique was not present in the team using Mob Programming occasionally which resulted in less direct and explicit feedback to the Driver.

(28)

5 Analysis

This chapter will feature the empirical material that has been collected in the qualitative study on an abstract level concerning the literature review. This chapter will also mention the differences between the teams using Mob Programming on a daily or occasional basis.

5.1

Learning

The result of the interviews revealed that knowledge sharing is impacted positively when using Mob Programming. Employees learn from other team members but can also transfer their knowledge to them. Balijepally et al. (2017) believe this is possible because of the way Mob Programming is structured. A development team consists of several different individuals with a certain type of skill set e.g. coding solutions, design patterns, shortcuts, etc. When working together as a mob, these skills are being shared between the members of the mob which has a positive impact on knowledge sharing.

This also made it possible for new team members to speed up their onboarding process. Since the knowledge transfer is accelerated, newly hired team members get a faster learning curve regarding the tools, work methods, and systems that the team is currently using. This means that new members can start being efficient and be more independent earlier in the onboarding process.

The interviewees positively recognized that problem solving with Mob Programming was increased and gained a more enhanced way of producing quality solutions. The

“one-piece flow” mentioned by Zuill and Meadows (2016) was recognized by the interviewees as it resulted in all members of the development team to focus on one issue. Therefore, able to combine their knowledge and experience to further progress with the issue and to produce extensive solutions. The combining of skills, ideas, and approaches mentioned by Balijepally et al. (2017) was also expressed by the interviewees to positively impact problem-solving, referring to knowledge sharing as a base for this enhanced procedure.

Zuill and Meadows (2016) mention that the impact of negative distractions is less prominent when using Mob Programming since “group memory” exists within a mob.

This means that every team member knows exactly what is being worked on and how it is being worked on. This makes it a lot easier to get back to the original task after an interruption or distraction. This was also recognized and expressed several times in the qualitative study by the different interviewees. Many interviewees believed that this “group memory” existed and helped them stay on track with the specific issue the team was working on.

5.2

Team dynamics

As mentioned earlier the collective competence gained is one of the clear and explicit benefits through working with Mob Programming. As the whole team works together, knowledge about what issues are being handled at the moment and how they are solving it spreads to all members of the team. As a result of that, the interviewees expressed the need for documentation minimized and helped the team be more time-

Faculty of Technology Department of Informatics

Mob Programming and its impact on the developer's well-being and individual performance

Abstract

Sammanfattning

Keywords

Acknowledgments

Table of contents

Appendices

1 Introduction

1.1 Purpose of the study

Research questions

Definition of research concepts

Limitations

2 Literature Review

The origin of Mob Programming

Potential Benefits of Mob Programming

Potential Risks of Mob Programming

Experiences from using Mob Programming

Conclusion

3 Research Method

Individualistic reasoning

Qualitative method

Research design - Qualitative questionnaire and interviews

Research design - Observations

Thematic analysis

Validity and reliability

Ethics

4 Results

4.1 Results - Qualitative interviews

Results - Observations

5 Analysis

Learning

Team dynamics