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.

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.

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.

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.

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.

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