Abstract Hybrid work has become the norm post pandemic, yet organizing it effectively in agile software engineering requires understanding how individual and contextual factors shape preferences and behaviors. This study surveyed 65 agile practitioners to explore these influences. Respondents generally preferred flexible office attendance policies, but not full-time remote work. Larger teams expressed interest in agreed on presence at the office, while small or medium size teams leaned slightly more toward individual choice. Social interaction was a strong reason to come to the office, and most respondents viewed in-person meetings as highly beneficial for social and problem-solving activities. In virtual meetings, camera use was guided mainly by social presence and visibility, while multitasking activities were mostly meeting-supportive and work related, with managers and agile leaders reporting slightly higher levels of multitasking and significantly higher levels of camera use.

Abstract Although agile teams aim to maximize value, few studies have examined how teams collectively develop an understanding of value beyond the Product Owner’s perspective. While Product Owners often define value priorities, team members’ understanding of how daily work connects to business goals and broader organizational context often remains limited. To address this gap, this study introduces and evaluates a value retrospective process , a structured reflection on cost and value. Informed by Design Science Research principles, the process was jointly designed by the first author, acting as Agile Lead, and the company’s finance function. The process was implemented across 61 cross-functional teams in a large Finnish conglomerate, and iteratively refined over two years. This study examines process design, organizational implementation, and participant experiences using semi-structured interviews. The findings show that participants initially perceived retrospectives as potentially judgmental or audit-like, but over time, these perceptions shifted toward psychologically safe, constructive dialogue. Value retrospectives supported increased awareness of costs and value, strengthened team-sponsor alignment, and prompted concrete improvement actions. This study contributes an empirically grounded process model and insights into how structured value reflection can support learning and alignment in agile teams.

Abstract Team autonomy—the extent to which teams can make decisions—is a central tenet of agile development. When scaling agile, technical and coordination challenges necessitate restricting autonomy. While greater autonomy is often considered better, the reasons for, and the extent to which, autonomy is, or should be, restricted in large-scale agile development remain poorly understood. In this paper, we address this gap by analyzing large-scale agile frameworks using decision-making theory. Applying inductive thematic analysis to the primary documents of scaling frameworks, we identify and categorize their decisions and related decision-making elements by decision-maker, decision type, decision-making style, decision timing, and affected artifacts. This research contributes to decision-making knowledge by providing a systematic categorization of decision points in large-scale agile development. For practitioners, the resulting classification helps identify key decision points, define roles and responsibilities, and plan team autonomy in large-scale agile.

Background: Hybrid work, which combines remote and office work, has become common after the Covid-19 pandemic. While many software companies embrace hybrid work to retain talent, this shift challenges agile software development, which values in-person collaboration. However, adaptation is central to agility, so agile companies are adjusting to their evolving needs, including the rise of hybrid work. Aims: This study explores how different types of companies organize hybrid work in agile software development to fit their unique organizational contexts. Method: We conducted a comparative multiple case study based on 39 semi-structured interviews with developers, product owners, specialists, and managers from two companies. We studied two agile software development units at the Finnish R&D site of Ericsson, a mature global telecommunications company, and one unit at Kempower, a young Finnish industrial company. Results: The study found that hybrid work guidelines, infrastructures, events, and communities in agile software development varied significantly across the units, yet employees in each unit generally reported satisfaction with their arrangements. The approaches were shaped by multiple factors, e.g., how team members were dispersed geographically, whether collaboration was mainly internal or included external partners, and the company's maturity. Conclusions: Our findings suggest that there is no one-size-fits-all approach for agile software development in a hybrid work environment. Instead, the successful adoption of hybrid work requires context awareness.

Abstract The Agile Manifesto emphasizes individuals and interactions over processes and tools. However, after the COVID-19 pandemic, interaction in software development changed, and companies are trying to find new practices in the hybrid environment. Hybrid work research points to the benefits for the individual, whereas companies have begun to form new rules and policies to get employees back to the office. To find a balance benefiting all, companies need to find new ways to connect and communicate. This paper explores how hybrid work impacts the sense of belonging in agile software development. We conducted interviews (N = 38) and a workshop (N = 15) with professionals from three case organizations. Our thematic analysis identifies key factors influencing belonging at the individual, team, and organizational levels. Our findings underline that continuous, conscious, and visible actions are needed at all levels to foster a sense of belonging. As hybrid work reduces spontaneous and random encounters, maintaining a sense of belonging requires planned efforts to recreate the informal interactions that once happened naturally.

Abstract The global shortage of highly skilled employees has created a need for a more efficient onboarding process in software development companies. The experienced onboarding efficiency affects the new employee’s willingness to stay within the company and the efficiency of their work. Our case company transferred to a team-based organization structure, where agile teams were given high autonomy. Supervisor responsibilities were divided among different roles, such as people coaches and a lead team. We studied the onboarding process through a survey that was answered by 39 persons, as well as 18 interviews to gather details from the onboarding process. To validate the findings, workshops, and presentations were organized in the case company. We found that mentoring was experienced as the most important form of onboarding in the case company. The biggest challenges were lack of transparency, insufficient material availability, and lack of documentation. As solutions were suggested: a shared repository of onboarding materials, checklists for teams and mentors for onboarding new employees efficiently, and collecting team-specific materials to a single location.

Abstract As agile software development is increasingly adopted in the software industry, the popularity of scaling frameworks supporting adoption in large development contexts is increasing rapidly. While several such frameworks exist, the most popular one at the moment is the Scaled Agile Framework (SAFe). Despite its popularity, there exists limited research on its usage and adoption. In this paper, we contribute by presenting a single case study in a large financial organization, studying the transformation reasons, transformation process, as well as the benefits, and challenges of SAFe adoption. We conducted 24 semi-structured interviews with 27 interviewees and analyzed the transcribed interviews using open and axial coding. We identified 17 reasons for SAFe adoption in this organization, of which the most salient ones were to shorten the time to market, improve collaboration, and use a well-described and comprehensive framework. An industry context-specific reason was the popularity of SAFe in the financial sector. The transformation in the case organization was top-down and proceeded step-wise. The most significant activities during the transformation were piloting, education, coaching, and the forming of agile release trains. Our case also implemented "Scrum tours" to increase the understanding of lean and agile principles. We identified 13 benefits of SAFe, of which improved collaboration, transparency, and shorter time to market were considered the most important. We identified a total of 16 challenges, with the most salient one being aligning the release trains with value streams. Failing with this led to cross-release train dependencies and coordination overhead, inhibiting agility. Further, the organization did not get rid of projects and project managers, which led to priority clashes and coordination overhead.

Background: The adoption of agile scaling frameworks has become increasingly prevalent in the software industry as organizations seek to extend the use of agile to large and complex projects. The frameworks claim to provide the necessary structure and guidance for scaling agile practices across multiple teams and domains. Despite their growing popularity, the challenges of adopting the frameworks are poorly understood. Aims: In this study, we analyze the experienced challenges related to adopting agile scaling frameworks to understand whether they are different for the different frameworks or between industries or roles within the adopting organization. Method: We conducted a survey targeting software practitioners with experience adopting agile scaling frameworks. We received 204 valid responses, representing ten frameworks adopted in 26 countries and six continents. Results: The most salient challenge, regardless of scaling framework, industry, or role, was organizational politics. Across frameworks, the challenge of forming agile teams emerged as the second most significant and change resistance as the third. We found significant differences in the challenges experienced by organizations based on their chosen framework and significant differences in the challenges between different industries and organizational roles, highlighting the importance of context when adopting agile scaling frameworks. Conclusions: This study provides the first quantitative assessment of the challenges of adopting specific agile scaling frameworks in various contexts. By comparing the challenges associated with different frameworks, industries, and organizational roles, other organizations can better understand the most significant obstacles they may face and improve their framework fit to mitigate them. Future studies could build on these findings to provide additional insights and recommendations for organizations seeking to adopt agile scaling frameworks, including identifying strategies for overcoming common challenges and improving the overall effectiveness of these frameworks in a diverse range of contexts.

Abstract In a large-scale agile environment, a Product Owner receives requests from many different directions. Freedom to influence the direction of the product and push ideas forward sometimes requires saying “no”. This is a case study that has been made by interviewing several Product Owners or people working in a Product Owner type of role. The case company, which is a large financial organization, encourages Product Owners to take responsibility by valuing an entrepreneurial mindset. This research examines whether it is possible to exercise entrepreneurial freedom in the Product Owner’s work, and how much freedom the Product Owner has in the direction of the product, i.e. whether they have the freedom to say “no”. A total of 18 Product Owners, and those in similar roles, as well as managers from the case company, were interviewed. The findings show that the role of the Product Owner needs to be clarified in order to have more freedom to act. Prioritizing is difficult and saying “no” is more difficult than desired. Product Owners find the urge for an entrepreneurial attitude understandable, however, it does not seem to fit perfectly into the everyday work life of a Product Owner in a large-scale set-up. When the understanding of the role deepens, Product Owners could have greater freedom to make their products successful.

Technical excellence is a nebulous term in agile software development. This vagueness is risky because it may lead to misunderstandings and to agile implementations that may overlook a key principle of agile development. This study investigates how agile practitioners interpret the concept of technical excellence brought up in Principle 9 of the Agile manifesto. Moreover, we investigate how agile practitioners put the concept into practice and what conditions facilitate putting technical excellence into practice. We conducted semi-structured interviews with twenty agile practitioners, coded the data inductively, and performed two sessions to validate the emerging findings. We find that technical excellence is first and foremost a mindset that is underpinned by continuous attention to sustainable code, continuous learning, and teamwork. Fostering technical excellence requires the adoption of design and development practices, such as continuous architecting, and is supported by continuous learning. We also identify three enabling conditions for technical excellence: Leadership support, customer buy-in, and psychological safety. These enablers provide teams with leeway to nurture their pursuit of technical excellence. Our findings highlight the key role of people-based strategies in promoting technical excellence in agile software development. They show that the attainment of technical excellence does not only involve technical practices. On the contrary, it relies on social and organizational support and, most importantly, a mindset.

“Technical excellence” is a nebulous term in agile software development. This vagueness is risky, as it creates a gap in the understanding of agile that may have consequences on how software development practitioners operate. Technical excellence is the only reference to quality in the agile manifesto. Hence, it is fundamental to understand how agile software development practitioners both interpret and implement it. We conducted interviews with twenty agile practitioners about their understanding of the term “technical excellence” and how they approach the task of fostering it. To validate the findings, two focus group meetings were conducted after the interviews and the analysis of the data were completed. We found that the configuration of technical excellence is made of four traits: (1) software craftsmanship; (2) software quality (3) mindset for excellence; and (4) consistency with good software engineering practices. Fostering technical excellence is a continuous endeavor. Further, we identified three key principles that were commonly cited as essential to implementing technical excellence, namely: 1) continuous learning; 2) continuous improvement; and 3) control of excellence. Based on our findings, we present several recommendations for software development teams seeking to better realize the goal of technical excellence in their agile implementation.

Background: The benefits of agile methods in small, co-located projects have inspired their adoption in large firms and projects. Scaling frameworks, such as Large-Scale Scrum (LeSS) and the Scaled Agile Framework (SAFe), have been proposed by practitioners to scale agile to larger contexts, and become rather widely adopted in the industry. Despite the popularity of the frameworks, the knowledge on the reasons, expected benefits, and satisfaction of organizations adopting them is still limited.

With an increasing number of companies choosing to implement Scrum, the role of the Scrum Master seems to change from how it is described in the Scrum Guide. Companies have challenges in hiring skilled Scrum Masters, and in seeing the value of this role after the agile adoption phase is over. This paper aspires to understand the value of Scrum masters by investigating the role in a case company, Nordea, while studying their experiment of assigning a single Scrum Master to multiple teams. We collected data by eleven semi-structured interviews and six observation sessions. Our findings show that the real value of a Scrum Master is based on his or her ability to understand people. The Scrum Master contributes to team dynamics and well-being, helps the team to connect and coordinate, and challenges the team to higher performance. Finally, assigning an experienced Scrum Master to two teams can lead to improved knowledge-sharing, cooperation and alignment. Assigning more than two teams to a single Scrum master may put the value this role provides at risk.

Abstract During the last two decades, turbulent business environments tempted firms to adopt agile methods to cope with the ever-changing customer demands. The success of agile methods in small and co-located teams inspired companies to apply them to large-scale endeavors. Agile scaling frameworks, such as the Scaled Agile Framework (SAFe), have been proposed by practitioners to scale agile practices to large projects and enterprises. Companies are increasingly taking these frameworks into use. However, the number of quantitative empirical studies assessing the benefits and challenges of adopting the agile scaling frameworks is still limited. This paper starts filling in this gap by presenting the results from a survey of 100 industry participants around the world on their perception of the benefits and challenges of adopting the SAFe framework. Our results show that the SAFe adoption improves transparency, as well as collaboration and dependency management between agile teams. The most commonly mentioned challenges of the SAFe adoption are organizational politics, difficulties in establishing an agile mindset, change resistance, and team formation challenges.

Abstract Over the past decade, agile methods have become the favored choice for projects undertaken in rapidly changing environments. The success of agile methods in small, co-located projects has inspired companies to apply them in larger projects. Agile scaling frameworks, such as Large Scale Scrum and Scaled Agile Framework, have been invented by practitioners to scale agile to large projects and organizations. Given the importance of agile scaling frameworks, research on those frameworks is still limited. This paper presents our findings from an empirical survey answered by the methodologists of 15 agile scaling frameworks. We explored (i) framework evolution, (ii) main reasons behind their creation, (iii) benefits, and (iv) challenges of adopting these frameworks. The most common reasons behind creating the frameworks were improving the organization’s agility and collaboration between agile teams. The most commonly claimed benefits included enabling frequent deliveries and enhancing employee satisfaction, motivation, and engagement. The most mentioned challenges were using frameworks as cooking recipes instead of focusing on changing people’s culture and mindset.

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 The Scaled Agile Framework (SAFe) is currently the most widely adopted framework for scaling agile in the software intensive industry. Despite this, there exists very little scientific research on the transformation process, as well as on the challenges and success factors of using SAFe in large-scale organizations. To start filling in this research gap, we conducted a case study by investigating the formation of agile release trains and the related challenges in a large financial organization adopting SAFe. We conducted 24 interviews with 27 interviewees, after which we analyzed the transcribed interviews using open and axial coding. The SAFe transformation started by forming a pilot train with teams that already had experience in agile practices. The success of the pilot led to the launching of new release trains. The forming of new agile release trains was challenging due to politics, difficulties in identifying the value streams, and the avoidance of a radical restructuring of the organization. These challenges led to opting for an organic way of transformation. Management organized several workshops to identify stakeholders for the second train. This was followed by team members choosing their teams based on skills and interests. The last two trains were formed using Lego workshops. The most significant challenges after forming the release trains at the case organization were struggles with existing projects and challenges due to inter-train dependencies.

Modern release engineering practices provide multiple benefits for software companies, but organizations have struggled when trying to adopt the most advanced practices, such as continuous delivery. It is not known in which contexts the most advanced practices are applicable and what can be achieved by adopting them. In this study, we discuss the effect of the organizational context on adopted release engineering practices and what outcomes are achieved with the practices. We study two organizational contexts: the startup and the large mature company context. The effect of the product context is mitigated by studying two case organizations with similar products, a rare research opportunity. We performed 18 interviews with various roles in the case organizations. The number of production environments, the number of customers, the control over the production environment, the available resources, the organization size and the distribution of the organization affected the release engineering practices and the ability to release frequently. Having less internal verification and more customer verification enabled fast feedback and customer experimentation in the startup context, but increased the number of production defects. However, having more internal verification in the large mature company context surprisingly did not prevent production defects. The organizational context had a large effect on how achievable modern release engineering practices, such as continuous delivery, were. In the startup context, the lack of resources was the main factor hindering the improvement of release engineering practices, while in the large mature company context, the number of stakeholders and products were the main factors.

Many large organizations are adopting agile software development as part of their continuous push towards higher flexibility and shorter lead times, yet few reports on large-scale agile transformations are available in the literature. In this paper we report how Ericsson introduced agile in a new R&D product development program developing a XaaS platform and a related set of services, while simultaneously scaling it up aggressively. The overarching goal for the R&D organization, distributed to five sites at two continents, was to achieve continuous feature delivery. This single case study is based on 45 semi-structured interviews during visits at four sites, and five observation sessions at three sites. We describe how the organization experimented with different set-ups for their tens of agile teams aiming for rapid end-to-end development: from component-based virtual teams to totally cross-functional, cross-component, cross-site teams. Moreover, we discuss the challenges the organization faced and how they mitigated them on their journey towards continuous and rapid software engineering. We present four lessons learned for large-scale agile transformations: 1) consider using an experimental approach to transformation, 2) consider implementing the transformation step-wise in complex large-scale settings, 3) team inter-changeability can be limited in a complex large-scale product — specialization might be needed, and 4) not using a common agile framework for the whole organization, in combination with insufficient common trainings and coaching may lead to a lack of common direction in the agile implementation. Further in-depth case studies on large-scale agile transformations, on customizing agile to large-scale settings, as well as on the use of scaling frameworks are needed.

Large software development organizations adopting agile methods need solutions and models to help scale agile to fit their needs. During recent years, several frameworks for scaling agile have been created by consultants, including the Scaled Agile Framework (SAFe), Large-scale Scrum (LeSS) and Disciplined Agile Delivery (DAD). However, research on how these frameworks are adopted in practice is seriously lacking. In this paper we describe how Comptel, a globally distributed software development company, adopted the SAFe framework in two business lines. Based on eleven interviews we present why and how the organization adopted SAFe, and discuss related challenges and success factors. The comparison of the two adoptions showed that investing in SAFe trainings, engaging people and change agents, hiring a coach, investing in a full-time release train engineer, preparing well for the first planning event and continuously improving and customizing SAFe led to good results.

In a large organization, informal communication and simple backlogs are not sufficient for the management of requirements and development work. Many large organizations are struggling to successfully adopt agile methods, but there is still little scientific knowledge on requirements management in large-scale agile development organizations. We present an in-depth study of an Ericsson telecommunications node development organization which employs a large scale agile method to develop telecommunications system software. We describe how the requirements flow from strategy to release, and related benefits and problems. Data was collected by 43 interviews, which were analyzed qualitatively. The requirements management was done in three different processes, each of which had a different process model, purpose and planning horizon. The release project management process was plan-driven, feature development process was continuous and implementation management process was agile. The perceived benefits included reduced development lead time, increased flexibility, increased planning efficiency, increased developer motivation and improved communication effectiveness. The recognized problems included difficulties in balancing planning effort, overcommitment, insufficient understanding of the development team autonomy, defining the product owner role, balancing team specialization, organizing system-level work and growing technical debt. The study indicates that agile development methods can be successfully employed in organizations where the higher level planning processes are not agile. Combining agile methods with a flexible feature development process can bring many benefits, but large-scale software development seems to require specialist roles and significant coordination effort.

Context: Continuous delivery (CD) is a development practice for decreasing the time-to-market by keeping software releasable all the time. Adopting CD within a stage-gate managed development process might be useful, although scientific evidence of such adoption is not available. In a stage-gate process, new releases pass through stages and gates protect low-quality output from progressing. Large organizations with stage-gate processes are often hierarchical and the adoption can be either top-down, driven by the management, or bottom-up, driven by the development unit.

We present a case study on scaling Scrum in a large globally distributed software development project at Nokia, a global telecommunications company. We discuss how the case project scaled Scrum while growing from two collocated Scrum teams to 20 teams located in four countries and employing a total of 170 persons. Moreover, we report scaling challenges the case project faced during this 2,5 year journey. We gathered data by 19 semi-structured interviews of project personnel from two sites, interviewees comprising different roles including managers, architects, product owners, developers and testers. The project was highly successful from the business point of view, as agile enabled fast response to customer requirements. However, the project faced significant challenges in scaling Scrum despite attempts at applying the Large-scale Scrum (LeSS) framework. The organization experimented with different ways of implementing scaling practices like implementing common sprint planning meetings, Scrum-of-Scrums meetings, common demos and common retrospectives, as well as scaling the Product Owner role. We conclude the paper by reflecting on the scaling approach used in the case organization in contrast to the LeSS framework.

Agile methods have become an appealing alternative for companies striving to improve their performance, but the methods were originally designed for small and individual teams. This creates unique challenges when introducing agile at scale, when development teams must synchronize their activities, and there might be a need to interface with other organizational units. In this paper we present a systematic literature review on how agile methods and lean software development has been adopted at scale, focusing on reported challenges and success factors in the transformation. We conducted a systematic literature review of industrial large-scale agile transformations. Our keyword search found 1875 papers. We included 52 publications describing 42 industrial cases presenting the process of taking large-scale agile development into use. Almost 90% of the included papers were experience reports, indicating a lack of sound academic research on the topic. We identified 35 reported challenges grouped into nine categories, and 29 success factors, grouped into eleven categories. The most salient success factor categories were management support, choosing and customizing the agile model, training and coaching, and mindset and alignment.

In this paper we propose a new framework to assess survivability of software projects accounting for media capability details as introduced in Media Synchronicity Theory (MST). Specifically, we add to our global engineering framework the assessment of the impact of inadequate conveyance and convergence available in the communication infrastructure selected to be used by the project, on the system ability to recover from project disasters. We propose an analytical model to assess how the project recovers from project disasters related to process and communication failures. Our model is based on media synchronicity theory to account for how information exchange impacts recovery. Then, using the proposed model we evaluate how different interventions impact communication effectiveness. Finally, we parameterize and instantiate the proposed survivability model based on a data gathering campaign comprising thirty surveys collected from senior global software development experts at ICGSE'2014 and GSD'2015.

We describe an experience in teaching global software engineering (GSE) using distributed Scrum augmented with industrial best practices. Our unique instructional technique had students work in both same-site and cross-site teams to contrast the two modes of working. The course was a collaboration between Aalto University, Finland and University of Victoria, Canada. Fifteen Canadian and eight Finnish students worked on a single large project, divided into four teams, working on interdependent user stories as negotiated with the industrial product owner located in Finland. Half way through the course, we changed the teams so each student worked in both a local and a distributed team. We studied student learning using a mixed-method approach including 14 post-course interviews, pre-course and Sprint questionnaires, observations, meeting recordings, and repository data from git and Flow dock, the primary communication tool. Our results show no significant differences between working in distributed vs. Non-distributed teams, suggesting that Scrum helps alleviate many GSE problems. Our post-course interviews and survey data allows us to explain this effect, we found that students over time learned to better self-select tasks with less inter-team dependencies, to communicate more, and to work better in teams.

The analysis and selection of requirements are important parts of any release planning process. Previous studies on release planning have focused on plan-driven optimization models. Unfortunately, solving the release planning problem mechanistically is difficult in an agile development context. We describe how a release planning method was employed in two case projects in F-Secure, a large Finnish software company. We identify the benefits which the projects gained from the method, and analyze challenges in the cases and improvements made to the method during the case projects. We observed five release planning events and four retrospectives and we conducted surveys in the first two events. We conducted six post-project interviews. We conjoined the observation notes, survey results and interviews and analyzed them qualitatively and quantitatively. The focal point of the method was release planning events where the whole project organization gathered to plan the next release. The planning was conducted by the development teams in close collaboration with each other and with the other stakeholders. We identified ten benefits which included improved communication, transparency, dependency management and decision making. We identified nine challenges which included the lacking preparation and prioritization of requirements, unrealistic schedules, insufficient architectural planning and lacking agile mindset. The biggest improvements to the method were the introduction of frequent status checks and a big visible planning status board. The release planning method ameliorated many difficult characteristics of the release planning problem but its efficiency was negatively affected by the performing organization that was in transition from a plan-driven to an agile development mindset. Even in this case the benefits clearly outweighed the challenges and the method enabled the early identification of the issues in the project.

Software projects that are engineered using global software development techniques are required to deploy processes and tools to support collaboration over large geographies. Specifically, these projects involve the deployment of processes and tools to support project management, communication, and risk management. Whereas a traditional software development effort can use standard processes and tools to support communication and collaboration, global software development efforts require a unified and holistic project management, development process, collaboration, and communication approach taking into consideration the interplay of time zones, number of sites and cultural diversity. In this paper, we introduce a novel approach for modeling and quantification of global software engineering frameworks. In our approach, we apply transient survivability metrics to support the design of global software engineering projects. Therefore, our approach combines survivability analysis and global software engineering frameworks analysis. The survivability metric used in this paper is the time required to recover from a software project disaster (e.g., break down in communication between remote teams) for a given global software engineering framework. The global software engineering modeling framework we use is composed of models supporting the evaluation of communication tools, software development processes and cultural diversity management. We illustrate the application of our approach by applying it to the analysis of an example derived from a real global software engineering project. Our results indicate that the combination of survivability analysis and modeling of global software engineering frameworks can provide meaningful insights when designing global software engineering frameworks.

Everything-as-a-Service (XaaS) is a cloud computing term for the extensive variety of services and applications emerging for users to access on demand over the Internet. In this paper, we describe how Ericsson built a new R&D product development program developing a XaaS platform and a related set of services. As the goal is continuous feature delivery, their R&D organization, distributed to five sites at two continents has recently adopted Lean and Agile software development. We collected data by conducting 32 semi-structured interviews during visits at four sites and four observation sessions at three sites. We describe how this organization has experimented with different set-ups for their tens of agile teams aiming for rapid end-to-end development: from component-based virtual teams to totally cross-functional, cross-component, cross-site teams. Moreover, we discuss the challenges that this organization has faced and how they have mitigated them.

Communities of practice—groups of experts who share a common interest or topic and collectively want to deepen their knowledge—can be an important part of a successful lean and agile adoption in particular in large organizations. In this paper, we present a study on how a large organization within Ericsson with 400 persons in 40 Scrum teams at three sites adopted the use of Communities of Practice (CoP) as part of their transformation from a traditional plan-driven organization to lean and agile. We collected data by 52 semi-structured interviews on two sites, and longitudinal non-participant observation of the transformation during over 20 site visits over a period of two years. The organization had over 20 CoPs, gathering weekly, bi-weekly or on a need basis. CoPs had several purposes including knowledge sharing and learning, coordination, technical work, and organizational development. Examples of CoPs include Feature Coordination CoPs to coordinate between teams working on the same feature, a Coaching CoP to discuss agile implementation challenges and successes and to help lead the organizational continuous improvement, an end-to-end CoP to remove bottlenecks from the flow, and Developers CoPs to share good development practices. Success factors of well-functioning CoPs include having a good topic, passionate leader, proper agenda, decision making authority, open community, supporting tools, suitable rhythm, and cross-site participation when needed. Organizational support include creating a supportive atmosphere and providing a suitable infrastructure for CoPs. In the case organization, CoPs were initially used to support the agile transformation, and as part of the distributed Scrum implementation. As the transformation progressed, the CoPs also took on the role of supporting continuous organizational improvements. CoPs became a central mechanism behind the success of the large-scale agile implementation in the case organization that helped mitigate some of the most pressing problems of the agile transformation.

SUMMARY This paper presents a case study on building a successful agile coaching team focusing on global software development projects in an international Nordic‐based software company. We describe how the team of eight coaches was built, and how the coaches work together as a team using agile practices, such as weekly iterations, backlogs, and daily stand‐ups. Furthermore, we describe their ‘deep and narrow’ approach to working closely with case projects, and the benefits to the coached projects. We describe the main challenges in building the coaching activities in a globally distributed company. The paper concludes with a set of lessons learned for coaching globally distributed projects and a discussion of the future plans for scaling up coaching by building a global coaching network within the company. We collected the data using 13 semi‐structured interviews of the coaching team members, and personnel from four coached case projects. Copyright © 2012 John Wiley & Sons, Ltd.

Context: Proponents of the Scrum software development method use the term "Scrum But" to refer to harmful changes to Scrum. Scrum has been increasingly adopted in large software development organizations. This has led to changes to Scrum practices, but it is not known if these changes are harmful. Objective: We studied how the requirements were planned and managed in the development teams of a large Scrum organization, how well the requirements planning and management practices matched Scrum, and whether the changes were perceived harmful. Method: We quantitatively analysed 435 requirements spanning a time period of approximately one year. We conducted a total of 40 interviews to study the Scrum adoption in the organization and to explain and validate the quantitative results. Results: The main discrepancies between the organization's practices and Scrum were the pacing of the planning process, which was more akin to a continuous process instead of the iteration-paced Scrum model, and the average time it took to develop requirements, which was considerably longer than the time prescribed by Scrum. The latter discrepancy was considered slightly harmful. Conclusion: Changes to the Scrum practices should be evaluated in their context to separate harmful ones from necessary or beneficial changes mandated by the organizational context.

Transforming a large organization from a plan-driven process to agile development is challenging. Despite this, large organizations are increasingly adopting agile development and lean thinking. However, there is little research on how to conduct a successful transformation in large organizations, which often are globally distributed. In this paper we discuss how one R&D unit of Ericsson integrated three global sites into their lean and agile transformation involving 400 persons in Finland, Hungary and the US. We describe the challenges and success factors in integrating the global sites. We collected the data by 45 semi-structured interviews and longitudinally observing the transformation during over 20 site visits. Success factors include: early and broad involvement of global sites at all organizational levels, constant communication and cross-site visits, and creation of joint infrastructure. The challenges include: creating a shared understanding of the change, enabling end-to-end development, bridging cultural differences and creating transparency.

In this paper we describe distributed Scrum augmented with best practices in global software engineering (GSE) as an important paradigm for teaching critical competencies in GSE. We report on a globally distributed project course between the University of Victoria, Canada and Aalto University, Finland. The project-driven course involved 16 students in Canada and 9 students in Finland, divided into three cross-site Scrum teams working on a single large project. To assess learning of GSE competencies we employed a mixed-method approach including 13 post-course interviews, pre-, post-course and iteration questionnaires, observations, recordings of Daily Scrums as well as collection of project asynchronous communication data. Our analysis indicates that the Scrum method, along with supporting collaboration practices and tools, supports the learning of important GSE competencies, such as distributed communication and teamwork, building and maintaining trust, using appropriate collaboration tools, and inter-cultural collaboration.

Global distribution of software engineering introduces geographical, temporal, cultural and organizational distance into teamwork. Globally distributed software projects need to use electronic communication tools to collaborate across these distances. Communication media differ in properties and capabilities to overcome the challenges imposed by these distances.

Scrum-of-Scrums meeting is mentioned in the literature as the mech- anism for handling inter-team coordination in large-scale Scrum. However, how to implement it in projects with tens of teams is not explained. In this paper, we present a multiple case study on how Scrum-of-Scrum meetings were applied in two large-scale, globally distributed Scrum projects both employing at least twenty Scrum teams. We conducted 58 semi-structured interviews of project per- sonnel, including managers, architects, product owners, develop- ers and testers. Our results show that Scrum-of-Scrum meetings involving representatives from all teams were severely challenged: the audience was too wide to keep everybody interested and the participants did not know what to report that might be valuable to other teams, often ending up not reporting anything. As a solu- tion, one of the case projects introduced feature-specific Scrum-of- Scrums meetings for 3-5 teams working on the same feature, which turned out to work well. However, challenges with coordination at the project level remained. The other case organization tried a site- based SoS structure that still did not work well.

Global distribution of software engineering introduces geographical, temporal, cultural and organizational distance into teamwork. Communication media differ in properties and capabilities to overcome the challenges imposed by these distances. Media Synchronicity Theory (MST) aims at explaining the capabilities of communication media and their effect on sharing information and building understanding. Instant messaging (IM), a tool commonly used in distributed projects, falls in between of synchronous and asynchronous communication, therefore making it interesting subject for study. In this paper, we examine the use of IM in distributed software engineering projects. We use MST as a framework to evaluate if and how instant messenger is able to address the challenges imposed by distribution of software projects. Our main finding is that while IM is capable of supporting both information sharing and building common understanding, other communication media are needed, most notably email, issue trackers and teleconferencing, to initiate and maintain communication efficiently.

The Product Owner in Scrum is a crucial role responsible for managing customer requirements in the form of prioritized backlog items and communicating them to the Scrum team. When scaling Scrum to large projects consisting of tens of teams, one Product Owner is not able to work with all the teams; thus the role needs to be scaled. While the literature suggests different scaling approaches, e.g. the use of Area Product Owners, reported experiences of scaling this role are scarce. Based on 58 semi-structured interviews, we report experiences of scaling the Product Owner role in two large globally distributed projects, each with 20 or more Scrum teams. Lessons learned include having local product owner representatives at each site, forming a product owner team, relying on frequent communication between the Product Owner representatives and the Scrum teams, as well as keeping and communicating clear priorities of the backlog to all stakeholders.

SUMMARY Global software development (GSD) projects use a variety of communication tools, such as teleconferences, email, and instant messaging to overcome the challenges caused by distribution. The use of different tools implies different communication needs and practices within the project. Media synchronicity theory (MST) breaks communication down into two processes — conveyance of information and convergence of understanding — and communication media capabilities into five: immediacy of feedback, parallelism, symbol variety, rehearsability, and reprocessability. According to MST, media capabilities differ in support for conveyance and convergence, and for good performance, there should be match between media capabilities and communication process needed in a given task. In this paper, we present our qualitative study on communication in GSD. We interviewed 79 individuals from 12 GSD projects. We discuss which communication tools were used and how. We analyze the tool use and articulated rationale for choosing the tools for various tasks in distributed software development based on the two communicative processes and five media properties suggested by MST. We found evidence supporting the applicability of MST as an aid in selecting communication tools for GSD projects. Copyright © 2011 John Wiley & Sons, Ltd.

This paper presents a currently ongoing single case study on adopting and scaling Scrum in a large software development project distributed across four sites. The data was gathered by 19 semi-structured interviews of project personnel, including managers, architects, developers and testers. At the time of the interviews the project had grown in size during the past 2,5 years from two collocated Scrum teams to 20 teams located in four countries and employing over 170 persons. In this paper we first describe our research approach and goals. Then we briefly summarize the preliminary results of this ongoing study: we explain how Scrum practices were scaled, as well as discuss the successes and challenges experienced when adopting the agile practices and scaling them, while at the same time growing the project size at a fast pace. Even though this project has been very successful from the business point of view, it has experienced a lot of problems in applying Scrum, especially related to scaling the agile practices. Thus, it seems that adapting Scrum practices to work well in a large distributed setting is challenging.

This paper presents a multiple-case study on how three globally distributed software development projects from a large Scandinavia-based IT organization introduced agile practices with the help of a company internal coaching team. The data was gathered by ten semi-structured interviews: we interviewed four coaches and six persons from the coached projects. We describe how the coaches cooperated with the case projects, helping them to adopt agile practices. We present the challenges the projects faced, as well as the benefits they gained. Our results show that when coaching globally distributed projects it is especially important to gain executive support from all the sites, to involve all sites in the change process, to build a common vision in a collaborative workshop, to invite coaches as early as possible, to aim for a long-term coaching relationship, and to remember that the project team owns the change, coaches are there just to support the team.

This paper presents a case study on building a successful agile coaching team focusing on distributed software development projects in a global software company. We describe how the team of eight coaches was built, how the coaches work as a team, how the coaches work with their customer projects, what the main benefits of coaching have been for the customer projects, and the main challenges on building the coaching activities.

Global software development projects use a variety of communication media, such as teleconferences, email and instant messaging to overcome the challenges caused by the distances. Each communication media has different properties and capabilities to mediate the communication on different software engineering tasks. The use of different tools imply different communication practices. In this paper, we report our findings on communication in twelve distributed software projects: which communication tools were used, how they were used, and how communication tool use was related to different tasks in the project studied. We analyze the tool use and articulated rationale for choosing the communication tools for various tasks in distributed software development based on communicative processes and medium properties. We found evidence supporting applicability of media synchronicity theory in selecting communication tools for GSD projects.

Distributed agile development (DAD) has received increasing interest both in industry and academia as global software development (GSD) is becoming main-stream. However, agile methods and in particular agile practices have been designed for collocated software development, and are thus not directly applicable to DAD. In this paper, we present findings from a multiple case study on agile practices in two small and one mid-sized distributed Scrum project. Based on an interview study of 19 project team members, we describe how Scrum practices, such as daily scrums, backlogs, and sprints were successfully adopted to distributed development. We also describe supporting GSD practices employed, such as frequent visits and multiple communication modes that the projects used. Finally, we depict the challenges and benefits the case projects reported, as well as lessons learned from applying Scrum in distributed settings.

While seemingly incompatible, combining large-scale global software development and agile practices is a challenge undertaken by many companies. Case study reports on the successful use of agile practices in small distributed projects already exist. How these practices could be applied to larger projects, however, remains unstudied. This paper reports a case study on agile practices in a 40- person development organization distributed between Norway and Malaysia. Based on seven interviews in the development organization, we describe how Scrum practices were successfully applied, e.g., using teleconference and Web cameras for daily scrum meetings, synchronized 4- week sprints and weekly scrum-of-scrums. Additional agility supporting practices for distributed projects were identified, e.g., frequent visits, unofficial distributed meetings and annual gatherings are described.

At first glance, agile methods and global software development might seem incompatible. Agile methods stress continuous face-to-face communication, whereas communication has been reported as the biggest problem of global software development. One challenge to solve is how to apply agile practices in settings where continuous face-to-face interaction is missing. However, agile methods have been successfully used in distributed projects, indicating that they could benefit global software development. This paper discusses potential benefits and challenges of adopting agile methods in global software development. The literature on real industrial case studies reporting on experiences of using agile methods in distributed projects is still scarce. Therefore we suggest further research on the topic. We present our plans for research in companies using agile methods in their distributed projects. We also intend to test the use of agile principles in globally distributed student projects developing software for industrial clients