In Global Software Engineering (GSE), the need for a common terminology and knowledge classification has been identified to facilitate the sharing and combination of knowledge by GSE researchers and practitioners. A GSE taxonomy was recently proposed to address such a need, focusing on a core set of dimensions; however its dimensions do not represent an exhaustive list of relevant GSE factors. Therefore, this study extends the existing taxonomy, incorporating new GSE dimensions that were identified by means of two empirical studies conducted recently.

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.

Aims: In this paper, we report our experiences from establishing an approach to measure learning results and associated performance impact for developers and teams in Ericsson.

Method: Experiences reported herein are a part of an exploratory case study of an on-going large-scale distributed project in Ericsson. The data collected for our measurements included archival data and expert knowledge acquired through both unstructured and semi-structured interviews. While performing the measurements, we faced a number of challenges, documented in the form of lessons learned.

Results: We aggregated our experience in eight lessons learned related to collection, preparation and analysis of data for further measurement of learning potential and performance in large-scale distributed software development.

Conclusions: Measuring learning and performance is a challenging task. Major problems were related to data inconsistencies caused by, among other factors, distributed nature of the project. We believe that the documented experiences shared herein can help other researchers and practitioners to perform similar measurements and overcome the challenges of large-scale distributed software projects, as well as proactively address these challenges when establishing project measurement programs.

Software architects are key assets for successful development projects. However, not much research has investigated the challenges they face in large-scale distributed projects. So, researchers investigated how architects at Ericsson were organized, their roles and responsibilities, and the effort they spent guarding and governing a large-scale legacy product developed by teams at multiple locations. Despite recent trends such as microservices and agile development, Ericsson had to follow a more centralized approach to deal with the challenges of scale, distribution, and monolithic architecture of a legacy software product. So, the architectural decisions were centralized to a team of architects. The team extensively used code reviews to not only check the code's state but also reveal defects that could turn into maintainability problems. The study results also suggest that the effort architects spend designing architecture, guarding its integrity and evolvability, and mentoring development teams is directly related to team maturity. In addition, significant investment is needed whenever new teams and locations are onboarded.

Context: Large-scale distributed software projects with long life cycles often involve a considerable amount ofcomplex legacy code. The combination of scale and distribution challenges, and the diculty to acquire knowledgeabout large amounts of complex legacy code may make the onboarding of new developers/teams problematic. Thismay lead to extended periods of low performance.Objective: The main objective of this paper is to analyze the learning processes and performance evolutions (teamproductivity and team autonomy) of remote software development teams added late to a large-scale legacy softwareproduct development, and to propose recommendations to support the learning of remote teams.Method: We conducted a case study in Ericsson, collecting data through archival research, semi-structured interviews,and workshops. We analyzed the collected data using descriptive, inferential and graphical statistics and softqualitative analysis.Results: The results show that the productivity and autonomy of immature remote teams are on average 3.67 and2.27 times lower than the ones of mature teams, respectively. Furthermore, their performance had a steady increaseduring almost the entire first year and dropped (productivity) or got stagnated (autonomy) for a great part of the secondyear. In addition to these results, we also identified four challenges that aected the learning process and performanceevolution of immature remote teams: complexity of the product and technology stack, distance to the main source ofproduct knowledge, lack of team stability, and training expectation misalignment.Conclusion: The results indicate that scale, distribution and complex legacy code may make learning more dicultand demand a long period to achieve high performance. To support the learning of remote teams, we put forward fiverecommendations. We believe that our quantitative analysis, as well as the identified factors and recommendationscan help other companies to onboard new remote teams in large-scale legacy product development projects.

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

Context: Software projects frequently incur schedule and budget overruns. Planning and estimation are particularlychallenging in large and globally distributed projects. While software engineering researchers have beeninvestigating effort estimation for many years to help practitioners to improve their estimation processes, there is littleresearch about effort estimation in large-scale distributed agile projects.Objective: The main objective of this paper is three-fold: i) to identify how effort estimation is carried out in largescaledistributed agile projects; ii) to analyze the accuracy of the effort estimation processes in large-scale distributedagile projects; and iii) to identify the factors that impact the accuracy of effort estimates in large-scale distributed agileprojects.Method: We performed an exploratory longitudinal case study. The data collection was operationalized througharchival research and semi-structured interviews.Results: The main findings of this study are: 1) underestimation is the dominant trend in the studied case, 2) reestimationat the analysis stage improves the accuracy of the effort estimates, 3) requirements with large size/scopeincur larger effort overruns, 4) immature teams incur larger effort overruns, 5) requirements developed in multi-sitesettings incur larger effort overruns as compared to requirements developed in a collocated setting, and 6) requirementspriorities impact the accuracy of the effort estimates.Conclusion: Effort estimation is carried out at quotation and analysis stages in the studied case. It is a challengingtask involving coordination amongst many different stakeholders. Furthermore, lack of details and changes in requirements,immaturity of the newly on-boarded teams and the challenges associated with the large-scale add complexitiesin the effort estimation process.