Context: Pair programming (PP) is more relevant than ever. As modern systems grow in complexity, knowledge sharing and collaboration across teams have become essential. However, despite well-documented benefits of PP, its adoption remains inconsistent across software teams. Objective: This study aims to understand the factors that facilitate or hinder team members’ adoption as well as lasting engagement in PP. Method: We have conducted an exploratory single-case study in a mature agile company in Norway. We collected data through two rounds of interviews with team members in different roles and performed a thematic analysis of the interviews. Results: Our key finding is that multiple factors, related to the perceptions of how PP contributes to daily work, social dynamics and learning, efforts associated with engaging in PP sessions, company and team attitudes, resources, infrastructure, and task characteristics, affect PP engagement. Conclusion: Long-term engagement in PP requires expected benefits with the practice being confirmed in firsthand experiences. Adapting the practice to each unique team, with insights drawn from collective learning, is also beneficial. Our findings will be beneficial for software practitioners seeking to make PP an integrated part of their team’s workflow.

ABSTRACT The COVID-19 pandemic has permanently altered workplace structures, making remote work a widespread practice. While many employees advocate for flexibility, many employers reconsider their attitude toward remote work and opt for structured return-to-office mandates. Media headlines repeatedly emphasize that the corporate world returns to full-time office work. This study examines how companies in software-intensive industry regulate work location, whether corporate policies have evolved in the last five years, and, if so, how, and why. We collected data on remote work regulation from corporate HR and management representatives from 68 companies that vary in size, location, and preferred work modality. Our findings reveal that although many companies prioritize office-oriented work (50%), most companies in our sample permit hybrid work (84%) and only four companies are returning to full-time office work. Remote work regulation does not reveal any particular new “best practice” as policies differ greatly; however, the single most popular arrangement was the three in-office days per week. More than half of the companies (53%) encourage or mandate office attendance centrally, with additional 18% having decentralized mandates. Over a quarter (28%) have changed regulations gradually increasing the mandatory office presence or implementing differentiated conditions. Our key recommendation for office-oriented companies is to consider trust-based recommendations as an alternative to centralized office presence mandates, while for companies oriented toward remote working, we warn about the points of no (or hard) return. Finally, the current state of policies is clearly not final, as companies continue to experiment and adjust their work regulation

• We analyze resignation patterns across 10 years (2016–2025) using HR and exit survey data from Ericsson, a large software-intensive organization. • Our results suggest that employees onboarded during the fully remote period were significantly more likely to resign within their first three years. • Stratified analysis identifies tenure, onboarding modality, and return-to-office policy as key factors influencing early attrition rates. • We demonstrate that even structured remote onboarding struggles to replicate the benefits of in-person integration, such as informal mentoring and social bonding. • Based on our findings, we recommend structured hybrid policies, including co-presence of new hires and their team mates, to mitigate attrition risks and support integration in software engineering teams. [Summary] Context: The COVID-19 pandemic permanently altered workplace structures, normalizing remote work. While flexibility has well-known benefits, critical evidence highlights challenges with fully remote arrangements, particularly for software teams. Objective: This study investigates how employee resignation patterns evolved across different work modalities –onsite, remote, and hybrid — at Ericsson, a global developer of software-intensive systems. Method: Using HR and exit survey data from 2016-2025 for technical roles in Ericsson Sweden, we analyze how tenure, onboarding modality, and reasons for resignation relate to attrition trends before, during, and after the pandemic. Results: Our findings show a marked increase in resignations from mid-2021 to mid-2023, especially among employees with less than three years of tenure. Those onboarded during the fully remote period were significantly more likely to resign early, and this pattern persisted even after Ericsson enhanced remote onboarding practices. Conversely, retention improved after the introduction of structured hybrid work policies, and survivability curves returned to pre-pandemic levels. Conclusions: Our findings suggest that fully remote onboarding, despite structural support, may hinder the formation of organizational attachment and belonging, increasing early attrition. In contexts like software engineering, where onboarding heavily relies on in-person mentoring, frequent peer interactions, and on-the-job training, selective return-to-office practices for new hires and their teams may help restore cohesion and long-term retention. These insights can guide HR leaders and policymakers in crafting post-pandemic work practices.

As organizations increasingly integrate digital product development into their core business, structuring the development organization and workflows effectively becomes critical. Yet, there is no one recipe that tells executives how to design their organizations for success. We explore four approaches to organizing product development, drawing on Mintzberg’s organizational structures, and visualizes ways to bridge the gap between software developers and traditional organizational structures. We categorize four organizations along a spectrum from interface-based models to highly integrated product organizations, highlighting key differences in strategic decision-making, autonomy, and cross-functional collaboration. Our findings contribute to the ongoing discussion on large-scale agile transformations and provide practical guidance for navigating the shifts toward a product-centric operational models.

The pandemic experiences of forced work from home (WFH) in the tech industry turned out better than expected. As a result, modern workplaces that employ software engineers have become increasingly hybrid allowing employees to alternate days spent in the office with days spent working remotely. Yet, approaches to regulate the hybrid work arrangements vary. Some companies implemented strict policies with controlled office presence while others rely on recommendations and permit greater locational flexibility. In this paper, we evaluate how different degrees of locational flexibility influence individual work arrangements and satisfaction in two comparative cases: a company with high degree of flexibility (FinCo) and a company with mandatory office presence (TelCo). Through a survey of 547 practitioners, our findings reveal that flexible policies can achieve higher voluntary office attendance than mandatory requirements. To our surprise, we found that the number of employees visiting the office at least 2-3 days per week in the company with greater flexibility was higher (68%) compared to the company with mandatory attendance (58%). The study also identifies key factors influencing work location choices, including commute time and role. The type of tasks and dependencies with colleagues also matter - employees with more WFH days tended to have more individual tasks, while those with more onsite work days engaged in more collaborative tasks and had colleagues who depended on them. Our results suggest that trust-based approaches and creating attractive office environments may be more effective than strict attendance policies in maintaining desired office presence while supporting employee satisfaction. These findings contribute practical insights for organizations seeking to establish effective post-pandemic work policies for software engineers.

Background. The widespread adoption of hybrid work following the COVID-19 pandemic has fundamentally transformed software development practices, introducing new challenges in communication and collaboration as organizations transition from traditional office-based structures to flexible working arrangements. This shift has established a new organizational norm where even traditionally office-first companies now embrace hybrid team structures. While remote participation in meetings has become commonplace in this new environment, it may lead to isolation, alienation, and decreased engagement among remote team members. Aims. This study aims to identify and characterize engagement patterns in hybrid meetings through objective measurements, focusing on the differences between co-located and remote participants. Method. We studied professionals from three software companies over several weeks, employing a multimodal approach to measure engagement. Data were collected through self-reported questionnaires and physiological measurements using biometric devices during hybrid meetings to understand engagement dynamics. Results. The regression analyses revealed comparable engagement levels between onsite and remote participants, though remote participants show lower engagement in long meetings regardless of participation mode. Active roles positively correlate with higher engagement, while larger meetings and afternoon sessions are associated with lower engagement. Conclusions. Our results offer insights into factors associated with engagement and disengagement in hybrid meetings, as well as potential meeting improvement recommendations. These insights are potentially relevant not only for software teams but also for knowledge-intensive organizations across various sectors facing similar hybrid collaboration challenges.

Abstract For decades, software engineering research and practice has focused primarily on technological and process-related factors. Today, there is a growing interest in organizational, social, and psychological factors, including well-being. Organizational studies show that well-being contributes to work outcomes, including creativity, performance, and productivity. But despite its importance, the predictors and outcomes of software engineers’ well-being as a multidimensional construct to date are under-researched. This paper reports on the multidimensional well-being of professional software engineers and generates insights for the future research in this area. 44 quantitative survey studies published between 2000 and 2023 were selected and synthesized both quantitatively and qualitatively through a systematic literature review. The results of the review were further analyzed to construct a quantitatively-testable theory, detailing the predictors and outcomes of well-being in software engineering organizations. The total number of research participants included in the selected studies is 16,086 software engineering professionals from at least 42 countries. The literature review identified various measures, constructs, and indicators of well-being, as well as its predictors and outcomes. The theory, based on cumulative results of carefully selected quantitative studies, is an attempt to “correct the record” by establishing well-being in software engineering as a meta-construct of hedonic, eudaimonic, and integrated or hedaimonic qualities predicted by different individual, team and organizational factors and impacting the functioning of software engineers and their organizations. The review highlighted the under-researched aspects of well-being in software engineering and confirmed the need for more advanced quantitative studies. We hope that the theory will benefit researchers in conducting future studies and practitioners in developing nuanced and science-based interventions for improving software engineers’ well-being.

ABSTRACT Background After the pandemic, software engineers were forced to work remotely, in many cases without prior experience of doing so. Objective The objective of this work is to analyze the factors that influence engineers' motivation, stress and performance when working remotely after the pandemic, and to what level. Methods A significant number (around 1000) of Latin‐American software development professionals from different countries who work remotely were surveyed in order to study the factors that affect them and how when they work in this manner. The data collected from the survey were then statistically analyzed using the partial least square‐structural equation modeling (PLS‐SEM) method. Conclusions The analysis of the data made it possible to conclude that there are direct negative effects of stress on performance and direct positive effects of motivation on performance. In addition, we found that skills, experience, and teamwork behavior, such as trust, communication, and knowledge sharing, play an important role when working remotely.

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

While modern software companies strive to increase team autonomy to enable them to successfully operate the piece of software they develop and deploy, efficient ways to orchestrate the work of multiple autonomous teams working in parallel are still poorly understood. In this paper, we report how team autonomy is maintained at Spotify at scale, based on team retrospectives, interviews with team managers and archival analysis of corporate databases and work procedures. In particular, we describe how managerial authority is decentralized through various workgroups with collective authority, what compromises are made to team autonomy to ensure alignment and which team-related factors can further hinder autonomy. Our findings show that scaled autonomy at Spotify does not mean anarchy, or unlimited permissiveness. Instead, squads are expected to take responsibility for their work and coordinate, communicate and align their actions with others, and comply with a few enabling constraints. Further, squads take many decisions independently without management control or due to collective efforts that bypass formal boundary structures. Mechanisms and strategies that enable self-organization at Spotify are related to effective sharing of the codebase, achieving alignment, networking and knowledge sharing, and are described to guide other companies in their efforts to scale autonomy.

In early 2020, the Covid-19 pandemic forced employees in tech companies worldwide to abruptly transition from working in offices to working from their homes. During two years of predominantly working from home, employees and managers alike formed expectations about what post-pandemic working life should look like. Many companies are experimenting with new work policies that balance employee- and manager expectations regarding where, when and how work should be done in the future. In this article, we gather experiences of the new trend of remote working based on the synthesis of 22 company-internal surveys of employee preferences for WFH, and 26 post-pandemic work policies from 17 companies and their sites, covering 12 countries in total. Our results are threefold. First, through the new work policies, all companies formally give employees more flexibility regarding working time and location. Second, there is a great variation in how much flexibility the companies are willing to yield to the employees. The paper details the different formulations that companies adopted to document the extent of permitted WFH, exceptions, relocation permits and the authorisation procedures. Third, we document a change in the psychological contract between employees and managers, where the option of working from home is converted from an exclusive perk that managers could choose to give to the few, to a core privilege that all employees feel they are entitled to. Finally, there are indications that as the companies learn and solicit feedback regarding the efficiency of the chosen strategies, we will see further developments and changes in the work policies concerning how much flexibility to work whenever and from wherever they grant. Through these findings, the paper contributes to a growing literature about the new trends emerging from the pandemic in tech companies and spells out practical implications onwards.

The COVID-19 outbreak has admittedly caused interruptions to production, transportation, and mobility, therefore, having a significant impact on the global supply and demand chain's well-functioning. But what happened to companies developing digital services, such as software? How has the enforced Working-From-Home (WFH) mode impacted their ability to deliver software, if at all? This article shares our findings from monitoring the WFH during 2020 in an international software company with engineers located in Sweden, the USA, and the UK. We analyzed different aspects of productivity, such as developer job satisfaction and well-being, activity, communication and collaboration, efficiency and flow based on the archives of commit data, calendar invites, Slack communication, the internal reports of WFH experiences, and 30 interviews carried out in April/May and September 2020. We add more objective evidence to the existing COVID-19 studies the vast majority of which are based on self-reported productivity from the early months of the pandemic. We find that engineers continue committing code and carrying out their daily duties, as their routines adjust to "the new norm". Our key message is that software engineers can work from home and quickly adjust their tactical approaches to the changes of unprecedented scale. Further, WFH has its benefits, including better work-life balance, improved flow, and improved quality of distributed meetings and events. Yet, WFH is not challenge free: not everybody feels equally productive working from home, work hours for many increased, while physical activity, socialization, pairing and opportunities to connect to unfamiliar colleagues decreased. Information sharing and meeting patterns also changed. Finally, experiences gained during the pandemic will have a lasting impact on the future of the workplace. The results of an internal company-wide survey suggest that only 9% of engineers will return to work in the office full time. Our article concludes with the InterSoft's strategy for work from anywhere (WFX), and a list of useful adjustments for a better WFH.

Developing software-intensive products or services usually involves a plethora of software artefacts. Assets are artefacts intended to be used more than once and have value for organisations; examples include test cases, code, requirements, and documentation. During the development process, assets might degrade, affecting the effectiveness and efficiency of the development process. Therefore, assets are an investment that requires continuous management. Identifying assets is the first step for their effective management. However, there is a lack of awareness of what assets and types of assets are common in software-developing organisations. Most types of assets are understudied, and their state of quality and how they degrade over time have not been well-understood. We performed an analysis of secondary literature and a field study at five companies to investigate and identify assets to fill the gap in research. The results were analysed qualitatively and summarised in a taxonomy. We present the first comprehensive, structured, yet extendable taxonomy of assets, containing 57 types of assets. The taxonomy serves as a foundation for identifying assets that are relevant for an organisation and enables the study of asset management and asset degradation concepts.

Background: Modern code review is expected to facilitate knowledge sharing: All relevant information, the collective expertise, and meta-information around the code change and its context become evident, transparent, and explicit in the corresponding code review discussion. The discussion participants can leverage this information in the following code reviews; the information diffuses through the communication network that emerges from code review. Traditional time-aggregated graphs fall short in rendering information diffusion as those models ignore the temporal order of the information exchange: Information can only be passed on if it is available in the first place.

BACKGROUND: The COVID-19 pandemic triggered a natural experiment of an unprecedented scale as companies closed their offices and sent employees to work from home. Many managers were concerned that their engineers would not be able to work effectively from home, or lack the motivation to do so, and that they would lose control and not even notice when things go wrong. As many companies announced their post-COVID permanent remote-work or hybrid home/office policies, the question of what can be expected from software engineers who work from home becomes more and more relevant. AIMS: To understand the nature of home telework we analyze the evidence of perceived changes in productivity comparing office work before the pandemic with the work from home during the pandemic from thirteen empirical surveys of practitioners. METHOD: We analyzed data from six corporate surveys conducted in four Scandinavian companies combined with the results of seven published surveys studying the perceived changes in productivity in industrial settings. In addition, we sought explanations for the variation in perceived productivity among the engineers from the studied companies through the qualitative analysis of open-ended questions and interviews. RESULTS: Combined results of 7686 data points suggest that though on average perceived productivity has not changed significantly, there are developers who report being more productive, and developers being less productive when working from home. Positively affected individuals in some surveys form large groups of respondents (up to 50%) and mention benefiting from a better organization of work, increased flexibility and focus. Yet, there are equally large groups of negatively affected respondents (up to 51%) who complain about the challenges related to remote teamwork and collaboration, as well as emotional issues, distractions and poor home office environment and equipment. Finally, positive trends are found in longitudinal surveys, i.e., developers' productivity in the later months of the pandemic show better results than those in the earlier months. CONCLUSIONS: We conclude that behind the average "no change" lays a large variation of experiences, which means that the work from home might not be for everyone. Yet, a longitudinal analysis of the surveys is encouraging, as it shows that the more pessimistic results might be influenced by the initial experiences of an unprecedented crisis. At the end, we put forward the lessons learned during the pandemic that can inspire the new post-pandemic work policies.

Despite benefits Enterprise Architecture (EA) has brought, EA has also been challenged due to its complexity, heavy workload demands, and poor user acceptance. Researchers and practitioners proposed to use EA in an agile and "business outcome-driven" way. This means that EA should not primarily be developed and used according to a pre-defined framework. Instead, EA should be developed and used for specific business purposes and by means of concrete deliverables. By doing so, a more effective and efficient way of EA application could be enabled. However, there is no common agreement on what types of business goals can be expected to be achieved by using EA (The What) and how to achieve these goals through EA solutions (The How). To address these issues, we analysed the information provided by leading EA tool vendors available on their websites to get inspiration. The results showed that Use Cases (UCs) are used generally to motivate potential EA users by focusing on specific business issues. Then, EA solutions to address such business requirements or challenges are scoped and derived accordingly. We expect relevant findings could bring inspiration to agile EA engineering, change the EA “heavy-weight” reputation, and improve the application of EA even among its sceptics.

Abstract Along with the increasing popularity of agile software development, software work has become much more social than ever. Contemporary software teams rely on a variety of collaborative practices, such as pair programming, the topic of our study. Many agilists advocated the importance of collocation, face-to-face interaction, and physical artefacts incorporated in the shared workspace, which the COVID-19 pandemic made unavailable; most software companies around the world were forced to send their engineers to work from home. As software projects and teams overnight turned into distributed collaborations, we question what happened to the pair programming practice in the work-from-home mode. This paper reports on a longitudinal study of remote pair programming in two companies. We conducted 38 interviews with 30 engineers from Norway, Sweden, and the USA, and used the results of a survey in one of the case companies. Our study is unique as we collected the data longitudinally in April/May 2020, Sep/Oct 2020, and Jan/Feb 2021. We found that pair programming has decreased and some interviewees report not pairing at all for almost a full year. The experiences of those who paired vary from actively co-editing the code by using special tools to more passively co-reading and discussing the code and solutions by sharing the screen. Finally, we found that the interest in and the use of PP over time, since the first months of the forced work from home to early 2021, has admittedly increased, also as a social practice.

Abstract Agile methods and the related concepts of employee empowerment, self-management, and autonomy have reached large-scale software organizations and raise questions about commonly adopted principles for authority distribution. However, the optimum mechanism to balance the need for alignment, quality, and process control with the need or willingness of teams to be autonomous remains an unresolved issue. In this paper, we report our findings from a multiple-case study in two large-scale software development organizations in the telecom industry. We analysed the autonomy of the agile teams in the organizations using Hackman’s classification of unit authority and found that the teams were partly self-managing. Further, we found that alignment across teams can be achieved top-down by management and bottom-up through membership in communities or through dialogue between the team and management. However, the degree of team autonomy was limited by the need for organizational alignment. Top-down alignment and control were maintained through centralized decision-making for certain areas, the use of supervisory roles, mandatory processes, and checklists. One case employed a bottom-up approach to alignment through the formation of a community composed of all teams, experts, and supporting roles, but excluding managers. This community-based alignment involved teams in decision-making and engaged them in alignment initiatives. We conclude that implementation of such bottom-up structures seems to provide one possible mechanism for balancing organizational control and team autonomy in large-scale software development.

Abstract High‐quality work is said to depend on team abilities. However, teams working in large‐scale projects often do not have all expertise to complete their tasks, which are also highly interdependent. Therefore, teams need to rely on coordination with other teams, experts, and supporting roles. In this paper, we explore teams' coordination needs and evaluate the impact of the satisfaction of these needs on team performance. We conducted an embedded multicase study with nine teams in two projects in two companies. We collected qualitative data through nine focus groups and 19 interviews and quantitative data using a questionnaire with 49 members from the studied teams. Our results suggest that project‐, team‐, and task‐related characteristics impact teams' coordination needs. Even in the same project, teams may have different expertise and work coordination needs. We found that the satisfaction of these needs seems to influence teams' performance, although our results are inconclusive and yield a closer look in future research. On the basis of our findings, we recommend the companies to cultivate a networking culture and support teams external coordination with other teams and experts, paying attention to their needs, for example, driven by a lack of experience or increased work complexity.

Code evolution, whether related to the development of new features, bug fixing, or refactoring, inevitably changes the quality of the code. One particular type of such change is the accumulation of Technical Debt (TD) resulting from sub-optimal design decisions. Traditionally, refactoring is one of the means that has been acknowledged to help to keep TD under control. Developers refactor their code to improve its maintainability and to repay TD (e.g., by removing existing code smells and anti-patterns in the source code). While the accumulation of the TD and the effect of refactoring on TD have been studied before, there is a lack of empirical evidence from industrial projects on how the different types of code changes affect the TD and whether specific refactoring operations are more effective for repaying TD. To fill this gap, we conducted an empirical study on an industrial project and investigated how Refactoring, Bug Fixing, and New Development affect the TD. We have analyzed 2, 286 commits in total to identify which activities reduced, kept the same, or even increased the TD, further delving into specific refactoring operations to assess their impact. Our results suggest that TD in the studied project is mainly introduced in the development of new features (estimated in 72.8 hours). Counterintuitively, from the commits tagged as refactoring, only 22.90% repay TD (estimated to repay 8.30 hours of the TD). Moreover, while some types of refactoring operations (e.g., Extract Method), help repaying TD, other refactoring operations (e.g., Move Class) are highly prone to introduce more TD.

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.

Large-scale distributed software projects with long life cycles often involve a considerable amount of complex legacy code. The combination of scale and distribution challenges and the difficulty in acquiring knowledge about massive amounts of complex legacy code may make the onboarding of new developers/teams problematic. These problems may lead to extended periods of low performance. The primary objective of this paper is to investigate the performance evolution of offshore newcomers onboarded in a large-scale globally distributed project and how it relates to the employed onboarding strategy. To achieve our objective, we conducted a case study in Ericsson. We identified that the following aspects in the onboarding strategy employed in the investigated case seem to be related to the unexpectedly low performance evolution: i) the distance to mentors; ii) the used formal training approach, which did not fit the sociocultural background of the newcomers; iii) allocation of large and distributed tasks in the early stages of the onboarding process; and iv) team instability. We conclude that the onboarding of newcomers in globally distributed projects must be planned well ahead and should consider avoiding the aspects mentioned above.

Offshore outsourcing of software development has been both famous for the promises of great cost reductions, and infamous for the hidden costs associated with the challenges of organizing software work over distance. Experience shows that many of these costs do not receive the deserved attention and are often excluded when making offshoring decisions. As a result, there is often a significant deviation between the expected and the realized costs of offshoring. In this paper, we investigate the awareness of the extra costs when making an offshoring decision, and the significance of the actual cost deviations. We conducted a single case study of a company that carried out an offshore outsourcing pilot project. We collected qualitative data from interviews, observations and a retrospective, and quantitative data on the costs and effort associated with the project. We conclude that the company was aware of the hidden cost factors, but largely underestimated their significance. The costs that surfaced in the studied project accounted for a total deviation of 181% and several individual cost categories with more than 400% overrun. The two main cost drivers in our study were the distance and poor process fit, which escalated the investments needed to make the collaboration work. Our results suggest that pilots are useful to understand the key problem areas in an offshoring collaboration, but too limited to shed light on all potential problems (e.g. turnover) due to the short timeframe. We also conclude that results of pilot projects shall not be the only data source when calculating the true costs of offshoring, since the start-up phase of an offshoring relationship carries large investments. Finally, we provide recommendations for companies in a similar situation on how to run and learn from offshore outsourcing pilot projects.

Abstract Organizational management traditionally has taken care of all the important strategy, structure, and work-design decisions, as well as most of the ongoing decisions about work procedures. In large-scale corporations with many geographically distributed sites and high divisional detachment, such strategies are yet doomed to result in implementing irrelevant work methods and procedures that conflict with the local interests. As Tayloristic habits are disappearing, organizations willingly or unwillingly change their decision-making approaches to enable more participation and influence from the performers. These trends are associated with the rise of participation-based parallel structures, such as quality circles, task forces or communities of practice. In this paper, we present our findings from studying corporate-level communities by the means of a multi-case study at Ericsson. We found that the main hindrances are related to the limited decision-making authority of parallel structure, member selection and achieving representation across the organizational units. Our results suggest that parallel structures highly depend on the authority of the members within their local communities, and their ability to not only channel the dialog between the units they represent and the community, but also enable the active engagement of the unit in the community studies. As such, we believe that special attention shall be put on the ambassador role of the community members.

Global software engineering has changed the way software is developed today. To address the new challenges, many universities have launched specially tailored courses to train young professionals to work in globally distributed projects. However, a mere acknowledgment of the geographic, temporal, and cultural differences does not necessarily lead to a deep understanding of the underlying practical implications. Therefore, many universities developed alternative teaching and learning activities, such as multi-university collaborative projects and small-scale simulations or games. In this article, we present a small-scale exercise that uses LEGO bricks to teach skills necessary for global work. We describe the many different interventions that could be implemented in the execution of the exercise. We had seven runs of the exercises and report our findings from executing seven runs of the exercise with the total of 104 students from five different courses in two different universities. Our results suggest that the exercise can be a valuable tool to help students dealing with troublesome knowledge associated with global software engineering and a useful complement to the courses dedicated to this subject.

Background: Employee turnover in GSD is an extremely important issue, especially in Western companies offshoring to emerging nations. Aims: In this case study we investigated an offshore vendor company and in particular whether the employees' retention is related with their experience. Moreover, we studied whether we can identify a threshold associated with the employees' tendency to leave the particular company. Method: We used a case study, applied and presented descriptive statistics, contingency tables, results from Chi-Square test of association and post hoc tests. Results: The emerging results showed that employee retention and company experience are associated. In particular, almost 90% of the employees are leaving the company within the first year, where the percentage within the second year is 50-50%. Thus, there is an indication that the 2 years' time is the retention threshold for the investigated offshore vendor company. Conclusions: The results are preliminary and lead us to the need for building a prediction model which should include more inherent characteristics of the projects to aid the companies avoiding massive turnover waves.

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

Offshoring software development activities to a remote site in another country continues to be one of the key strategies to save development cost. However, the assumed economic benefits of offshoring are often questionable, due to a large number of hidden costs and too simple cost calculations. This study is a continuation of our work on calculating the true hourly cost that includes the extra direct and indirect costs on top of the salary-based hourly rates. We collected data from an empirical case study conducted in a large international corporation. This corporation develops software-intensive systems and has offshored its ongoing product development from Sweden to a recently on-boarded captive company site in India. In this paper, we report a number of extra costs and their impact on the resulting hourly cost as well as the bottom-line cost per work unit. Our analysis includes quantitative data from corporate archives, and expert-based estimates gathered through focus groups and workshops with company representatives from both the onshore and the offshore sites. Our findings show that there is additional cost that can be directly or at least strongly attributed to the transfer of work, working on a distance, and immaturity of the offshore site. Consideration of extra costs increases the hourly cost several times, while the performance gaps between the mature sites and the immature site leads to an even higher difference. As a result, two years after on-boarding of the offshore teams, the mature teams in high-cost locations continue to be "cheaper" despite the big salary differences, and the most positive hypothetical scenario, in which the company could break even, is unrealistic. The implications of our findings are twofold. First, offshoring of complex ongoing products does not seem to lead to short-term bottom-line economic gains, and may not even reach breakeven within five years. Second, offshoring in the studied case can be justified but merely when initiated for other reasons than cost.

Context Large software development projects involve multiple interconnected teams, often spread around the world, developing complex products for a growing number of customers and users. Succeeding with large-scale software development requires access to an enormous amount of knowledge and skills. Since neither individuals nor teams can possibly possess all the needed expertise, the resource availability in a team's knowledge network, also known as social capital, and effective knowledge coordination become paramount. Objective In this paper, we explore the role of social capital in terms of knowledge networks and networking behavior in large-scale software development projects. Method We conducted a multi-case study in two organizations, Ericsson and ABB, with software development teams as embedded units of analysis. We organized focus groups with ten software teams and surveyed 61 members from these teams to characterize and visualize the teams’ knowledge networks. To complement the team perspective, we conducted individual interviews with representatives of supporting and coordination roles. Based on survey data, data obtained from focus groups, and individual interviews, we compared the different network characteristics and mechanisms that support knowledge networks. We used social network analysis to construct the team networks, thematic coding to identify network characteristics and context factors, and tabular summaries to identify the trends. Results Our findings indicate that social capital and networking are essential for both novice and mature teams when solving complex, unfamiliar, or interdependent tasks. Network size and networking behavior depend on company experience, employee turnover, team culture, need for networking, and organizational support. A number of mechanisms can support the development of knowledge networks and social capital, for example, introduction of formal technical experts, facilitation of communities of practice and adequate communication infrastructure. Conclusions Our study emphasizes the importance of social capital and knowledge networks. Therefore, we suggest that, along with investments into training programs, software companies should also cultivate a networking culture to strengthen their social capital, a known driver of better performance.

Background: Developers and development teams in large-scale software development are often required to learn continuously. Organizations also face the need to train and support new developers and teams on-boarded in ongoing projects. Although learning is associated with performance improvements, experience shows that training and learning does not always result in a better performance or significant improvements might take too long.

Abstract Context: Global software development (GSD) projects can have distributed teams that work independently in different locations or team members that are dispersed. The various development settings in GSD can influence quality during product evolution. When evaluating quality using defects as a proxy, the development settings have to be taken into consideration. Objective: The aim is to provide a systematic method for supporting investigations of the implication of GSD contexts on defect data as a proxy for quality. Method: A method engineering approach was used to incrementally develop the proposed method. This was done through applying the method in multiple industrial contexts and then using lessons learned to refine and improve the method after application. Results: A measurement instrument and visualization was proposed incorporating an understanding of the release history and understanding of GSD contexts. Conclusion: The method can help with making accurate inferences about development settings because it includes details on collecting and aggregating data at a level that matches the development setting in a GSD context and involves practitioners at various phases of the investigation. Finally, the information that is produced from following the method can help practitioners make informed decisions when planning to develop software in comparable circumstances. Copyright © 2016 John Wiley & Sons, Ltd.

Knowledge management (KM) is essential for success in any software project, but especially in global software development where team members are separated by time and space. Software organizations are managing knowledge in various ways to increase transparency and improve software team performance. One way to classify these strategies is proposed by Earl who defined seven knowledge management schools. The objective of this research is to study knowledge creation and sharing practices in a number of distributed agile projects, map these practices to the knowledge management strategies and determine which strategies are most common, which are applied only locally and which are applied globally. This is done by conducting a series of semi-structured qualitative interviews over a period of time span during May, 2012-June, 2013. Our results suggest that knowledge sharing across remote locations in distributed agile projects heavily relies on knowledge codification, i.e. Technocratic KM strategies, even when the same knowledge is shared tacitly within the same location, i.e. Through behavioral KM strategies.

Agile software development has become well known to the community and is nowadays frequently used for the development of different kinds of software systems. Agile methods are widely spread and often adapted to the context-specific needs. The adaptations constitute reductions and/or extensions of agile practices. Yet, we have limited knowledge about the impact of some of the individual practices, which is crucial to justify organizational changes. To systemize the knowledge of the impact of agile practices, we launch this workshop and invite researchers and practitioners to work on a documenting and accumulating their experiences in a knowledge base.

There exists no generally accepted theory in software engineering, and at the same time a scientific discipline needs theories. Some laws, hypotheses and conjectures exist, but yet no generally accepted theory. Several researchers and initiatives emphasize the need for theory in the discipline. The objective of this paper is to formulate a theory of software engineering. The theory is generated from empirical observations of industry practice, including several case studies and many years of experience in working closely between academia and industry. The theory captures the balancing of three different intellectual capitals: human, social and organizational capitals, respectively. The theory is formulated using a method for building theories in software engineering. It results in a theory where the relationships between the three different intellectual capitals are explored and explained. The theory is illustrated based on an industrial case study, where it is shown how decisions made in industry practice are explainable with the formulated theory, and the consequences of the decisions are made explicit. Based on the positive results, it is concluded that the theory may have a good explanatory power, although more evaluations are needed.

Context: In large-scale distributed software projects the expertise may be scattered across multiple locations.

The link between maintenance and product quality, as well as the high cost of software maintenance, highlights the importance of efficient maintenance processes. Sustaining maintenance work efficiency in a global software development setting that involves a transfer is a challenging endeavor. Studies report on the negative effect of transfers on efficiency. However, empirical evidence on the magnitude of the change in efficiency is scarce. In this study we used a lean indicator to visualize variances in defect resolution cycles for two large products during evolution, before, during and after a transfer. Focus group meetings were also held for each product. Study results show that during and immediately after the transfer the defect inflow is higher, bottlenecks are more visible, and defect resolution cycles are longer, as compared to before the transfer. Furthermore we highlight the factors that influenced the change in defect resolution cycles before, during, and after the transfer.

Offshore software development has gained momentum and most of software companies today have implemented offshore strategies of some sort. Many of these strategies are enforced by corporate top management and driven by assumptions that lower development wages guarantee cheaper and better software development. In practice, offshore software development is associated with many risks, and achievement of the expected benefits is not as straightforward as the rumor has it. In this paper we explore an implementation of an offshore strategy in a Swedish software company that opened its offshore branch in Russia. Based on extensive documentation analysis we create an overview of the initially expected benefits and obstacles that prevailed among onshore product and development unit managers. Years after implementation of the offshore in sourcing strategy we asked these managers about the achievement of their expectations. We observed that the company documented various expected benefits when implementing an off shoring strategy and also concerns that some of these benefits might not be achieved. Seven years after its implementation, the off shoring strategy was overall considered working, however the expected benefits were not fully achieved. More importantly, several gaps were identified, that suggest that the enforced strategy has resulted in a stable but not beneficial collaboration from the onshore perspective.

Developing and maintaining team awareness within and across teams working in the same project helps team members in aligning their activities and facilitates implicit coordination. This requires both task and presence awareness. In this paper, we share our findings from a survey in which we measured the level of team awareness in cross-team collaborations with varying degree of separation. To measure the levels of awareness we asked questions like who is who, who knows what, who is on a vacation, who depends on whom and alike. Results from surveying 17 pairs of teams from 15 organizations indicate that level of awareness in cross-team collaborations is generally lower than that within the teams. We also found that task and presence awareness levels are independent and can vary. In addition to distance, we identified a few other factors with potential positive and negative influence on team awareness.

Many companies have development sites around the globe. This inevitably means that development work may be transferred between the sites. This paper defines a classification of software transfer types, it divides transfers into three main types: full, partial and gradual transfers to describe the context of a transfer. The differences between transfer types, and hence the need for a classification, are illustrated with staffing curves for two different transfer types. The staffing curves are obtained through a combination of interviews with both high-level management and a group of experts, and an industrial case study. From the empirical work, it is concluded that the distribution of personnel differs for different types of transfer, which means that it is crucial to be clear about different classes of software transfers. If not, it is easy to underestimate the effort needed to transfer software work as well as additional costs related to the transfer as such.

In the light of globalization it is not uncommon that different teams from different locations get involved in the development of a software product during its evolution. However, empirical evidence that demonstrates the effect of changing team members on software quality is scarce. In this paper, we investigate quality of a software product, across subsequent software releases, that was first developed in one location of Ericsson, a large multinational corporation, then jointly with an offshore location of the same company, and finally transferred offshore. To get a better understanding multiple data sources are used in the analysis: qualitative data, consisting of interviews and documentation, and quantitative data, consisting of release history and defect statistics. Our findings confirm an initial decline in efficiency and quality after a transfer, and highlight the areas of concern for companies that are considering transferring their product development from experienced teams to those having limited or no previous engagement with the product.

Most large software companies are involved in offshore development of some sort, and now the trend is that small and medium sized companies are also going global. While empirical research suggests that offshoring are not always successful, evidence explaining the reasons for terminated collaborations is scarce, especially for small and medium sized companies. In this paper we explore the stories of three Scandinavian medium-sized software companies that have terminated their offshore outsourcing relationships and changed to offshore insourcing arrangements. The main reason for termination was disappointing low quality of the software delivered, being caused by insufficient domain knowledge, high turnover and a lack of motivation among the remote and external developers. We apply the theory of single-loop and double-loop learning in order to explain why the companies failed to correct the experienced problems, and the theory of escalating commitment to explain why the companies did not correct the failing course of action earlier. Finally we describe the change in the choice of the principle sourcing strategy from outsourcing to insourcing.

SUMMARY Globalization has influenced the way software is developed today, and many software organizations have started to actively utilize resources from around the world. However, these endeavors are recognized as very challenging, and they have attracted a lot of attention in software research in the past decade. Unlike many other research initiatives, which explore the complexities of distributed software development activities, the focus of this paper is on software transfers. Software transfers refer to activities that are moved from one location to another. The authors draw attention to the lessons learned from an empirical investigation of two transfer projects conducted at Ericsson. Both transfers were performed between a site in Sweden and a site in India. The observations outline a set of generic practices that have been found useful for transferring software development within a company. It also highlights a number of challenges to be addressed and a set of corresponding recommendations. Finally, the paper emphasizes the need to identify software products that are suitable for transfers and the need to monitor the long‐term effects of transfer. Copyright © 2011 John Wiley & Sons, Ltd.

Trust is one of the key factors that determines success or failure of any software project. However, achieving and maintaining trust in distributed software projects, when team members are geographically, temporally and culturally distant from each other, is a remarkable challenge. This paper explores the dynamics of trust and best practices performed in software organizations to address trust-related issues in global software engineering. Semi-structured interviews were conducted in six different distributed software development organizations and a resulting trust dynamics model is presented. Based on the findings, the paper also provides suggestions for the industry to achieve trust in distributed collaborations.

Globalization has significantly changed the way the market operates today. In particular, it motivated many software companies expand through acquisitions and utilize skillful resources regardless of their location around the globe. Global software engineering endeavors have been widely explored in the research literature for the past decade and associated with many challenges caused by geographic, temporal and cultural distances. While software development as such is quite a challenging task, involvement of dispersed and diverse software teams created a perceived crisis with respect to, so called, soft issues that have not been targeted in the past. The effect of distribution versus co-location is still under investigation, and the most commonly referred challenges are related to communication, coordination and control. Thus the focus of research to a large extent has shifted from software product as the center, to people developing software.

Although global software work nowadays is not a phenomenon, research and practice is still addressing the complexities associated with the new forms of work enabled through globalization. `Go global' strategies usually prescribe two alternative approaches: distribution of software development activities across several locations, or re-location of work to another site. This research paper focuses on the latter approach that is called software product transfers and discusses findings from an empirical case study conducted in Ericsson. The observations indicate that transferring software work from one site to another site of the same company is a challenging endeavor. Furthermore, practices used in co-located projects do not necessarily lead to a desired outcome. The paper provides an overview of the challenges and highlights practical advice for handling software product transfers.

Increased popularity of global software engineering (GSE) has resulted in quite a number of research and industrial studies. As the area matures, an increased focus on empirically supported results leads to a greater potential impact on future research and industrial practice. However, since GSE scenarios are diverse, what works in one context might not directly apply in another. Thus it is necessary to understand, how GSE-related empirical findings should be reported to be useful for practitioners and researchers. Furthermore, itdasias important to summarize progress and get the big picture of published research to identify gaps and commonalities. In this paper we analyze differentiating factors of GSE scenarios and offer a classification scheme for describing the context of a GSE study. In addition, we report initial results of a systematic review on GSE-related empirical literature using papers from ICGSE 2006 and 2007, at the same time illustrating and evaluating the proposed scheme.

The influence of globalization on software development has been recognized as significant by many studies. Existence of unique factors that distinguish globally distributed software development environment increases the complexity of software development processes and brings challenges to project managers in achieving project success. This paper describes a study on globally distributed projects, which aims to determine the severity of global threats and provide an approach for sustainable support in managing project outcome predictions. Risk Barometer has been developed based on empirical data from industrial projects investigated during the study. It calculates the probability of negative outcome for global threats upon historical data. The results of this study provide practitioners that lack knowledge and experience a tool for more effective risk management, as well as cost and effort estimation for a globally distributed project.