No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
Studying Onboarding in Distributed Software Teams: A Case Study and Guidelines
Abstract
Many companies have turned towards globally distributed software development in their quest for access to more development capacity. This paper investigates how a company onboarded distributed teams in a global project, and report experience on how to study such distributed projects. Onboarding is the process of helping new team members adapt to the existing team and ways of working. The goal of the studied onboarding program was to integrate Por-tuguese developers into two existing Norwegian teams. Further, due to the growing trend in utilizing globally distributed projects, and the challenge of conducting studies in distributed organizations, it is crucial to find good practices for researching such projects. We collected qualitative data from interviews, observations, Slack conversations and documents, and quantitative data on Slack activity. We report experiences on different onboarding practices and techniques, and we suggest guidelines to help other researchers conduct qualitative studies in globally distributed projects. CCS CONCEPTS • General and reference → Empirical studies; • Software and its engineering → Software creation and management.
... When onboading an individual to replace a team member who retires, takes up a new role within the company or leaves the company, training is often performed by the person who is to be replaced, or by immediate teammates. Onboarding in general is a well-researched field with studies of diverse type of professions [4,[7][8][9][10], and some empirical studies about onboarding newcomers in software companies [5,[11][12][13] as well as recent interest in the context of agile software development [14]. ...
... Companies shall have a good understanding of the complexity of the assignment and critically assess their own capabilities in terms of organizational maturity and size as well as existing in-house competences. A good onboarding plan for large campaigns includes a phase-based approach as suggested by related research [4,5,12] and a multiple-batch breakdown, a novel contribution of our study (see Fig. 2). Our findings shed light on the challenges and potential strategies for organizing multiple-batch onboarding, which resonate with the findings from an unprecedent, transformational growth (although not as rapid as in our cases) reported by Kumar and Wallace [27]. ...
... The helpful strategies included running self-study parts in parallel with on-the-job training (e.g., integration in the teams), which is consonant with existing research that emphasizes the importance of early productive work and exposure to work-related practices and ceremonies [5,14]. Our findings contribute to existing research suggesting that mentoring and support can be organized through a "buddy team" or a "sister team" [6,12,14]. Prior research shows that such approach reduces the problems of mentors being unavailable for newcomers [14], and helps new teams to grow their social network, which is essential in large-scale agile [31]. And yet, our study clearly shows that following a plan will not take you far when changes arrive. ...
Onboarding is a process of organizational socialization of the new hires, that includes recruitment, orientation, training, coaching and support. While onboarding individuals into an organization is a rather straightforward task, little is known about 1) onboarding hundreds of developers and 2) doing it on a distance in outsourcing situations. Furthermore, the subject of sustainable growth with respect to organizational capabilities and culture is often overlooked. This paper reports findings from an exploratory multi-case study of two large onboarding campaigns. We collected empirical data from interviews, retrospectives, onboarding documentation and onsite visits. Based on the empirical study, onboarding hundreds of software engineers in a complex agile product development environment which lacks documentation and puts high demands on engineers’ knowledge and skills is a challenging and costly endeavor. To save the costs and for practical reasons, large-scale onboarding is organized in batches with the first batch trained onsite, and the later batches trained internally. We report challenges faced in the two cases and discuss possible solutions. One core finding is that a good plan combined with the organizational agility, i.e., the responsiveness to change, together with organizational maturity determined the success of organizational scaling. The presented cases contribute to the scarce research on knowledge transfer and onboarding in a large-scale agile context.
... Interpersonal B. Cultural differences, Offshore socialization, Geographical dispersion [10] Geographical dispersion [9] Communication issues [28] Communication between teams with different aims (i.e. AE vs DE) ...
... Remote mentoring, Feedback and review [10] Socialization emphasis [9] Remote mentoring, Feedback and review, Onshore mentoring [28] Mentoring Ceremonies, Process documentation, Physical task board, Guided task allocation, Feedback and review [20] Daily, Explicit mentoring responsibilities [11] Feature-centric documentation [5] Feature-driven semi-automatic mentoring Global Software Development (GSD). The Internet allows for software professionals to team up no matter the time and the place. ...
... difficulties to integrate into the team due to its distributed nature), geographical dispersion and communication issues (i.e. problems to communicate between teams with different time zones or difficulties to conduct remote mentoring), overcoming cultural differences and strategy fragmentation (i.e., maintaining the same onboarding process in the whole organization) [9,10,28]. Remote mentoring, onshore workshops (i.e. gathering together different teams in the same place to work together, for example, through pair programming) or frequent feedback are some strategies taken by GSD companies to mitigate these barriers [9,10,28]. ...
Onboarding (i.e., the process of incorporating new people) is relevant because it introduces employees to their role, the company’s culture, and what the company has to offer. Onboarding is then dependent on the company’s culture and practices. When it comes to software development, these practices include the methods, the tools or the developers’ organigram. Accordingly, there is not a one-size-fits-all onboarding, rather this procedure needs to be tuned for the practice at hand. This work tackles the specifics brought about by Software Product Line Engineering w.r.t. traditional software development, namely: larger code base, larger code variability, and larger and more heterogeneous teams. Specifically, this works advocates for feature-centric onboarding. Features (i.e., functional characteristics that are visible for a user) already play a key role throughout the SPL lifecycle. In this context, we advocate for defining the onboarding process as a journey where milestones are equated with features. Unfortunately, finding the most appropriate feature for a newcomer, if conducted manually by mentors, would be time-consuming, given the sheer number of features. To face this problem, we advocate for Recommender Systems based on the similarity between the feature’s codebase and the code previously explored by the newcomer. To this end, we resort to Topic Modeling, and specifically, Latent Dirichlet Allocation. We provide proof-of-concept through RecomMentor, a recommender system for pure-variants as the variability management system. RecomMentor is put to test against ranking metrics of the Information Retrieval literature. The first evaluation suggests that LDA could be an appropriate technique, paving the way towards using Recommender Systems in feature-based onboarding scenarios.
... Within this context, onboarding employees who work virtually has been recognized as a challenging task (Britto et al., 2018;Moe et al., 2020). Challenges that may be faced when onboarding in the virtual work context are often linked to the limited F2F contact which may reduce familiarity with other employees and the wider organization, thus limiting opportunities for newcomers to build strong social connections with their teams (Rodeghero et al., 2021). ...
... Challenges that may be faced when onboarding in the virtual work context are often linked to the limited F2F contact which may reduce familiarity with other employees and the wider organization, thus limiting opportunities for newcomers to build strong social connections with their teams (Rodeghero et al., 2021). Moe et al. (2020) studied the onboarding process in distributed software GVTs involving incoming Portuguese members and existing Norwegian members, and found that the following challenges influenced the onboarding process: missing domain knowledge (about the coding) (76%), the use of communication tools (47%), unclear tasks (41%) and language barriers (35%). Other authors have found similar results related to coordination challenges (Driskell et al., 2003), low levels of team trust and engagement and cultural challenges in terms of language, norms, and communication (Gibson et al., 2014). ...
We explore onboarding in the context of global virtual teams (GVTs) with our findings from a qualitative case study with a leading global organization in the financial services industry. Through interviews with GVT members and leaders, we contribute to the literature in three ways: (a) revealing that onboarding in GVTs with dynamic membership is an ongoing practice (instead of a one-off activity); (b) identifying two categories of practices (known onboarding practices from the traditional literature and GVT-specific practices); and (c) suggesting that onboarding in GVTs with dynamic membership is not the organization’s and the leader’s responsibility alone, but existing and incoming members have a role to play too. We discuss our theoretical and practical contributions, and close with our study’s limitations and future research directions.
... As Bablo et al. [5] notes, communication in agile teams is not just frequent but also informal and direct, enabling rapid responses to change and fostering a collaborative environment. For a long time, communication tools such as Slack have been vital in globally distributed teams, providing an asynchronous yet real-time communication medium supporting fast feedback [25]. ...
This paper examines the role of the enterprise social networking (ESN) tool Slack in the daily work of software practitioners within NAV, a large-scale agile public sector organization. Based on 13 interviews with NAV developers, our case study explores how Slack is employed for knowledge sharing and daily communication across the organization. We used a newly developed framework for communication in agile teams as a theoretical lens. Through our analysis, we found that Slack use had become deeply integrated into the organizational culture and fostered alignment in three main ways: Promoting communication transparency through open discussions visible for developers organization-wide, enhancing communication quality with prompt responses and constant communication, and encouraging communication discipline through structured channels and threads. This study also unveiled some challenges, such as information overload and hindered focus. However, our findings suggest that if common hurdles are overcome, modern ESN tools can reshape how cross-organizational communication plays out in large-scale agile, reinforcing the agile principles of collaboration and motivated individuals.
... A literatura atual apresenta diversos estudos no contexto de processo de onboarding de profissionais efetivos em empresas de software [4,6,13]. Entretanto, observa-se uma lacuna de pesquisa relacionada a estudos com foco específico no onboarding de novos estagiários na área de desenvolvimento de software. ...
The onboarding process is important for successfully integrating new workers into software development teams. Specifically for interns, this process can be even more relevant, as it is their first professional contact. Thus, it is relevant to investigate how onboarding occurs and how possible techniques are being applied to provide more adequate guidance for interns in the software industry. This paper aims to analyze the onboarding process for interns in the software development context. The initial study was conducted through an initial survey with 53 interns, observing the main elements and onboarding techniques used in their previous experiences. As an emerging result, mentoring, intern documentation, and social interaction were highlighted as the most promising techniques for successful onboarding, according to the participants. Furthermore, we identified that effective onboarding contributes to building a positive organizational culture and talent retention. Regarding the contributions, we cover the participants’ perceptions of techniques and challenges faced in intern onboarding in software development. Our future work involves surveying individuals responsible for supervising trainees or interns in the context of software development companies.
... As Bablo et al. [5] notes, communication in agile teams is not just frequent but also informal and direct, enabling rapid responses to change and fostering a collaborative environment. For a long time, communication tools such as Slack have been vital in globally distributed teams, providing an asynchronous yet real-time communication medium supporting fast feedback [25]. ...
This paper examines the role of the enterprise social networking (ESN) tool Slack in the daily work of software practitioners within NAV, a large-scale agile public sector organization. Based on 13 interviews with NAV developers, our case study explores how Slack is employed for knowledge sharing and daily communication across the organization. We used a newly developed framework for communication in agile teams as a theoretical lens. Through our analysis, we found that Slack use had become deeply integrated into the organizational culture and fostered alignment in three main ways: Promoting communication transparency through open discussions visible for developers organization-wide, enhancing communication quality with prompt responses and constant communication, and encouraging communication discipline through structured channels and threads. This study also unveiled some challenges, such as information overload and hindered focus. However, our findings suggest that if common hurdles are overcome, modern ESN tools can reshape how cross-organizational communication plays out in large-scale agile, reinforcing the agile principles of collaboration and motivated individuals.
... Each new hire has a different set of skills, experience levels, and distinct expectations from the job, and HR professionals need to align them all together to ensure employees' well-being and job satisfaction. Moe et al. [16] mentioned HR professionals in an organisation ensure the company. Precisely explaining, onboarding requires the collaboration of multiple departments, such as training faculties, IT departments, and the company's accountants, to inform all the vital aspects of including new employees in the company. ...
Onboarding is an important part of HR management to add value to the organisation. An effective onboarding programme assists employees in comprehending the fundamental nature of the organisation as well as the expectations that the company has for its employees. Providing employees with a sense of belonging during the onboarding process has the potential to increase their levels of job satisfaction. When it comes to the boarding process, the performance of human resources is directly related to the organization's ability to maintain harmony. It is essential for the retention and happiness of newly hired employees to maintain their engagement throughout the onboarding process. When it comes to training staff to perform paperwork and other key activities, it is essential to make use of technology. For the purpose of this investigation, the primary quantitative approach was utilised to compile all of the pertinent information pertaining to the subject matter. Three questions pertaining to demographics and ten questions based on topics have been helpful in the process of properly producing questionnaires. A total of fifty-five volunteers actively participated in the collection of the data, which was subsequently analysed using the SPSS software. Consequently, this has been of great assistance to the study in establishing hypotheses and providing appropriate responses to the research questions.
... Social capital is key for agile software development: it is a prerequisite for solving problems, making decisions, shifting workload, understanding common goals, and sharing knowledge among or across individuals and teams. Further, access to an informal network is essential when new employees are onboarded (Bauer, 2010;Jones, 1986;Moe et al., 2020). ...
Although the public health emergency related to the coronavirus disease 2019 (COVID-19) pandemic has officially ended, many software developers still work partly from home. Agile teams that coordinate their office time foster a sense of unity, collaboration, and cohesion among team members. In contrast, teams with limited co-presence may experience challenges in establishing psychological safety and developing a cohesive and inclusive team culture, potentially hindering effective communication, knowledge sharing, and trust building. Therefore, the effect of agile team members not being co-located daily must be investigated. We explore the co-presence patterns of 17 agile teams in a large agile telecommunications company whose employees work partly from home. Based on office access card data, we found significant variation in co-presence practices. Some teams exhibited a coordinated approach, ensuring team members are simultaneously present at the office. However, other teams demonstrated fragmented co- presence, with only small subgroups of members meeting in person and the remainder rarely interacting with their team members face-to-face. Thus, high average office presence in the team does not necessarily imply that team members meet often in person at the office. In contrast, non-coordinated teams may have both high average office presence and low frequency of in-person interactions among the members. Our results suggest that the promotion of mere office presence without coordinated co-presence is based on a false assumption that good average attendance levels guarantee frequent personal interactions. These findings carry important implications for research on long-term team dynamics and practice.
... Specific to the Agile context, there are some studies such as study [5] reporting results about cultural barriers impeding agile ways of working in distributed teams from an empirical study of a Swedish company working with offshore engineers from an outsourcing vendor in India. Such challenges are not limited to the countries of Western and Eastern cultures; Moe et al. [11] stated that during an onboarding process, the most important success factor is finding Portuguese developers that matched the culture of the existing Norwegian Agile teams. ...
The effect of national culture in the software development especially in Agile Software Development industry has a considerable place since national culture affects and shapes organizations and individuals. Our study examines the impact of Turkish national culture on Agile software transformations and developments in Turkey, as the first instance in/for Turkey scope, to the best of our knowledge. We conducted semi-structured interviews with fourteen experts in prominent nine companies from three major industries including TechFin, Aviation, and Telecommunication. In the study, motivations of organizations for transforming Agile, challenges with transitioning to Agile, Agile culture specific to Turkey and preferences on Agile frameworks in Turkey were investigated. The results were discussed along with their implications for Agile in Turkey by considering Hofstede’s model which is designed to investigate country-level cultural traits. Our results are largely parallel with the existing knowledge of Hofstede Insights specific to Turkish culture, yet we additionally present the impacts of this national culture of Turkey on the country’s Agile Software Development. Consequently, it was observed that the national cultural background has a considerable effect on the Turkish Agile software development domain. We have witnessed some similar effects in the Eastern culture as well. By providing the country’s cultural patterns through a localized lens, the study may contribute to those who may have a practical interest to Turkish in terms of which potential challenges they need to be prepared for once they move into the adoption of agile working in/with this country and more generally in/with the countries with which has similar cultures as in the Eastern civilizations. Our study also comes with global insights to the other countries in terms of understanding the use of agile methods and practices in companies located outside of the early adopters of agile methods.
... Britto et al (2017) reviewed onboard models in literature, and identified, in the context of geographically distributed development, that the most common strategy adopted is coaching and mentoring, although it is only semiformalized. Still in the context of Global Software Development (GSD), Moe et al (2020) observed that even if one organization applied the same practices and strategies for onboarding of all new employees, the results are affected by several factors such as the domain and complexity of the teams, the type of team, and availability of teammates. Sharma and Stol (2020), based on survey data, argued that a successful onboarding is associated to higher levels of job satisfaction and workplace relationship quality. ...
New hires usually should learn about the working process, organization structure, and company corporate culture and to be acquaintance with a very new environment. It requires company to organize throughout a well-planned onboarding process, but many companies are not aware of onboarding models and how to support onboard process to become more efficient. We aimed to characterize the main methods through an ad-hoc literature review. We provide practitioners and researchers with the rationale to identify onboarding models and characteristic of the main methods relate to onboarding Software Engineering.
Large-scale agile software development is increasingly being organized with product management. Although product management is familiar to software engineering, we need research-based knowledge about organizing product management in an agile development context. This study focuses on product management challenges and configurations in a Nordic fintech organization with 10,000 employees. We conducted 19 interviews with participants involved in core product management activities. The study identifies ten key factors that hinder product management performance in a large-scale agile product company. Further, we present six product management configurations used in the fintech organization. The most suitable setup depends on the product lifecycle stage, product size, and development team setup. Our summary of the product management configurations and challenges can guide software product managers working in large-scale agile companies.
Highlights
• A systematic literature review was conducted to identify critical success factors.
• A total of 38 primary studies and nearly 100 different factors were identified.
• Results were categorized into 10 main critical success factors.
• A synthesized model of critical success factors in DevOps and their relationships is proposed.
Context:
DevOps is a set of software development and operation practices and a recent addition to a large family of different kinds of software process models. The model emerged out of the observation that information systems operations and developments should be closely integrated activities to ensure the success of any organization. Thus, DevOps methods are an additive tool for companies to improve overall performance in their software development processes and operations.
Objective:
This paper aims to identify the various critical success factors (CSFs) of DevOps projects that have been discussed in prior research. In addition, this study proposes a comprehensive framework for depicting how these CSFs impact or drive DevOps success.
Method:
This study consists of a systematic literature review to collect the primary articles for the analysis.
Results:
After searches in four major publication databases and snowballing, we selected 38 primary studies for the analysis. Nearly 100 different CSFs were identified, which were then categorized into Technical, Organizational, and Social & Cultural dimensions. Based on the results of the literature analysis, a comprehensive framework is proposed that depicts how the CSFs impact or drive DevOps success.
Conclusion:
This paper presents a DevOps framework with various CSFs based on prior literature. The proposed framework will provide collective knowledge of DevOps success factors, which will allow researchers and practitioners to enhance their understanding of CSFs and learn how to handle DevOps issues in organizations. In particular, the paper highlights a number of future research directions related to CSFs.
Software engineering has many software development life cycle (SDLC) models to develop a software application and the latest SDLC models have been provided by agile methods. The agile methodology has been introduced due to some existing lacks in software development. Now agile methodology is used to overcome these deficiencies and improve software development. The use of the agile methodology is increased within software industries due to its distinctive features such as enabling change requests from the client at any stage of a project, client satisfaction, iterative development, and client-developer interaction. Another reason for agile adoption is the methods that are being used for agile software development. These methods include Scrum, Feature drive development, Extreme programming, and Dynamic system development methods. However, the agile methodology has some issues for project development and management. In this study, we discuss all these issues which are related to agile methods and individuals (i.e. team and developer). Further, we suggest the possible improvements that need to be introduced in the agile methodology. We believe such improvements is to make the agile methodology more productive for development environments.
Context: Agile methods in offshored projects have become increasingly popular. Yet, many companies have found that the use of agile methods in coordination with companies located outside the regions of early agile adopters remains challenging. India has received particular attention as the leading destination of offshoring contracts due to significant cultural differences between sides of such contracts. Alarming differences are primarily rooted in the hierarchical business culture of Indian organizations and related command-and-control management behavior styles.
Objective: In this study, we attempt to understand whether cultural barriers persist in distributed projects in which Indian engineers work with a more empowering Swedish management, and if so, how to overcome them. The present work is an invited extension of a conference paper.
Method: We performed a multiple-case study in a mature agile company located in Sweden and a more hierarchical Indian vendor. We collected data from five group interviews with a total of 34 participants and five workshops with 96 participants in five distributed DevOps teams, including 36 Indian members, whose preferred behavior in different situations we surveyed.
Results: We identified twelve cultural barriers, six of which were classified as impediments to agile software development practices, and report on the manifestation of these barriers in five DevOps teams. Finally, we put forward recommendations to overcome the identified barriers and emphasize the importance of cultural training, especially when onboarding new team members.
Conclusions: Our findings confirm previously reported behaviors rooted in cultural differences that impede the adoption of agile approaches in offshore collaborations, and identify new barriers not previously reported. In contrast to the existing opinion that cultural characteristics are rigid and unchanging, we found that some barriers present at the beginning of the studied collaboration disappeared over time. Many offshore members reported behaving similarly to their onshore colleagues.
This open access book constitutes the proceedings of the 21st International Conference on Agile Software Development, XP 2020, which was planned to be held during June 8-12, 2020, at the IT University of Copenhagen, Denmark. However, due to the COVID-19 pandemic the conference was postponed until an undetermined date.
XP is the premier agile software development conference combining research and practice. It is a hybrid forum where agile researchers, academics, practitioners, thought leaders, coaches, and trainers get together to present and discuss their most recent innovations, research results, experiences, concerns, challenges, and trends. Following this history, for both researchers and seasoned practitioners XP 2020 provided an informal environment to network, share, and discover trends in Agile for the next 20 years.
The 14 full and 2 short papers presented in this volume were carefully reviewed and selected from 37 submissions. They were organized in topical sections named: agile adoption; agile practices; large-scale agile; the business of agile; and agile and testing.
With the growing interest of adopting agile methods in offshored process, many companies realized that the use of agile methods and practices in companies located outside the location of early adopters of agile methods may be challenging. India, the main destination of offshoring contracts, have received particular attention, due to the big cultural differences. Critical analysis of related studies suggests that impeding behaviors are mostly rooted in the hierarchical culture of Indian organizations and related management behavior of command-and-control. But what happens in distributed projects with a more empowering onshore management? In this paper, we present the findings from a multiple-case study of DevOps teams with members from a mature agile company located in Sweden and a more hierarchical offshore vendor from India. Based on two focus groups we list culturally different behaviors of offshore engineers that were reported to impede agile ways of working. Furthermore, we report the findings from surveying 36 offshore team members from five DevOps teams regarding their likely behavior in situations reported to be problematic. Our findings confirm a number of previously reported behaviors rooted in cultural differences that impede the adoption of agile ways of working when collaborating with offshore engineers. At the same time, our survey results suggest that among the five surveyed teams there were teams that succeeded with the cultural integration of the offshore team members. Finally, our findings demonstrate the importance of cultural training especially when onboarding new team members.
KeywordsCultureCultural differencesAgileDistributed developmentDistributed agile teams
Agile methods are designed for handling uncertainty as well as reducing risks in product development through transparency, inspection, and adaptation. Applying an effective risk management is in the nature of agile methods. However, when multiple agile teams work on the same product, a higher coordination effort is required and more formal practices are applied. The objective of this paper is to study how risk management can be improved in a scaled agile environment. Therefore, we conducted a case study in a large-sized ecommerce company and interviewed several project managers. The results show that there are differences for risk management in terms of two contexts. On the one hand, informal risk management is rated as good enough for one autonomous team. On the other hand, more formal approaches are needed, when several teams work on the same requirement. Furthermore, a tool for the support of risk management in a scaled agile environment is presented. We can conclude that hybrid development approaches consisting of agile practices and traditional practices, are beneficial, when several teams work in parallel.
Test-Driven Development (TDD) is an incremental approach to software development. Despite it is claimed to improve both quality of software and developers’ productivity, the research on the claimed effects of TDD has so far shown inconclusive results. Some researchers have ascribed these inconclusive results to the negative affective states that TDD would provoke. A previous (baseline) experiment has, therefore, studied the affective reactions of (novice) developers—i.e., 29 third-year undergraduates in Computer Science (CS)—when practicing TDD to implement software. To validate the results of the baseline experiment, we conducted a replicated experiment that studies the affective reactions of novice developers when applying TDD to develop software. Developers in the treatment group carried out a development task using TDD, while those in the control group used a non-TDD approach. To measure the affective reactions of developers, we used the Self-Assessment Manikin instrument complemented with a liking dimension. The most important differences between the baseline and replicated experiments are: (i) the kind of novice developers involved in the experiments—third-year vs. second-year undergraduates in CS from two different universities; and (ii) their number—29 vs. 59. The results of the replicated experiment do not show any difference in the affective reactions of novice developers. Instead, the results of the baseline experiment suggest that developers seem to like TDD less as compared to a non-TDD approach and that developers following TDD seem to like implementing code less than the other developers, while testing code seems to make them less happy.
KeywordsTDDAffective stateReplicationExperiment
Virtual teams rely on enterprise social networking tools such as Slack to collaborate efficiently. While such tools contribute to making the communication more synchronous and support distributed agile development, there are several challenges such as how to interact with each other and how to balance the communication with other types of communication mechanisms such as meetings, e-mail, and phone. In this paper, we describe and discuss how a distributed global project used Slack. Some of the challenges we identified were related to language problems, using too much direct messaging when communicating, and unbalanced activity (33% of the users accounted for 86% of the messages). The positive aspects of using the tool were increased transparency, team awareness, and informal communication. Further, Slack facilitates problem-focused communication which is essential for agile teams. Our study stresses the importance of reflecting on how virtual teams use communication tools, and we suggest that teams decide on guidelines on how to use the tools to improve their coordination.
Members of high performing software teams collaborate, exchange information and coordinate their work on a frequent, regular basis. Most teams have the daily stand-up meeting as a central venue for these activities. Although this kind of meeting is one of the most popular agile practices, it has received little attention from researchers. We observed 102 daily stand-ups and interviewed 60 members of 15 teams in five countries. We found that the practice is usually challenging to conduct in a way that benefits the whole team. Many team members have a negative experience from conducting the meeting, which reduces job satisfaction, co-worker trust and well-being. However, the practice can be adjusted and improved to empower teams. In this article, we describe key factors that affect the meeting and propose four recommendations for improving the practice.
One important discussion in the software development field is related to the skills that people need to have to build successful software products. This debate is generated on one hand by a large number of failures and delays of software projects. On the other hand, the debate is triggered by the need to build even better-quality software in a rapidly changing world. We will examine to which extent soft skills are relevant when hiring software testers and if there are any specific skills required for agile testers.
We analyzed 400 job advertisements for testers from 33 countries, out of which 64% ask for soft skills. Of the advertisements asking for soft skills, there is, on average, a request for 5 soft skills, 11 testing skills, and 5 technical skills. Only 30% of the companies ask explicitly for agile testers. However, our analysis shows no notable differences in skill demands for agile testers and the rest.
Software companies want to hire testers who can communicate well and have analytical and problem-solving skills. There is a significant increase in the need for openness and adaptability, independent-working and team-playing since 2012. In addition, there are new categories of soft skills identified, such as having work ethics, customer-focus and the ability to work under pressure.
Abstract— Virtual teams, with a high level of interdependence and cooperation among team members, are the building block of successful global software organizations. While becoming agile helps on communication and collaboration, such teams meet several challenges in the form of cultural differences, language barriers, national traditions, different values and norms, lack of face-to-face communication, time-zone differences, and difficulties in building and maintaining trust. To successfully implement an agile virtual team the team needs to have the right structure, but equally important is the ability to improve as a team; to become self-managing with shared decision-making and shared leadership. It takes a long time to form such a team, and expert coaching is needed.
We describe and discuss how a team leader coached and improved a global virtual agile team at a large savings and insurance company over a period of one year. Because the team members had overlapping working hours the team was able to base coordination on mutual adjustment and frequent feedback. Social software and face-to-face meetings were important factors to achieve this. By involving the remote developers in the strategy of the product, enabling everyone to pick their own tasks, and focusing on continuous learning, knowledge sharing and team build activities, the team members became highly motivated and self-managing.
Ten years ago, Martins, Gilson, and Maynard reviewed the emerging virtual team (VT) literature. Given the proliferation of new communication technologies and the increased usage of work teams, it is hardly surprising that the last decade has seen an influx of VT research. In this review, we organize the last 10 years of empirical work around 10 main themes: research design, team inputs, team virtuality, technology, globalization, leadership, mediators and moderators, trust, outcomes, and ways to enhance VT success. These themes emerged inductively because they either represent areas with consistent results, a large proliferation of studies, or a grouping of studies and results that differed from where the literature stood a decade ago. Following the review section, we turn our attention toward 10 opportunities for future research: study setting, generational impacts, methodological considerations, new and emerging technologies, member mobility, subgroups, team adaptation, transition processes and planning, creativity, and team member well-being. Some of these opportunities emerged from our review of the extant VT literature; others are grounded in the broader team literature, are unresolved theoretical issues, or were linked to insights discussed within the VT practitioner literature. Within the domain of VTs, technological innovation continues to advance the way team members interact and enable individuals who previously could not be connected to work together as a team. Accordingly, VTs provide great promise to organizations, and the field continues to be rich with research opportunities for the coming decade(s).
Context is a central concept in empirical software engineering. It is one of the distinctive features of the discipline and it is an indispensable part of software practice. It is likely responsible for one of the most challenging methodological and theoretical problems: study-to-study variation in research findings. Still, empirical software engineering research is mostly concerned with attempts to identify universal relationships that are independent of how work settings and other contexts interact with the processes important to software practice. The aim of this paper is to provide an overview of how context affects empirical research and how empirical software engineering research can be better 'contextualized' in order to provide a better understanding of what works for whom, where, when, and why. We exemplify the importance of context with examples from recent systematic reviews and offer recommendations on the way forward.
Self-organizing teams have been recognized and studied in various forms-as autonomous groups in socio-technical systems, enablers of organizational theories, agents of knowledge management, and as examples of complex-adaptive systems. Over the last decade, self-organizing teams have taken center stage in software engineering when they were incorporated as a hallmark of Agile methods. Despite the long and rich history of self-organizing teams and their recent popularity with Agile methods, there has been little research on the topic within software wngineering. Particularly, there is a dearth of research on how Agile teams organize themselves in practice. Through a Grounded Theory research involving 58 Agile practitioners from 23 software organizations in New Zealand and India over a period of four years, we identified informal, implicit, transient, and spontaneous roles that make Agile teams self-organizing. These roles-Mentor, Coordinator, Translator, Champion, Promoter, and Terminator-are focused toward providing initial guidance and encouraging continued adherence to Agile methods, effectively managing customer expectations and coordinating customer collaboration, securing and sustaining senior management support, and identifying and removing team members threatening the self-organizing ability of the team. Understanding these roles will help software development teams and their managers better comprehend and execute their roles and responsibilities as a self-organizing team.
Most large software companies are involved in offshore development, now small- and medium-sized companies are starting to undertake global sourcing too. Empirical research suggests that offshoring is not always successful; however, only a few comprehensive failure stories have been reported. The objective of our study has been to understand why small and medium-sized companies terminate their offshore outsourcing relationships and what alterna- tive arrangements they undertake afterwards. Therefore, we designed a multiple case study of four medium-sized Scandinavian software companies that have terminated their offshore outsourcing relationships. Our results are based on data collected through semi-structured interviews, informal dialogues and analysis of company documents. We found that all compa- nies terminated their offshore contracts because of low quality of the software being developed. This was caused by an inability to build the necessary human and social capital. The companies reported challenges with domain knowledge, a lack of commitment of external developers, cultural clashes, poor communication and high turnover, which only amplified the problems. After termination all four companies changed their sourcing strategy from offshore outsourcing to offshore insourcing and partnerships. We conclude that successful offshore software development requires a change from a cost-driven focus to an intellectual capital- driven focus. To prevent continuous investments into contracts that are destined to fail, companies should look for signs of escalating commitments and terminate relationships that cannot be corrected. Those companies that choose outsourcing shall also take into account that mismatch between the size of the offshore contract relative to the vendor may have a negative effect on a relationship.
Selecting a research method for empirical software engineering research is problematic because the benefits and challenges
to using each method are not yet well catalogued. Therefore, this chapter describes a number of empirical methods available.
It examines the goals of each and analyzes the types of questions each best addresses. Theoretical stances behind the methods,
practical considerations in the application of the methods and data collection are also briefly reviewed. Taken together,
this information provides a suitable basis for both understanding and selecting from the variety of methods applicable to
empirical software engineering.
Virtual teams are increasingly global, creating challenges for communication and coordination due to greater distances, multiple time zones and cultural differences. A longitudinal research program investigating communication and collaboration in globally distributed engineering design teams is described. Preliminary results illustrate the value of combining quantitative and qualitative sources of information on team communication, working patterns and outcomes. Quantitative data includes communication logs, system usage data and questionnaires. Qualitative data includes participant observation, interviews, transcripts of team events and incident reports. Findings focus on the appropriation of technology by teams, the "stickiness" of media usage patterns, the sometimes opposing effects of group technology on team perceptions and the impact of cultural and power issues on communication practices. Qualitative and quantitative data offer distinct but complementary insights into team dynamics, supporting the view that understanding virtual team processes requires multi-faceted research approaches.
Abstract,Case study is a suitable research methodology,for software engineering,research since it studies contemporary phenomena in its natural context. However, the understanding of what constitutes a case study varies, and hence the quality of the resulting studies. This paper aims,at providing,an introduction to case study methodology,and,guidelines for researchers,conducting,case studies and,readers studying,reports of such,studies. The content is based on the authors’ own,experience from conducting,and reading case studies. The terminology,and,guidelines are compiled,from,different methodology,handbooks,in other research domains, in particular social science and information systems, and adapted to the needs,in software,engineering. We,present,recommended,practices for software engineering,case studies as well,as empirically,derived,and,evaluated,checklists for researchers and readers of case study research. Keywords,Casestudy.Research methodology.Checklists .Guidelines
Onboarding is the process of supporting new employees regarding their social and performance adjustment to their new job. Software companies have faced challenges with recruitment and onboarding of new team members, and there is no study that investigates it in a holistic way. In this paper, we conducted a multi-case study to investigate the onboarding of software developers/teams, associated challenges, and areas for further improvement in 3 globally distributed legacy projects. We employed Bauer's model for onboarding to identify the current state of the onboarding strategies employed in each case. We learned that the employed strategies are semi-formalized. Besides, in projects with multiple sites, some functions are executed locally, and the onboarding outcomes may be hard to control. We also learned that onboarding in legacy projects is especially challenging and that decisions to distribute such projects across multiple locations shall be approached carefully. In our cases, the challenges to learn legacy code were further amplified by the project scale and the distance to the original sources of knowledge. Finally, we identified practices that can be used by companies to increase the chances of being successful when onboarding software developers and teams in globally distributed legacy projects.
Software developers use many different communication tools and channels in their work. The diversity of these tools has dramatically increased over the past decade and developers now have access to a wide range of socially enabled communication channels and social media to support their activities. The availability of such social tools is leading to a participatory culture of software development, where developers want to engage with, learn from, and co-create software with other developers. However, the interplay of these social channels, as well as the opportunities and challenges they may create when used together within this participatory development culture are not yet well understood. In this paper, we report on a large-scale survey conducted with 1,449 GitHub users. We discuss the channels these developers find essential to their work and gain an understanding of the challenges they face using them. Our findings lay the empirical foundation for providing recommendations to developers and tool designers on how to use and improve tools for software developers.
This chapter reviews what academics are studying and what practitioners are doing with respect to onboarding. The onboarding "best practices" conveyed through practitioner outlets generally do not provide sufficient prescription to implement policies or programs that will achieve desired outcomes. That prescription is also lacking from the academic literature, as there is a paucity of research on specific onboarding practices. Using the Klein and Heuser (2008 ) Inform-Welcome-Guide framework, we first examine the available insights from the academic literature. We then review the practitioner literature and identify the common recommendations that are made regarding onboarding best practices. We also summarize a recent survey conducted to gain a clearer picture of what organizations are currently doing with respect to onboarding practices. We conclude with a discussion of disconnects observed across these three areas and the identification of future research needs.
Onboarding is frequently used by organizations to help socialize newcomers, but little research has focused on the specific onboarding practices organizations use or the effectiveness of those practices in facilitating newcomer adjustment. To begin addressing this gap, this study explores specific onboarding practices and evaluates the Inform-Welcome-Guide framework of onboarding practices. Data are presented from representatives of 10 organizations regarding what onboarding practices they offer and how those practices are offered. Three hundred seventy-three new employees from those same 10 organizations also shared their perceptions of the practices they experienced, when those practices were experienced, and the perceived helpfulness of those practices. Lastly, the extent to which new employees were socialization was assessed. Several research questions and hypotheses among these variables were examined, and most of the hypotheses supported. Implications of these findings for future research and practice are discussed.
Most companies have learned that cost calculations for offshore outsourcing shouldn't be limited to hourly wages. Looking at salaries alone, you could naively hope for cost reductions of up to 90 percent. However, don't underestimate the cost of knowledge transfer, travel, attrition, miscommunication, and so on. But does an opportunity for cost reduction still exist? To answer this question, researchers delved into the collaboration between a Dutch software company and an Indian vendor. They gathered evidence for direct costs and quantified perceptions of indirect costs associated with an in-house team in the Netherlands and the outsourced offshore team in India. The offshore team's true hourly costs took three years to become comparable with those of the in-house team. Getting close to the break-even point took five years. Learning costs due to offshore employee turnover were the primary cost factor to get under control.
This book offers a broad perspective on issues relating to the sourcing of systems and business processes in a national and global context, examining the client's and the vendor's involvement in sourcing relationships by putting the emphasis on the capabilities that each side should develop as a result of their interactions with each other. © Ilan Oshri, Julia Kotlarsky & Leslie P. Willcocks 2009. All rights reserved.
Companies increasingly make use of geographically dispersed teams to capture knowledge residing at different locations. In this context, shared leadership is considered a key enabler of team performance. Taking a functional perspective on shared leadership, we thus investigate the relationship between shared leadership behaviors and team performance in dispersed teams. Furthermore, we analyze how socio-demographic factors that are characteristic for dispersed teams (i.e., high female-to-male ratio, high mean age, and high levels of national diversity) affect shared leadership behaviors. Based on data from 96 dispersed teams, we show that shared leadership behavior fosters team performance. Further, we find the socio-demographic characteristics typical for dispersed teams to foster shared leadership. Theoretical and managerial implications for human resource management are discussed. © 2012 Wiley Periodicals, Inc.
Many organizations have turned towards globally distributed software development (GSD) in their quest for cheap, higher-quality software that has a short development cycle. However, this kind of development has often been reported as being problematic and complex to manage. There are indications that trust is a fundamental factor in determining the success or failure of GSD projects. This article studies the key factors that cause a lack of trust and the effect of lacking trust and present data from four projects in which problems with trust were experienced. We found the key factors to be poor socialization and socio-cultural fit, increased monitoring, inconsistency and disparities in work practices, reduction of and unpredictability in communication; and a lack of face-to-face meetings, language skills, conflict handling, and cognitive-based trust. The effect of lacking trust was a decrease in productivity, quality, information exchange and feedback, morale among the employees, and an increase in relationship conflicts. In addition, the employees tended to self-protect, to prioritize individual goals over group goals, and to doubt negative feedback from the manager. Further, the managers increased monitoring, which reduced the level of trust even more. These findings have implications for software development managers and practitioners involved in GSD. Copyright © 2008 John Wiley & Sons, Ltd.
A systematic review of global software engineering (GSE) literature from 2000 to 2007 shows the field to be immature. Studies report many challenges but little evidence regarding specific GSE practices directly related to project success or failure. There is evidence that distance matters and, furthermore, that GSE--although driven by cost-reduction goals--seldom brings immediate cost savings.
Global Software Development (GSD) has gained significant popularity as an emerging paradigm. Companies also show interest
in applying agile approaches in distributed development to combine the advantages of both approaches. However, in their most
radical forms, agile and GSD can be placed in each end of a plan-based/agile spectrum because of how work is coordinated.
We describe how three GSD projects applying agile methods coordinate their work. We found that trust is needed to reduce the
need of standardization and direct supervision when coordinating work in a GSD project, and that electronic chatting supports
mutual adjustment. Further, co-location and modularization mitigates communication problems, enables agility in at least part
of a GSD project, and renders the implementation of Scrum of Scrums possible.
This paper explores the role of transactive memory in enabling knowl- edge transfer between globally distributed teams. While the information systems literature has recently acknowledged the role transactive memory plays in improv- ing knowledge processes and performance in colocated teams, little is known about its contribution to distributed teams. To contribute to filling this gap, knowl- edge-transfer challenges and processes between onsite and offshore teams were studied at TATA Consultancy Services. In particular, the paper describes the trans- fer of knowledge between onsite and offshore teams through encoding, storing and retrieving processes. An in-depth case study of globally distributed software development projects was carried out, and a qualitative, interpretive approach was adopted. The analysis of the case suggests that in order to overcome differences derived from the local contexts of the onsite and offshore teams (e.g. different work routines, methodologies and skills), some specific mechanisms supporting the development of codified and personalized 'directories' were introduced. These include the standardization of templates and methodologies across the remote sites as well as frequent teleconferencing sessions and occasional short visits. These mechanisms contributed to the development of the notion of 'who knows what' across onsite and offshore teams despite the challenges associated with globally distributed teams, and supported the transfer of knowledge between onsite and offshore teams. The paper concludes by offering theoretical and prac- tical implications.
Onboarding New Employees: Maximizing Success
- N Talya
- Bauer
Talya N. Bauer. 2010. Onboarding New Employees: Maximizing Success. (2010).
Virtual teams research: 10 years, 10 themes, and 10 opportunities
- Travis Lucy L Gilson
- Nicole C Jones Maynard
- Matti Young
- Marko Vartiainen
- Hakonen
Lucy L Gilson, M Travis Maynard, Nicole C Jones Young, Matti Vartiainen, and
Marko Hakonen. 2015. Virtual teams research: 10 years, 10 themes, and 10
opportunities. Journal of management 41, 5 (2015), 1313-1337.
Context in industrial software engineering research
- Kai Petersen
- Claes Wohlin
Kai Petersen and Claes Wohlin. 2009. Context in industrial software engineering
research. In 2009 3rd International Symposium on Empirical Software Engineering
and Measurement. IEEE, 401-404.
What's the real hourly rate of offshoring
- Šmite D
D Šmite and R van Solingen. 2016. What's the real hourly rate of offshoring?
IEEE Software 33, 5 (2016), 60-70.
Skype: an appropriate method of data collection for qualitative interviews
- Sullivan Jessica R
Jessica R Sullivan. 2012. Skype: an appropriate method of data collection for
qualitative interviews? The Hilltop Review 6, 1 (2012), 10.
Case study research and applications: Design and methods
- Robert K Yin
Robert K Yin. 2017. Case study research and applications: Design and methods.
Sage publications.
Virtual teams research: 10 years, 10 themes, and 10 opportunities
- Gilson Lucy L
The Handbook of Global Outsourcing and Offshoring 3rd edition
- Julia Ilan Oshri
- Leslie P Kotlarsky
- Willcocks
Daily stand-up meetings: start breaking the rules
- Viktoria Stray Nils Brede Moe
- Dag
- Sjoberg