1 Introduction

In technology companies worldwide, the need for new hires is so high that it threatens to limit the growth of many industries, one of which is the software industry [4, 11]. The shortage of employees is partly due to lacking education and training and the ongoing technology boom due to the Covid-19 pandemic and the need is not only for employees in general, but for especially highly skilled and specialized workers [4, 11, 15, 24].

To be able to acquire employees with a specialized skill set, a company must either hire such an employee, train one from its own pool of employees, or train a new employee using a trainee program. The limited number of employees in the industry makes recruitment difficult, costly, and even risky. According to a recruitment company SmartRecruiters [18], an efficient recruitment process requires 15 steps, which does not even include the onboarding steps of the newly hired employee. Onboarding of newcomers most commonly relies on a process, in which the newcomer learns the ropes of his or her new assignment [1, 20]. This adds the expenses of the recruitment process [6, 16, 21]. However, not all companies see the importance of onboarding and consider it as a “necessary evil”, to which not all teams or employees want to contribute [16].

As a case organization for this study, we chose a software company that constantly recruits new software engineers, and has recently recognized the challenge of not being able to provide a consistent onboarding experience for all new employees. Organizational changes have led to gaps in the process, where ownership and responsibilities of onboarding newcomers are unclear. The major changes include a change in management, the sudden shift to remote work induced by the Covid-19 pandemic, and the focus on implementing agile practices in all functions. Only limited research exist on how the agile ways of working could be efficiently combined with onboarding processes and practices [10]. In this paper, we study the challenges and successes of onboarding in an agile case organization and add to the body of knowled of agile onboarding.

2 Background

2.1 Onboarding

According to Bauer “Onboarding is the process of helping new hires adjust to social and performance aspects of their new jobs quickly and smoothly” [1]. A lot of research on the subject uses the term “Organizational socialization” [2, 8, 20]. In more recent research, organizational socialization is more commonly referred to as onboarding [1, 7, 17].

Generally, onboarding has been studied extensively. Whenever a person starts in a position, whether it is in a new company or a new position within the same company, there is always a period of socialization [20]. A person going through that period will be in an anxiety-producing situation and to reduce their anxiety, the newcomers will focus on learning the requirements of their new role as quickly as possible [19]. The more formal the process is, the more stress there is for the newcomer [19].

Employees, regardless of the field of industry, do change jobs and that includes challenges for both the individuals and companies [6]. Good onboarding – or organizational socialization – will have a higher chance to keep the new employees in the organization for longer than people who experience ineffective onboarding [2].

2.2 Theoretical Background

Van Maanen and Schein’s Model: As Van Maanen and Schein stated, there was no formal model to study or understand onboarding prior their work [20]. Van Maanen introduced seven dimensions which describe the major strategies used to onboard people to the organization [19]. Van Maanen and Schein further developed this theory and defined six major tactics [20]: 1) Collective vs. individual onboarding processes, 2) Formal vs. informal onboarding processes, 3) Sequential vs. random steps in the socialization processes, 4) Fixed vs. variable socialization processes, 5) Serial vs. disjunctive socialization processes, and 6) Investiture vs. divestiture socialization processes.

Jones Classification: Jones [12] presented the dimensions initially presented by Van Maanen and Schein [20] in a table with classification. Jones emphasized that the tactics used by organizations have an impact on the newcomer orientation and need to be understood better. Jones studied the actual response the different tactics may have on individuals, which provides an initial empirical standpoint on the different tactics used by the companies. The classification helps to explain Van Maanen and Schein’s [20] dimensions as tactics that are either institutionalized or individualized. The main findings from the study by Jones, confirm their hypotheses that self-efficacy will be more influential than whether the tactics done by employers are institutionalized or individualized [12].

Bauer’s Onboarding Metrics : Bauer [1] presents a model of onboarding functions and practices along with success measures. On an individual level, the building blocks for successful onboarding are four C’s: Compliance, Clarification, Culture and Connection. As Bauer explains, most firms can be put on a scale of three levels, using the four C’s: Passive onboarding, high potential onboarding and proactive onboarding. These can be used to define the current level of onboarding within a company.

2.3 Previous Research on Onboarding Within Software Development Companies

Even though onboarding in general has been studied extensively, we found only five papers on onboarding in software companies, two of them concentrating on agile [7, 10].

Britto et al. studied the effects of having multiple software development teams scattered in different locations and contextualised their findings in a later study [5, 6]. They found clear aspects that made the onboarding successful for new employees [5]: providing clear expectations for the new employee, providing extensive coaching and support on learning the project, and using tools to gather and give feedback. In their later study they found the challenges that had a negative influence on the new employee adjustment: distance to mentors, too formal onboarding process, too large tasks during onboarding and team instability [6].

Gregory et al. studied recently a team working in an agile setting [10] and used the onboarding model by Bauer to expand on [1]. The model created by Gregory et al. outlines two distinct aspects that no prior paper has considered. The first are the workplace adjustments, which are introduced as a new category in the model. The second is the realization of agile practices helping newcomers adjust to the company. The workplace adjustments are done by the company to enable better support for the newcomer [10]. These are team composition, team communication and the communities of practice.

Team composition refers to the adjustments the team has to consider when onboarding new employees. As agile software development focuses on the team-based decision making and quick reactions to changes, higher team cohesion and motivation leads to a more efficient team [23]. Introducing a new team member means that the team must re-adjust to accommodate a newcomer [10]. Gregory et al. explained that continuous personnel changes within the team limited the team’s ability to form into a cohesive agile team, which in turn did not allow time for anyone to start mentoring. When the team was able to form into a balanced team, the newcomers could be better accommodated to become a part of the team, with the help of a mentor.

Team Communication: Agile teams that have been working together for a longer time, may have developed a style of communication which is difficult to understand by the new employees [10]. Accommodating newcomers requires the more experienced team members to consider newcomers’ level of understanding of the domain and terminology.

Communities of Practice: Any agile team is also a part of an organization. The organization can have similar teams or areas of expertise that give the team – and most importantly the newcomer – the feeling that they can share their knowledge and gain understanding from their organization, not only from the team [10]. This shared expertise in the organization is known as “communities of practice” [22].

In another study done in agile settings Buchan et al. [7] provided best practices to focus on while onboarding: socialization opportunities, access to high quality knowledge artefacts, access to formal training, proactive feedback and knowledge sharing and providing psychological safety to experiment and learn.

Most recently, Rodeghero et al. [16] studied the remote onboarding of software developers during the pandemic at Microsoft. They found that social interactions within the teams were lacking in depth. Most employees felt connected to their team, but some employees felt the team activities lacking. The best practices the study discovered were team activities, such as game nights, hackathons and recurring meetings to just chat and catch up. The challenges found included not seeing other people’s faces, as cameras were commonly turned off, and asking for help and connecting with the team were considered difficult [16]. The authors provided a list of adjustments to be done by the company to help with onboarding new employees more efficiently: 1) promote communication and asking for help, 2) encourage teams to turn cameras on, 3) schedule 1 to 1 meetings, 4) provide information about the organization, 5) emphasize team building, 5) assign an onboarding buddy, 6) assign an onboarding technical mentor, 7) support multiple onboarding speeds, 8) assign a simple first task, 9) provide up-to-date documentation.

2.4 How to be Efficient When Onboarding People in an Agile Setting?

When looking at research done with agile teams, it seems that mentoring and peer support are common and suggested techniques for onboarding new employees to agile teams [7, 10] Along with mentoring, agile practices and ways-of-working also function as onboarding practices, for example sprint retrospectives [10]. According to Cockburn [9] agile companies tend to lean towards a leadership strategy that assigns goals and communicates constraints, rather than controls how work is done within the team. Agile teams are self-organizing and have a lot autonomy, thus no model, process or tool can be imposed to an agile team from higher up. In a modern, agile environment, teams take into use tools, techniques, and methods they find useful. For effective process improvemet, agile teams must want to use that process, method or tool.

Using the Van Maanen and Schein’s [20] dimensions, the agile practices could be summarised requiring the following dimensions: individual, informal, sequential, fixed, serial and investiture. When comparing these to Jones’ classification, it seems that the most efficient way to teach the job context would be using individualised tactics [12]. This is due to the teams having the freedom to choose their own processes within certain frames and thus also find the best ways for them to onboard new employees [3, 10].

The content of the job on the other hand should be clear for all employees from the start. According to previous studies, there might be challenges when it comes to handling expectations and learning [10, 16]. Also, Jones stated that random and variable tactics bring unnecessary uncertainty for the new employee [12].

Finally, socialization seems to be important. Not having connection to the members of your own team, makes asking help more difficult [16]. Not being able to onboard into an organization socially may be a big factor when the new employee is making the decision to either staying in the company or leaving [2].

3 Research Method

3.1 Research Objectives

This paper aims to find out the challenges and solutions for onboarding new employees in an agile software product organization. The findings can help other companies with similar challenges as our case organization was experiencing to overcome issues and as Bauer mentioned [1], increase the employee retention, employee well-being and effectiveness in the company. In this paper we aim to answer the following research questions:

  • RQ1: What are the experienced challenges when onboarding new employees into an agile team?

  • RQ2: Which practices support onboarding new employees into an agile team?

  • RQ3: How to improve the onboarding process for agile teams within a company?

To answer the research questions above, we collected data by a survey (39 responses), interviews (18 interviewees) and workshops (10 participants). Next, each of these are described in detail. Before that we briefly describe the case organization.

3.2 Case Organization and Their Research Premise

The company under study operates in the software engineering industry. It employs over 350 people and has a revenue of over 80 million euros. The 350 people within the company work with their own assigned products, which are managed individually. Out of these individually managed product development teams, a product development unit of 82 people underwent an organizational transformation towards a team-based organizational structure. In 2020 the global pandemic moved people to work from home and many of them did not return fully to the office after the pandemic, but continued in hybrid mode. The data collection of this study took place in 2022, after the company had moved to hybrid work mode. Agile methods, such as Scrum, are widely used within the company, by different teams. Each team works mainly independently, specializing in its specific area of the product. The teams are self-sustaining and self-directing, and may choose their own practices and processes within certain frames. This applies for onboarding as well. The company continuously hires new people to support the growth of its products.

After the transformation new roles were introduced and responsibilities were re-arranged to reduce person dependence. The onboarding responsibilities of supervisors and directors were reduced, and new lower-level roles were introduced. Many of the roles are considered as “hats”, which are additional responsibilities on top of an assigned role. For example, a person can be both a developer and a Scrum Master, or a Product Owner and a people coach. The new roles central to onboarding are the following:

People Coach: A person responsible for long-term career coaching, probationary period follow-up, goal setting and well-being of a predetermined number of employees within the R &D. The employees may choose the most suitable people coach for themselves. The objective is to provide a peer for each employee that ensures that the employee has the conditions to succeed in his or her work assignments. A people coach usually comes from a different team. This allows for the employee to receive ideas from outside the own team, and to talk about the situation in the own team more openly.

Mentor: A team colleague from the own team that is responsible for providing a basic understanding of the team processes and practices, along with the onboarding in the team, including the specifics of the development or design environment. Mentors have usually dedicated time to answer questions the new employee might have.

At the time of the study, employees were onboarded to their assignments with the use of a team mentor and a people coach, along with general company level onboarding. The onboarding has been a challenge for many years, as tools and technologies kept changing and no sufficient documentation was always available. According to the statistics the company has collected, onboarding does have a positive impact, even though it is sometimes criticized of being insufficient. This may be due to the development teams not having a culture to share their practices and common materials. The process of onboarding has become somewhat blurry for both the company and the new employees. Due to these challenges, research was welcomed to advance the process around onboarding to support the people coaches, mentors and new employees to adjust to the company better and with better consistency.

3.3 Scope and Perspective of the Study

To limit the scope of this study, we chose to concentrate on the one product organization with approximately 80 people, with the most changes in ways of working. The data was collected by the first author of this paper, who at the beginning of this study had worked as a developer in the company for two years in the R &D of the product under study. While starting the study, the author was transferred from the development team to concentrate on improving the onboarding process and to additionally work as a people coach for summer trainees. To avoid close involvement into the onboarding process of the summer trainees, the summer trainees in question were excluded from this study. Even though the close involvement of the first author can be seen as a limitation, the people coach role provided also good insight into the onboarding process. The two other authors participated in designing and monitoring the study steps, ensuring the the objectivity. They provided an outside view, as well as contributed to the writing of this paper.

3.4 Data Collection

Survey Data Collection: The initial status of the current situation of the onboarding processes was collected with a survey. The survey questions were formed by drawing inspiration from previous studies [1, 14]. As onboarding consists of multiple stages as presented by Bauer [1], the survey needed to be tailored to gather a wide perspective on the onboarding in the case company. QuestionsFootnote 1 asked about general onboarding experience, the support received, the knowledge of the company, and the preferred ways to receive information while onboarding. The survey consisted of two questions about the respondent’s backgrounds, 13 agree-disagree questions on a likert scale [13] about the onboarding, and five open-ended questions in which the respondents were asked to describe the challenges and good practices of their onboarding experience. Respondents could also indicate if they would be willing to participate in the interviews on the topic.

The questions were reviewed by employees in the case company and all authors of this paper and improved based on the feedback. Two employees tested the survey and it was estimated that responding would take 10–15 min.

Link to the survey was sent to a common mailing list of the product’s R &D. The 82 recipients consisted of developers, designers, quality assurance specialists, Product Owners, and lead experts. We received 39 completed responses (response rate: 47,6%).

Interview Data Collection: Semi-structured interviews were selected to collect more detailed description of the employees’ onboarding experience, the same way as in the previous onboarding studies [10, 14]. The interview questions were formed by analysing the previous literature on the topic (e.g. [14]) and modified to better reflect large-scale agile set-up in the case company. Moreover, the preliminary findings from the surveys were used to ask more specific questions. The interview questions can be found at.Footnote 2

To get an extensive picture of all different onboarding processes, tools, or techniques in use across different teams, we found it important to have interviewees from all 13 teams. Initially, ten people indicated in the survey study of their willingness to be interviewed. They represented six teams. The organization chart and previous knowledge on employees’ roles was used to find people that represented groups and roles that were not yet represented in the interviews. The purpose was to have a selection of employees that represented a wide range of roles and groups.

In total 18 people from 12 teams were interviewed. 14 interviews were conducted using the questions aimed specifically to ask about the interviewee’s own onboarding experience, while in four interviews the main purpose was to gather information of the recent mentoring experiences from more experienced employees working as mentors. This separation was made to make it easier to focus on the interviewee’s own point of view, in cases where the employee did not recall their own onboarding experience. Interviewees, their roles, teams and time from own onboarding are listed in Table 1.

Table 1. Interviewees
Full size table

Interviews were confidential, and it was made sure that in the results the respondents cannot be traced back to any team or a specific employee to ensure privacy.

Workshops: All 18 interviewees were invited to participate in an online workshop. Finally, a total of 10 people participated in the workshop which was divided into two parts due to time constraints. Out of the total 10 participants, 9 participated in the first part of the workshop, and covered a total of 7 teams. These 9 people were divided into three break-out rooms to collect ideas and create solutions to the challenges identified in the interviews. When organising the second workshop, all the initial 18 interviewees were invited, out of which 6 participated in the second workshop, and covered a total of 5 teams. The focus was to create concrete action points based on results from the survey, the previous workshop and the interviews.

Due to having workshop participants from multiple offices, an online whiteboard tool Miro was used as a working space for the workshop. Each group, based on the division in break-out rooms, had their own working space, in which the participants could create new sticky notes for their ideas, and use the sticky notes to brainstorm and prioritise their ideas. This helped the analysis, as all the workshop work was visible and written out in the online tool. The workshop participants were told to create solutions for the challenges they chose from the pool of challenges found previously in the study, as well as create concrete action points on how to approach solving the problems.

Data Analysis: In this paper, we concentrate on the data collected with the open-ended questions of the survey, interview data, and workshop results. Both survey and interview data were analysed using an Excel sheet where individual, good practices, challenges, development ideas, and other common thoughts were collected. A matrix was formed from the respondents and the key factors, from which it was easy to count the number of mentions that each key factor had. Thus, the most commonly mentioned challenges, good practices, and ideas could be easily identified. The end result of the workshops was ready-made solution suggestions.

4 Results

4.1 RQ1: What Are the Experienced Challenges When Onboarding New Employees into an Agile team?

The case organisation had been experiencing challenges regarding onboarding and therefore saw a need for this study. The challenges recognized in this study are listed in Table 2. The table shows how many employees brought up a certain issue in the open-ended survey answers and during the interviews. The order in the table is based on how many mentioned each challenge during the interviews. As many survey respondents volunteered for the interviews, there is some overlap between the survey and interview respondents.

Table 2. Challenges identified from surveys and interviews
Full size table

There is a clear difference between the challenges brought up in the survey compared to the interviews. The survey answers emphazise the low quality and lack of onboarding materials and documentation, whereas interview brought up topics such as lack of transparency of onboarding practices and not collecting feedback on the onboarding experience.

A challenge with the highest number of mentions was surprisingly the lack of transparency of the onboarding practices (C-1). In the interviews, most interviewees mentioned having a dispersed process, which had some overlapping and missing items. The interviewed mentors mentioned that they had little or no understanding on the onboarding process as a whole and had to purely focus on the mentoring and onboarding of the team. Lack of transparency was also a problem when looking at the onboarding process between different teams, as the onboarding process was quite different for different teams (C-11). This lack of transparency was only visible in the interviews, as when people described their process and experiences it became clear that they had no knowledge of other teams or mutual practices.

No onboarding feedback was gathered (C-2) was the second most mentioned challenge. In the interviews, it became clear with almost all employees that no feedback was asked about their onboarding process. This makes the process development difficult, as there is no way of knowing what aspects to keep the same and what to improve. The different events organised jointly for different products within the company did have feedback models in place, but mentoring or team onboarding did not have any kind of feedback process. In the interviews, three people mentioned that the onboarding survey conducted during this study was the first time they had been asked for feedback regarding onboarding.

Missing materials or documentation (C-3) was an issue that came up both in the survey and in the interviews. Interviewed persons emphasized that missing materials and documentation was a huge issue and caused major delays in their onboarding. Additionally, documents were mentioned to be outdated (C-6) and people had to look for information from many places without having a clear picture of what to look for (C-8). In addition, two interviewees brought up that they found materials, but did not have access to those materials, and had to ask for them specifically (C-12). Also, one survey respondent mentioned not getting started for a few days, because he or she did not have access rights. A few interviewees mentioned that they did not lack materials, but they lacked a structure for the onboarding materials.

When it comes to the organization structure and internal language, there were mentions about the organization structure being unclear (C-4), not knowing other team’s responsibilities (C-11), or not knowing the right people to ask for help when it comes to a more specific area (C-13). Moreover, some employees mentioned not initially understanding the domain and business-specific language (C-7). The interviewees mentioned these as smaller issues. However, five interviewees reporting of not understanding the organization structure would indicate that general organization and company-wide aspects have not been communicated well enough during the onboarding process.

One of the most worrying findings were the mentions of not feeling included in the team (C9). This had as many reasons as there were mentions and were mostly individual in nature. The underlying cause appeared to be the way teams to give specific responsibilities to their new team members. Most of these responsibilities were something no one had an ownership before, causing the new employee to fall into a role, where no one could instruct him or her on what to do or even on where to start (C-13). When being a part of the team, but still only completing certain assignments that were not related to the assignments of the team, caused that some employees were not properly included in the team’s work. This is an indication of a wider problem, the lack ownership of responsibilities, also apparent in responsibilities related to onboarding itself (C-5).

4.2 RQ2: Which Practices Support Onboarding New Employees into an Agile Team?

The currently employed practices that are mentioned as successful in supporting onboarding in the case company can be found from Table 3 which is constructed based on the interview answers.

Table 3. Good onboarding practices identified
Full size table

The most mentioned practice both in the interviews and in the open questions of the survey was mentoring (P-1). Mentoring was described as one of the most important parts of onboarding, due to its focus on the individual and their skills. Mentors were always working in the same agile team. In a few responses the term “mentor” was not used, but the description was clearly the description of a mentor. The most important in mentoring was the availability of someone always ready to answer your questions. In addition, many people who had started prior to the pandemic mentioned that asking questions in the office from anyone was important and especially that the team as a whole was open to questions from the new employee (P-5). The pandemic stripped away the possibility of being at the office, so other ways to lower the threshold to ask questions were needed. In the beginning, it was harder for teams to find habits to help newcomers get help more easily, but the more recently onboarded interviewees mentioned different ways to encourage asking questions, arrange activities and facilitate situations for new employees to participate into conversations, which encourages to an open and transparent working culture (P-3). These include in different teams: 1) staying in the virtual daily meeting room after the daily activities with cameras open until lunch, 2) hanging out in a virtual meeting room with microphones open every day for at least a few hours (P-13), 3) having a weekly reservation on working with cameras open, 4) having a weekly time for just hanging out and talking about non-work-related stuff to build the team, 5) team gatherings and re-building the team working habits with the new employee, and 6) pair/mob/team programming (P-6).

The second most mentioned practice was people coaching (P-2). Due to the people coaching being a relatively new organizational model, only a few interviewees had a people coach from the start. The similar tasks as the people coaches were doing, were mentioned as being done by the previous supervisor more than two years ago (P-12). The supervisor welcomed new people to the office and showed them around. The interviewees onboarded less than two years ago on the other hand thought of the walk-through of the contract and strategy, when talking about supervisor onboarding.

Another good practice that was in use with many teams was onboarding day or days at the office (P-4). This is mainly something that was taken into use after the pandemic had started because previously people started their work at the office quite regularly. During the pandemic, the first day included presentations and setting up the environment for the work assignment. Unfortunately, not too many people were introduced with multiple days at the office as the regulations prevented working there most of the time. However, this was seen as important, due to getting to meet other people at the office and getting to know your teammates better. Onboarding days were also difficult for teams that had their members spread out to multiple offices.

Another thought that was mentioned multiple times in the interviews, was the hands-on work assignments given to new employees, especially getting to do work assignments from the first days on (P-8). Employees stated that they got familiar with the code by getting to complete challenging and varying tasks from the start (P-14). Their first assignments were one by one more challenging to solve, which was seen as motivating. Even the first assignments were actual backlog items from the team’s backlog. A common thought here seems to be that the planning was done in advance. Along with planning the assignments in advance, reserving time for the newcomer to get to know the code without rushing was also thought as important, because it reduced the anxiety of meeting the performance expectations of a full-time employee right away (P-9).

4.3 RQ3: How to Improve the Onboarding Process for Agile Teams Within A company?

The third research question asks for solutions for improving the onboarding process in an agile organization. To find the best solutions, feedback, and solutions were collected first from the interviews. Additionally, a two-phase workshop was organized to facilitate ways for employees to solve the most important challenges by themselves.

Ideas Collected. Unlike previous categories, new ideas were something interviewees did not have much in common. We received a lot of new ideas, ranging from team-level onboarding ideas to product-level ideas. See Table 4 presenting the most often mentioned ideas. The idea, which many interviewees seemed to agree on, was a clear presentation of the organization structure (I-1). It would help all employees to better understand the different parts of the organization and their responsibilities.

Ideas that came up as successful and were already used in some teams were: Pair/mob programming and completing assignments as one team (I-2), which allows for information sharing during the regular programming, arranging a team gathering as soon as possible when a newcomer starts (I-3), planning ahead when a newcomer is arriving for example regarding joint office days and tasks for the newcomer (I-4), and that the team will gather their tools, access rights and documents into a single location for the newcomer and keeps those up-to-date (I-6). These ideas could be spread and taken into use also in other teams.

At the time of the study the onboarding responsibility was unclear and scattered between different people: people coach, mentor, team and the rest of the organization. As team is central for the onboarding success, many onboarding practices depend on the team and might be team-specific due to the self-organizing nature of an agile team, it was suggested that in the future the team would take the main responsibility of onboarding (I-5).

Finally, as teams have many things in common, it was suggested to create common software architectural solutions accross teams (I-7) and common presentations explaining higher level architecture and ways of working in the organisation (I-8). These would give more insight into the product and the organization, and make it easier for employees to understand the architecture and business decisions behind the product.

Table 4. Ideas collected
Full size table

Solutions Created in the Workshops: The workshop participants selected the following five challenges as the most important to solve in the onboarding process and offered a number of solutions for each challenge, as shown below:

Mentor Lacks Instructions: Each team should create their own checklist for their own onboarding process, so that the most essential technical details will always be reviewed. The checklist could contain: UI features, project structures, microservices, repositories and the most important data structures. The checklist requires checking and updating every time a new employee is starting.

Materials or Documentation Outdated: To avoid this from happening in the future, links should always be updated when documentation is updated. Having all documentation in one platform would support this.

Materials or Documentation Missing: All materials need to be found from a single location. Outdated material needs to be removed if found. A common repository for technical documentation already exists, but is not utilized. A wider adoption for this tool is needed. This would centralize the technical documentation.

Lack of Knowledge in Some Specific Domain Areas: The issue that the new employee does not know anyone with knowledge about a specific area, causes a lot of questions and time to find a person to answer a question. To solve this, an introduction of the people, and their skills and responsibilities also outside the own team would be needed.

Feeling of Not Beloning to the Team: More care should be taken to onboard the new employee to the team as well. This includes for example some activities with the team, preferably face-to-face. Some off-topic talks within the team can also help with team building. Team members should focus on including the more quiet people in discussions.

As can be seen from the list above, the solutions suggested by the workshop participants are quite low level and should be easy to implement.

The workshop participants were asked to form action points to help the organization to take suggestions into practice. Two major action poins were created: 1) Create a group to discuss onboarding best practices and challenges from different teams. This would allow for knowledge and experience sharing between the teams about onboarding. This way the practices used in different teams could be made more common and generally more would be known about the onboarding within the organization. 2) Create a common checklist for onboarding and place for onboarding documentation. The checklist could include also technical details that would be essential to know for a new employee. That way the mentor would have a clear place for all the materials, and the team could use the documentation for their own ways of working. It was also heavily suggested that this sort of a documentation would be in the version control, next to the code made by the teams.

5 Discussion and Conclusions

In this paper, we reported a case study on onboarding in a medium-size agile software development company, which had undergone changes and expressed the need to improve its onboarding practices. With a survey, interviews, and workshops we collected data on the current onboarding challenges, successful practices, and improvement ideas from the software development organization.

Even though there exists plenty of literature on onboarding in general, including onboarding theories [1, 12, 20], onboarding in agile software development has not received much attention yet. According to Gregory et al. [10], more research is needed to cover different kinds of agile companies, including remotely working and larger software companies, both of which were covered in this research. Next, we will discuss our results, especially from the point of view of agile software development.

Based on our results we present the following practical implications for onboarding in agile software development organizations:

  1. 1)

    Mentoring is the key. In our results, mentoring was the most often mentioned successful onboarding practice. A peer from the same team where the new employee would start was assigned as a mentor for him or her. When comparing to the literature, it seems clear that mentoring is widely used as a good onboarding strategy, even across different industries. In several software companies, mentoring was reported to be one of the most popular or the prime onboarding method, [5, 7, 10, 16].

  2. 2)

    Give Agile teams the main onboarding responsibility and make the responsibility clear. According to our results, the agile teams had already a lot of responsibility in onboarding the new team members. However, that responsibility was not clearly stated. In agile software development the teams are self-organized, and according to agile leadership strategy teams are just assigned goals and given constraints, rather than controlled by how the work is done within the team [9]. Therefore, it seems quite natural that teams have a lot of autonomy also in the onboarding process when including new members in an agile team.

  3. 3)

    Give agile teams the autonomy to decide the onboarding practices for them. Many of the successful practices found in our study, as well as improvement ideas were team-level practices, which implies how important the team-level practices are for successful onboarding. As agile teams have the autonomy to decide their internal practices, teams should be given the freedom to decide the best onboarding practices for them. Some of the successful and suggested practices in our study were actually typical agile practices, such as mob/peer programming. Previous literature has also reported that agile practices and ways of working also function as onboarding practices, for example, sprint retrospectives [10] and code reviews [5, 10].

  4. 4)

    Support and encourage the teams to share good practices. Our results revealed that different agile teams had already a good selection of successful onboarding practices at the team level. However, the teams were not aware of the different practices used by different teams. Sharing these practices and learning from other teams was one of the actions suggested by the workshop participants. Previous research supports this finding, e.g., Gregory et al. [10] suggest communities of practice to share expertise in the organization in the form of “communities of practice” [22].

  5. 5)

    Create a common place for onboarding documentation and checklists. Keep them up to date. The lacking, missing, and not up-to-date materials for onboarding, such as plans and orientation materials, were brought up as a challenge in our study, and a lot of ideas were given on how to improve the situation. Also, previous research in software companies has reported similar problems [5, 10, 14]. These studies have suggested that better documentation would fill in many of the challenges faced by the new employees.

We call for more research on onboarding practices used in different agile development companies. In addition, it would be interesting to follow up on the influences of the improvements suggested by our study participants, and how these improvements might influence the employee engagement statistics and turnover rate in a longer period. Additionally, information and reports from implemented methods by each team would provide excellent insight into the effect the solutions have on the team’s daily work.