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.
... 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.
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.
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