Abstract Agile at scale introduces persistent tensions as organizations attempt to balance autonomy, coordination, and control across teams and layers. Some tensions are paradoxes, which are persistent contradictions in which both sides matter. Drawing on a qualitative case study of MarketCorp, a multinational marketplace company, we explore how paradoxes manifest in a large-scale agile context and how leaders respond. Interviews with 15 top managers and reflective conversations with 60 employees reveal three paradoxes: centralization vs. autonomy, internal vs. external focus, and product vs. project approaches. We explored two approaches for designing facilitated dialogue around paradoxes in leadership teams. The study highlights the importance of recognizing, normalizing, and collaboratively managing paradoxes and offers practical guidance for large-scale agile organizations, demonstrating that paradoxes can provide a valuable focus for continuous improvement and strengthen agile learning practices.

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

Onboarding is an important activity to integrate new employees into an organization as soon as possible, in order to support them in becoming productive. Whereas onboarding has traditionally been done primarily onsite, it is now increasingly common for new software professionals to be onboarded either fully remotely or partially remotely in hybrid settings. We ask how software professionals develop a sense of belonging through the onboarding process. Using a conceptual framework from the general onboarding literature, we report on case studies of onboarding of software professionals in three different settings on the hybrid continuum, drawing on a dataset comprising interviews with 46 informants, Slack logs, observations, and company documents. In Case 1, we focus on the onboarding of consultant developers in two divisions: in one division, the consultants work internally with the consulting organization. In the other division, the consultants are placed with clients. In Case 2, we study the onboarding of software professionals in a hybrid setting, and in Case 3, we study the onboarding of a new team of remote developers based in Portugal, who joined a company in Norway. We extend the literature on onboarding of software professionals by shedding light on how software organizations conduct onboarding in different types of hybrid settings. We extend and refine the initial conceptual model, and formalize it through the development of a series of propositions. We then discuss a number of recommendations for software organizations who wish to onboard new software professionals in different settings on the hybrid continuum.

This empirical study examines the transformation of a large-scale multinational software engineering organization into a product-oriented enterprise following Continuous Software Engineering (CSE) principles. Focusing on MarketCorp — a digital marketplace organization with distributed software development teams across multiple countries — the study explores the complex dimensions of transformation required for large-scale organizational change. Drawing on 15 interviews with MarketCorp’s top management, our findings reveal that the transformation encompasses three interconnected dimensions: organizational, platform, and cultural transformation. The organizational dimension involves structural changes and software engineering capacity redistribution; the platform dimension requires transitioning from brand-specific software platforms to a unified service-oriented model; and the cultural dimension encompasses shifts in identity, working relationships, and cross-regional software development collaboration. These dimensions are essential to enable successful CSE implementation at scale. The study contributes to empirical software engineering research by highlighting the need for organizations to proactively manage paradoxes and balance multiple competing demands across all transformation dimensions. Our findings provide practical insight for organizations undertaking similar transformations, emphasizing the importance of integrated change management approaches that consider the interdependencies between organizational structure, technology infrastructure, and cultural adaptation.

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.

Continuous Software Engineering (CSE) is widely adopted in the industry, integrating practices such as Continuous Integration and Continuous Deployment (CI/CD). Beyond technical aspects, CSE also encompasses business activities like continuous planning, budgeting, and operational processes. Coordinating these activities in large-scale product development involves multiple stakeholders, increasing complexity. This study aims to address this complexity by identifying and analyzing critical dependencies in large-scale CSE. Based on 17 semi-structured interviews conducted at two Nordic fintech companies, our preliminary findings indicate that dependencies between software teams and support functions, as well as between software teams and external entities, are the primary sources of delays and bottlenecks. As a next step, we plan to further refine our understanding of critical dependencies in large-scale CSE and explore coordination mechanisms that can better support software development teams in managing these challenges.

Abstract Context Organizations opt for continuous delivery of incremental updates to deal with uncertainty and minimize waste. However, applying continuous engineering (CSE) practices requires a continuous feedback loop with input from customers and end-users. Challenges It becomes increasingly challenging to apply traditional requirements elicitation and validation techniques with ever-shrinking software delivery cycles. At the same time, frequent deliveries generate an abundance of usage data and telemetry informing engineering teams of end-user behavior. The literature describing how practitioners work with user feedback in CSE, is limited. Objectives We aim to explore the state of practice related to utilization of user feedback in CSE. Specifically, what practices are used, how, and the shortcomings of these practices. Method We conduct a qualitative survey and report analysis from 21 interviews in 13 product development companies. We apply thematic and cross-case analysis to interpret the data. Results Based on our earlier work we suggest a conceptual model of how user feedback is utilized in CSE. We further report the identified challenges with the continuous collection and analysis of user feedback and identify implications for practice. Conclusions Companies use a combination of qualitative and quantitative methods to infer end-user preferences. At the same time, continuous collection, analysis, interpretation, and use of data in decisions are problematic. The challenges pertain to selecting the right metrics and analysis techniques, resource allocation, and difficulties in accessing vaguely defined user groups. Our advice to practitioners in CSE is to ensure sufficient resources and effort for interpretation of the feedback, which can be facilitated by telemetry dashboards.

Context Large fintech organizations are increasingly adopting agile methodologies to enhance product development capabilities. However, implementing agile at scale presents unique challenges, particularly related to collaboration essential for successful software product management (SPM). Social capital, comprising structural, cognitive, and relational dimensions, may play a crucial role in facilitating the collaboration needed to overcome these challenges. Objectives We examine the role of social capital in large-scale agile SPM, focusing on how it facilitates coordination, collaboration, and, ultimately, success, in complex, product-focused environments. Methods We employ a multi-case study approach, comprising 33 interviews, observations, and document analysis, analyzing two Scandinavian fintech companies that have adopted large-scale agile practices organized around product areas. Results Our findings, viewed through the lens of social capital theory, show that its three dimensions help explain how large-scale organizations adopting SPM manage dependencies and enable product-focused coordination. Specifically, the structural dimension helps illuminate how networks are formed; the cognitive dimension clarifies how shared understanding of product visions and development practices emerges; and the relational dimension highlights how trust is cultivated among product development actors across multiple operational levels (i.e., product team, product area, organizational, and external levels). Together, these dimensions offer insight into how agile practices are effectively implemented at scale. Conclusion Our study finds that social capital is a critical enabler of effective SPM in large-scale agile contexts. Its three dimensions support the collaboration and relational networks necessary for agility at scale. These insights suggest that fostering social capital should be prioritized in agile transformations to address the sociotechnical complexities inherent in large-scale SPM.

ABSTRACT Process debt, like technical debt, can be a source of short‐term benefits but often leads to harmful consequences in the long term for a software organization. Despite its impact, the phenomenon of process debt has not been thoroughly explored in current literature, leaving a gap in understanding how it affects and is managed within organizations. This paper addresses this gap by defining process debt, describing its occurrence, the risks of its mismanagement, and showing examples of mitigation strategies. Our study began with an exploratory phase involving semi‐structured interviews with sixteen practitioners across four international organizations, allowing us to gather diverse insights into the occurrence and management of process debt. Then, to deepen our understanding and validate our findings, we conducted a cross‐company focus group with ten additional practitioners and analyzed fifty‐eight observations and thirty‐five interviews from a longitudinal case study. The analysis of the research findings led to a definition of process debt and a novel framework. We also report on the causes, consequences, and occurrence patterns of process debt over time. We present mitigation strategies and discuss which ones need further attention for future research. Our results suggest that the debt metaphor may help companies understand how to manage and improve their processes and make process‐related decisions that are beneficial both in the short and long term.

Abstract Product teams organized into product areas are becoming more and more prevalent in large-scale agile. While such arrangements are thought to improve the development process and overall product delivery, it is still not clear how this form of organizing alleviates the coordination challenges commonly associated with large-scale agile. In this paper, we report on a case study from a product area in a large FinTech organization. Through analyzing interviews, observations, and strategic documents, we describe how organizing into a product area with vertical and horizontal teams supported inter-team coordination. Further, we describe seventeen coordination mechanisms used in the product area. Our findings have three main contributions. First, we propose that the product area represent a distinct organizational level that can support coordination in large scale development settings. Second, we found that the team types used in the product area represent different team typologies. Third, pull requests and pair programming were used as inter-team coordination mechanisms, and our findings suggest that pair programming to some extent could replace the PR mechanism to further improve product area coordination.

Abstract Large-scale agile software development is increasingly being organized with product management. Although product management is familiar to software engineering, we need research-based knowledge about organizing product management in an agile development context. This study focuses on product management challenges and configurations in a Nordic fintech organization with 10,000 employees. We conducted 19 interviews with participants involved in core product management activities. The study identifies ten key factors that hinder product management performance in a large-scale agile product company. Further, we present six product management configurations used in the fintech organization. The most suitable setup depends on the product lifecycle stage, product size, and development team setup. Our summary of the product management configurations and challenges can guide software product managers working in large-scale agile companies.

Pair programming (PP) has been a widespread practice for decades and is known for facilitating knowledge exchange and improving the quality of software. Many agilists advocated the importance of collocation, face-to-face interaction, and physical artifacts incorporated in the shared workspace when pairing. After a long period of forced work-from-home, many knowledge workers prefer to work remotely two or three days per week, which is affecting practices such as PP. In this revelatory single-case study, we aimed to understand how PP is practiced during hybrid work when team members alternate between on-site days and working from home. We collected qualitative and quantitative data through 11 semi-structured interviews, observations, feedback sessions, and self-reported surveys. The interviewees were members of an agile software development team in a Norwegian fintech company. The results presented in this paper indicate that PP can be practiced through on-site, remote, and mixed sessions, where the mixed mode seems to be the least advantageous. The findings highlight the importance of adapting the work environment to suit individual work mode preferences when it comes to PP. In the future, we will build on these findings to explore PP in other teams and organizations practicing hybrid work.

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.

Abstract Context Responding to change and continuously improving processes, practices, and products are core to agile software development. It is no different in large-scale agile, where multiple software development teams need to respond both to changes in their external environments and to changes within the organization. Objective With this study, we aim to advance knowledge on coordination in large-scale agile by developing a model of the types of organizational changes that influence coordination mechanisms. Method We conducted a longitudinal case study in a growing large-scale agile organization, focusing on how external and internal changes impact coordination over time. We collected our data through 62 days of fieldwork across one and a half years. We conducted 37 interviews, observed 118 meetings at all organizational levels, collected supplementary material such as chat logs and presentations, and analyzed the data using thematic analysis. Results Our findings demonstrate how external events, such as onboarding new clients, and internal events, such as changes in the team organization, influence coordination mechanisms in the large-scale software development program. We find that external and internal change events lead to the introduction of new coordination mechanisms, or the adjustment of existing ones. Further, we find that continuous scaling requires continuous change and adjustment. Finally, we find that having the right mechanisms in place at the right time strengthens resilience and the ability to cope with change in coordination needs in complex large-scale environments. Conclusions Our findings are summarized in an empirically based model that provides a practical approach to analyzing change, aimed at supporting both researchers and practitioners dealing with change in coordination mechanisms in large-scale agile development contexts.

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.

In large-scale agile software development, many teams work together to achieve overarching project goals. The more teams, the greater the coordination requirements. Despite the growing popularity of large-scale agile, inter-team coordination is challenging to practice and research. We conducted a case study over 1.5 years in a large-scale software development firm to better understand which inter-team coordination mechanisms are used in large-scale agile and how they support inter-team coordination. Based on a thematic analysis of 31 interviews, 113 hours of observations, and supplemental material, we identified 27 inter-team coordination mechanisms. From this, we offer the following contributions. First, we propose a taxonomy of inter-team coordination with three categories: coordination meetings, such as communities of practice, inter-team stand-ups, and retrospectives; coordination roles, such as the program architects and the platform team; and coordination tools and artefacts, such as Slack and JIRA as well as inter-team task boards, product backlogs, and roadmaps. Second, the coordination mechanisms displayed combinations of four key characteristics, technical, organizational, physical, and social (TOPS), which form the basis of the TOPS framework to capture the multifaceted characteristics of coordination mechanisms.Technicalrelates to the software product and/or technical tools supporting software development.Organizationalpertains to the structural aspects of the organization.Physicalrefers to tangible or spatial characteristics.Socialcaptures interpersonal and community-based characteristics. Finally, the taxonomy and the TOPS framework provide a knowledge base and a structured approach for researchers to study as well as for software practitioners to understand and improve inter-team coordination in large-scale agile.

Abstract Effective coordination is the key to successful agile teams. They rely on frequent interactions and mutual adjustment to manage dependencies between activities, which traditionally has been solved by co-locating the team. As the world is adjusting to post-covid work-life, companies are moving towards a work-from-anywhere approach where workers can choose to what degree they want to work from home or office. However, little is known about coordination in such a context. We report findings on developers’ emerging strategies when working-from-anywhere, from an exploratory case study in Norway, including eight interviews. Our study shows that new strategies for mutual adjustment emerged as teams experimented with different tools and approaches: developers chose tasks according to location, tasks with vague requirements are performed collocated while individual tasks requiring focus are best performed at home; large meetings are virtual, preserving co-located time for collaborative tasks; using virtual rooms to maintain unscheduled meetings as they communicate mental presence to teammates, lowering the threshold for intra-team unscheduled talks. The strategies can help organizations create a productive and effective environment for developers.

Abstract The product manager (PM) role is well established in leading technological companies, such as Google, Amazon, Microsoft, and Facebook. PMs are responsible for integrating technical, design, and business perspectives when developing software products and product portfolios. In agile methods (e.g., Scrum), similar responsibilities are linked to the Product Owner (PO) role. In contrast, in large-scale agile, one can find both Product Owners and product managers who sometimes compete. Despite the widespread adoption of the product manager role, the attention toward it in the agile academic community has been surprisingly limited. In this multiple case study, we analyzed 17 interviews with 11 product managers from four agile companies. We found that the PMs facilitated continuous product experimentation and innovation, supported the product teams, and engaged in additional activities to achieve optimal product development. Our summary of the product management activities can guide product managers working in agile companies.

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.

Abstract Inter-team coordination in large-scale software development can be challenging when relying on agile development methods that emphasize iterative and frequent delivery in autonomous teams. Previous research has introduced the concept of coordination strategies, which refer to a set of coordination mechanisms to manage dependencies. We report on a case study in a large-scale agile development program with 16 development teams. Through interviews, meeting observations, and supplemental document analyses, we explore the challenges to inter-team coordination and how dependencies are managed. We found four coordination strategies: 1) aligning autonomous teams, 2) maintaining overview in the large-scale setting, 3) managing prioritizations, and 4) managing architecture and technical dependencies. This study extends previous research on coordination strategies within teams to the inter-team level. We propose that large-scale organizations can use coordination strategies to understand how they coordinate across teams and manage their unique coordination situation.

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.

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

Today, product development organizations are adopting agile methods in units outside the software development unit, such as in sales, market, legal, operations working with the customer. This broader adoption of agile methods has been labeled large-scale agile transformation and is considered a particular type of organizational change, originating in the software development units. So far, there is little research-based advice on conducting such transformations. Aiming to contribute towards providing relevant research advice on large-scale agile transformation, we apply a research-based framework for evaluating organizational agility on a product development program in a maritime service provider organization. We found that doing a large-scale agile transformation involves many significant challenges, such as having a shared understanding of the problem, getting access to users, and getting commitment to change that needs to be done. In order to overcome such challenges, we discuss the need for a holistic and integrated approach to agile transformation involving all the units linked to software development.

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.

Given the relevance of coordination in the field of global software engineering, this work was carried out to further understand coordination mechanisms. Specifically, we investigated meetings and the collaboration tool Slack. We conducted a longitudinal case study using a mixed-methods approach with surveys, observations, interviews, and chat logs. Our quantitative results show that employees in global projects spend 7 h 45 min per week on average in scheduled meetings and 8 h 54 min in unscheduled meetings. Furthermore, distributed teams were significantly larger than co-located teams, and people working in distributed teams spent somewhat more time in meetings per day. We found that low availability of key people, absence of organizational support for unscheduled meetings and unbalanced activity from team members in meetings and on Slack were barriers for effective coordination across sites. The positive aspects of using collaboration tools in distributed teams were increased team awareness and informal communication and reduced the need for e-mail. Our study emphasizes the importance of reflecting on how global software engineering teams use meetings and collaboration tools to coordinate. We provide practical advice for conducting better meetings and give suggestions for more efficient use of collaboration tools in global projects.

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.

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.

Abstract In agile software development, a core responsibility of the product owner (PO) is to communicate business needs to the development team. In large-scale agile software development projects, many teams work toward an overall outcome, but they also need to manage interdependencies and coordinate efficiently. In such settings, POs need to coordinate knowledge about project status and goal attainment both within and across the development teams. Previous research has shown that the PO assumes a wide set of roles. Still, our knowledge about how POs coordinate amongst themselves and with their teams in large-scale agile is limited. In this case study, we explore PO coordination in a large-scale development program through the theoretical lens of Relational Coordination Theory. Our findings suggest that (1) coordination varies depending on the context of each PO, (2) a focus on achieving high-quality communication changes coordination over time, and (3) unscheduled coordination enables of high-quality communication.

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.

Agile development methods were believed to best suit small, co-located teams, but the success in small teams has inspired use in large and very large-scale software development. However, fundamental assumptions of agile development are challenged when applying the methods at a very large scale. An interpretative revelatory case study on one of the largest software development programmes in Norway shows how agile methods were adapted and complemented with practices from traditional methods to handle the scale. The programme ran over four years with 12 co-located development teams and a total of 175 people involved. The case study was conducted retrospectively using group interviews with 24 participants and documents. Findings on key challenging areas are reported: customer involvement, software architecture, and inter-team coordination. The revelatory study also suggests refinements of a research agenda for very large-scale agile development.

In order to be responsible stewards of other people's data, cloud providers must be accountable for their data handling practices. The potential long provider chains in cloud computing introduces additional accountability challenges, and this paper examines requirements which must be fulfilled to achieve an accountability-based approach.

The daily stand-up meeting is a widely used practice. However, what is more uncertain is how valuable the practice is to team members. We invited professional developers of a programming forum to a survey and obtained 221 responses. Results show that the daily stand-up meeting was used by 87% of those who employ agile methods. We found that even though the respondents on average were neutral towards the practice, the majority were either positive or negative. Junior developers were most positive and senior developers and members of large teams most negative. We argue that the value of the practice should be evaluated according to the team needs. Further, more work is needed to understand why senior developers do not perceive the meetings as valuable and how to apply the practice successfully in large teams.

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.

Software developers and testers have to work together to achieve the goals of software development projects. In globally distributed software projects the development and testing are often scattered across multiple locations forming virtual teams. Further, the distributed projects are so complex that none of team members can possibly possess all the knowledge about the project individually. During testing in such teams, developers and testers need to coordinate and communicate frequently. However, coordination is affected by the availability of the project information, which is distributed among different project members and organizational structures. Many companies are facing decisions about how to apply agile methods in their distributed projects. These companies are often motivated by the opportunities of solving the coordination and communication difficulties associated with global software development. In this paper we investigate the communication between testers and developers in two teams from two software companies performing continuous agile testing in a distributed setting. We describe four communication practices used by the team: handover through issue tracker system, formal meetings, written communication and coordination by mutual adjustment. We also discuss communication between testers and developers in collocated versus distributed testers and developers. We have found that early participation of the testers is very important to the success of the handover between testers and developers. The communication between developers and testers is not sufficiently effective through written communication and that it changes depending on the type of the tasks and experience of the testers.

Shared knowledge allows virtual teams to collaborate more effectively. Shared knowledge in teams, hereafter called team knowledge, must be established and maintained. This is a key enabler for agile development in a distributed context. Hence, organizations may benefit from efforts to ensure sufficient levels of team knowledge. Such efforts may include different measures, such as project kick-offs, frequent visits across locations, knowledge sharing tools and practices. However, team knowledge includes many types of knowledge, with different impacts on the team's work. This paper outlines a framework for conceptualizing the breadth of team knowledge relevant for virtual software teams. With the help of this framework, organizations can think more strategically about how to improve team knowledge -- for example the planning of kick-offs, what to focus on in face-to-face meetings and how the team members work together on a day-to-day basis. The framework may also be used to assist in planning team composition, for example based on individuals' knowledge and the overlap with other team members' knowledge. The framework uses four broad categories of team knowledge: task-related, team-related, process-related and goal-related. Beneath these four categories the framework details and describes more concrete knowledge types. We also provide examples from software practice for each knowledge type.

Virtual teams, with a high level of interdependence and cooperation among team members, are one of the building blocks of successful global software organizations. Shared team knowledge is vital for effective collaboration in virtual teams. Hence, it makes sense for organizations to put in place efforts to ensure that teams have a sufficient level of shared knowledge. A successful agile virtual team needs to have shared knowledge on the tasks and how to do them, who knows what in the team, the development process, and the goals of the team. While shared knowledge helps on communication and collaboration, virtual teams meet several challenges in the form of values and norms, lack of face-to-face communication, time-zone differences, and difficulties in building and maintaining trust. We describe and discuss how a framework for establishing shared knowledge was applied to a global virtual agile team in a Product Centre at DNV GL -- an international provider of software for a safer, smarter and greener future in the energy, process and maritime industries. The whole group of 22 met face to face once a year, and we describe how they in one such team gathering worked on creating shared understanding about the task, the team, the process and goals of the virtual team.

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. A successful agile virtual 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 one 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.

In globally distributed software projects the testing expertise may be scattered across multiple locations. We describe and discuss a globally distributed agile project at DNV GL Software, a multinational provider of software for a safer, smarter and greener future in the energy, process and maritime industries. DNV GL Software is headquartered in Norway. The project is distributed across two locations with 12 team members in Norway and three testers in China. In a distributed agile team with little overlap in working hours the challenge is to coordinate tasks and test activities in a way that makes coordination and communication efficient. DNV GL Software believes in including the remote testers as part of the agile team, enabling self-managing, cross-functional virtual teams that are capable of taking the full responsibility for implementing and verifying one entire feature. To support the communication between testers in China and the rest of the team in Norway, the team needs a shared understanding of the goal of a release and how to collaborate. We conducted interviews with the team and representatives from different roles in the organization, and we performed retrospectives with the team. In this article we describe how continuous testing based on continuous and frequent feedback ensures knowledge sharing and safeguarding the quality of the system under development. We found the following enablers for a successful virtual agile team: coordination by mutual adjustment, dedicated testers and low turnover, shifting working hours, and self-management and autonomy. Non-technical factors, such as socio-technical and organizational factors, have a significant influence on the way software testing is performed in an agile virtual team. To be successful the organization needs to invest in bringing the remote testers closer to the rest of the team, as part of the virtual team.

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.

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.

Ever since the agile manifesto was created in 2001, the research community has devoted a great deal of attention to agile software development. This article examines publications and citations to illustrate how the research on agile has progressed in the 10 years following the articulation of the manifesto. Specifically, we delineate the conceptual structure underlying agile scholarship by performing an analysis of authors who have made notable contributions to the field. Further, we summarize prior research and introduce contributions in this special issue on agile software development. We conclude by discussing directions for future research and urging agile researchers to embrace a theory-based approach in their scholarship.

Although Scrum is an important topic in software engineering and information systems, few longitudinal industrial studies have investigated the effects of Scrum on software quality, in terms of defects and defect density, and the quality assurance process. In this paper we report on a longitudinal study in which we have followed a project over a three-year period. We compared software quality assurance processes and software defects of the project between a 17-month phase with a plan-driven process, followed by a 20-month phase with Scrum. The results of the study did not show a significant reduction of defect densities or changes of defect profiles after Scrum was used. However, the iterative nature of Scrum resulted in constant system and acceptance testing and related defect fixing, which made the development process more efficient in terms of fewer surprises and better control of software quality and release date. In addition, software quality and knowledge sharing got more focus when using Scrum. However, Scrum put more stress and time pressure on the developers, and made them reluctant to perform certain tasks for later maintenance, such as refactoring.

Many software companies disseminate process knowledge through electronic process guides. A common problem with such guides is that they are not used. Through a case study, we investigated how participation in creating an electronic process guide, through process workshops, influenced the use of the guide. We studied developer and project manager usage with respect to three factors: frequency of use, used functionality, and reported advantages and disadvantages. We collected data from three rounds of interviews and 19 months of usage logs in a longitudinal study in a medium-size software company. Employees who participated in process workshops showed a higher degree of usage, used a larger number of functions, and expressed more advantages and disadvantages than those not involved. Our study suggests that employee participation has a long-term positive effect on electronic process guide usage.