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.

Abstract Reversing an outsourcing decision and retaking control of the development and operations of IT systems can be a viable option for organizations facing outsourcing-related challenges, such as problematic vendor relationships, high costs, or the recognition of software development as a core competence. Despite its increasing practical importance, backsourcing has received little attention in the software engineering literature. This paper presents an in-depth case study of a large public organization that successfully backsourced the development of the majority of its large portfolio of software systems. Based on interviews with 61 representatives of the backsourcing organization and its vendors and an analysis of corporate documentation, we present the rationale for backsourcing, the six main guiding principles shaping the approach, and the outcomes and lessons learned from the initiative. The primary reason for backsourcing in the case organization was cost reduction. The IT department led the effort, granting various application areas considerable autonomy in the practical implementation of backsourcing. The effort was characterized by close and constructive collaboration with the outsourcing vendors, who were being phased out, an incremental approach to assuming responsibility for the applications, and the concurrent implementation of agile development at scale. Over three years, the organization successfully backsourced over 100 systems and established an agile development organization with over 300 people. As a result of backsourcing, the organization reported an increased sense of system ownership, increased personnel motivation, faster deliveries, and better quality-in-use. We were unable to find clear evidence of significant cost savings. Key challenges included managing the change effort, building and retaining the necessary competencies, and addressing organizational tensions resulting from the IT department’s central role in the backsourcing effort.

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.

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.

While agile software development is increasingly adopted in large organizations, there is still a lack of studies on how traditionally organized enterprises adopt and scale agile forms of organization. This industrial multiple embedded case study explores how the organizational model of a large public sector entity evolved over four years to support the adoption of agile software development methods. Data was collected through semi-structured interviews and document analysis. We describe the change in three phases: pre-transformation, initial transformation, and maturing. Changes in three subcases of organizational units are further described in detail. Moving from an outsourced project-based way-of-working with separate business, IT and vendor organizations, the new organizational design emphasizes internal development capability, cross-functional autonomous teams organized around products and grouped in product areas, and continuous delivery. Starting from the IT department, the transformation expanded to the whole organization, and went beyond software development to the finance and leadership. We describe the target and intermediate organizations employed when adopting agile development methods for the whole organization and three organizational units responsible for different services. Defining suitable product boundaries, achieving alignment across teams, enhancing the competence of product owners, the coexistence of old and new types of systems, processes, and structures, and balancing the teams’ need for autonomy with the organizational needs for coordination and control are remaining challenges.

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.

Requirements Engineering (RE) has established itself as a software engineering discipline over the past decades. While researchers have been investigating the RE discipline with a plethora of empirical studies, attempts to systematically derive an empirical theory in context of the RE discipline have just recently been started. However, such a theory is needed if we are to define and motivate guidance in performing high quality RE research and practice. We aim at providing an empirical and externally valid foundation for a theory of RE practice, which helps software engineers establish effective and efficient RE processes in a problem-driven manner. We designed a survey instrument and an engineer-focused theory that was first piloted in Germany and, after making substantial modifications, has now been replicated in 10 countries worldwide. We have a theory in the form of a set of propositions inferred from our experiences and available studies, as well as the results from our pilot study in Germany. We evaluate the propositions with bootstrapped confidence intervals and derive potential explanations for the propositions. In this article, we report on the design of the family of surveys, its underlying theory, and the full results obtained from the replication studies conducted in 10 countries with participants from 228 organisations. Our results represent a substantial step forward towards developing an empirical theory of RE practice. The results reveal, for example, that there are no strong differences between organisations in different countries and regions, that interviews, facilitated meetings and prototyping are the most used elicitation techniques, that requirements are often documented textually, that traces between requirements and code or design documents are common, that requirements specifications themselves are rarely changed and that requirements engineering (process) improvement endeavours are mostly internally driven. Our study establishes a theory that can be used as starting point for many further studies for more detailed investigations. Practitioners can use the results as theory-supported guidance on selecting suitable RE methods and techniques.

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.

In educational projects, having students encounter problems is desirable, if it increases learning. However, in capstone projects with industrial customers, negative effects problems can have on customer satisfaction must be considered. We conducted a survey in a capstone project course in order to study problems, learning and customer satisfaction related to eleven software engineering topics. On the average, students working in the managerial roles learned quite a lot about each topic, and the developers learned moderately, but the degree of learning varied a lot among the teams, and among the team members. The most extensively encountered problems were related to testing, task management, effort estimation and technology skills. The developers contributed quite a lot to solving problems with technology skills, but only moderately or less with other topics, whereas the managers contributed quite a lot with most of the topics. Contributing to solving problems increased learning moderately for most of the topics. The increases were highest with maintaining motivation and technology skills. Encountering problems with task management, customer expectations and customer communication affected customer satisfaction very negatively. When considering both learning and customer satisfaction, the best topics to encounter problems in were effort estimation, testing, and technology skills.

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.

Team-level retrospectives are widely used in agile and lean software development, yet little is known about what is actually discussed during retrospectives or their outcomes. In this paper, we synthesise the outcomes of sprint retrospectives in a large, distributed, agile software development organisation. This longitudinal case study analyses data from 37 team-level retrospectives for almost 3 years. We report the outcomes of the retrospectives, their perceived importance for process improvement and relatVed action proposals. Most discussions were related to topics close to and controllable by the team. However, the discussions might suffer from participant bias, and in cases where they are not supported by hard evidence, they might not reflect reality, but rather the sometimes strong opinions of the participants. Some discussions were related to topics that could not be resolved at the team level due to their complexity. Certain topics recurred over a long period of time, either reflecting issues that can and have been solved previously, but that recur naturally as development proceeds, or reflecting waste since they cannot be resolved or improved on by the team due to a lack of controllability or their complexity. For example, the discussion on estimation accuracy did not reflect the true situation and improving the estimates was complicated. On the other hand, discussions on the high number of known bugs recurred despite effective improvements as development proceeded.

Context: Continuous delivery is a software development discipline in which software is always kept releasable. The literature contains instructions on how to adopt continuous delivery, but the adoption has been challenging in practice. Objective: In this study, a systematic literature review is conducted to survey the faced problems when adopting continuous delivery. In addition, we identify causes for and solutions to the problems. Method: By searching five major bibliographic databases, we identified 293 articles related to continuous delivery. We selected 30 of them for further analysis based on them containing empirical evidence of adoption of continuous delivery, and focus on practice instead of only tooling. We analyzed the selected articles qualitatively and extracted problems, causes and solutions. The problems and solutions were thematically synthesized into seven themes: build design, system design, integration, testing, release, human and organizational and resource. Results: We identified a total of 40 problems, 28 causal relationships and 29 solutions related to adoption of continuous delivery. Testing and integration problems were reported most often, while the most critical reported problems were related to testing and system design. Causally, system design and testing were most connected to other themes. Solutions in the system design, resource and human and organizational themes had the most significant impact on the other themes. The system design and build design themes had the least reported solutions. Conclusions: When adopting continuous delivery, problems related to system design are common, critical and little studied. The found problems, causes and solutions can be used to solve problems when adopting continuous delivery in practice.

Context: In continuous delivery, the aim is that every feature passes through the integration and deployment pipeline, resulting in an immediately deployable product. This practice has been proposed to accelerate value delivery, improve software quality and increase developer productivity.

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.

The relationship between customers and suppliers remains a challenge in agile software development. Two trends seek to improve this relationship, the increased focus on value and the move towards continuous deployment. In this special section on continuous value delivery, we describe these emerging research themes and show the increasing interest in these topics over time. Further, we discuss implications for future research.

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.

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.

Signal processing software is characterized by a heavy emphasis on arithmetic calculations and the lack of complicated control structures, placing specific constraints on which testing techniques are applicable and how signal processing software can be efficiently tested. In this paper, we analyze the unique characteristics of signal processing software from the testing viewpoint and propose applied techniques for tackling the verification challenges of such software. We propose a testing method for the signal processing context and provide examples of its application to an FIR and a second order IIR filter. This method extends the applicability of algebraic testing and domain testing methods to signal processing software. The developed method applies to linear systems and can be further extended to take nonlinearities in the tested system into account.

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.

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.

Time pressure is prevalent in the software industry in which shorter and shorter deadlines and high customer demands lead to increasingly tight deadlines. However, the effects of time pressure have received little attention in software engineering research. We performed a controlled experiment on time pressure with 97 observations from 54 subjects. Using a two-by-two crossover design, our subjects performed requirements review and test case development tasks. We found statistically significant evidence that time pressure increases efficiency in test case development (high effect size Cohen’s d=1.279) and in requirements review (medium effect size Cohen’s d=0.650). However, we found no statistically significant evidence that time pressure would decrease effectiveness or cause adverse effects on motivation, frustration or perceived performance. We also investigated the role of knowledge but found no evidence of the mediating role of knowledge in time pressure as suggested by prior work, possibly due to our subjects. We conclude that applying moderate time pressure for limited periods could be used to increase efficiency in software engineering tasks that are well structured and straight forward.

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.

We present a field study on how testers use knowledge while performing exploratory software testing (ET) in industrial settings. We video recorded 12 testing sessions in four industrial organizations, having our subjects think aloud while performing their usual functional testing work. Using applied grounded theory, we analyzed how the subjects performed tests and what type of knowledge they utilized. We discuss how testers recognize failures based on their personal knowledge without detailed test case descriptions. The knowledge is classified under the categories of domain knowledge, system knowledge, and general software engineering knowledge. We found that testers applied their knowledge either as a test oracle to determine whether a result was correct or not, or for test design, to guide them in selecting objects for test and designing tests. Interestingly, a large number of failures, windfall failures, were found outside the actual focus areas of testing as a result of exploratory investigation. We conclude that the way exploratory testers apply their knowledge for test design and failure recognition differs clearly from the test-case-based paradigm and is one of the explanatory factors of the effectiveness of the exploratory testing approach.

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.

SUMMARY When global software engineering (GSE) is understood as knowledge intensive collaborative work, many of the reasons for the problems encountered in GSE projects can be traced back to the social conditions framing the collaboration between people at different physical sites. A total of 59 interviews were conducted in eight GSE projects of two large software companies with sites in Finland and other countries. As a result of categorization of problems related to group relations, the lack of trust between the main site and the other sites, and the fear of negative personal consequences among the project employees at the main site due to introduction of GSE were found to be the major problems in the projects. Our analysis suggests that poorly communicated reasoning for GSE can lay the ground for fear and for distrust between employees at remote sites. Unfulfilled cognitive expectations and fear related to one's professional future were found to be the sources of distrust toward employees at off‐site locations. The main contribution of this study is a novel empirical description of the linkages between fear and distrust in GSE. In addition, practical implications to effectively implement an organizational change from collocated development to distributed development are suggested. Copyright © 2010 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 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.

We present the results of a qualitative observation study on the manual testing practices in four software development companies. Manual testing practices are seldom studied, and based on the literature we conjecture that they have a strong effect on the effectiveness of manual testing. We observed testing sessions of 11 software professionals performing system level functional testing. As a result we identified 22 manual testing practices that we classified into 9 test session strategies and 13 detailed test execution techniques. Many of the identified techniques were based on similar ideas as traditional test case design techniques. However, the subjects applied these techniques during manual testing without separate test design phase. The results indicate that software professionals use a wide set of strategies and techniques when performing manual testing. Testers seem to need and use techniques even if applying exploratory testing.

Software development as a knowledge intensive activity involves high requirements for communication and collaboration between its practitioners. In global software development, geographical, cultural and language distances bring additional challenges to communication. While text-based communication is very common in global software projects, recent improvements in telecommunications technology and network infrastructure have enabled ad-hoc audio conferencing as an economically feasible and available communication medium. Media richness theory suggests audio conferencing as a richer medium to have potential in leveraging uncertainty and equivocality, while media synchronicity theory suggests using multiple communication media to accomplish a task. This empirical qualitative study is based on 57 interviews from eight global software development projects. We discovered that self-conception of poor language skills leads to preference to use text-based communication media. We also found out that technical personnel tends to prefer text-based communication media more than non-technical team members.

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.

When globally distributed software development (GSD) is understood as knowledge intensive collaborative work, many of the reasons for problems encountered in GSD projects can be traced back to social conditions framing the collaboration between people at onsite and offsite. A total of 59 interviews were conducted in 8 GSD projects of two major software companies located in Finland. As a result of categorization of problems related to group relations in GSD projects, the lack of trust between onsite and offsite and fears of losing jobs at onsite was found as major problems in the early phases of the projects. Our analysis suggests that poorly communicated reasons GSD can cause severe problems in collaboration between people by laying the ground for fears and for distrust between sites. The study contributes to the GSD research by creating a novel empirical description of the linkages between fear and distrust in GSD.

Research on code reviews has often focused on defect counts instead of defect types, which offers an imperfect view of code review benefits. In this paper, we classified the defects of nine industrial (C/C++) and 23 student (Java) code reviews, detecting 388 and 371 defects, respectively. First, we discovered that 75 percent of defects found during the review do not affect the visible functionality of the software. Instead, these defects improved software evolvability by making it easier to understand and modify. Second, we created a defect classification consisting of functional and evolvability defects. The evolvability defect classification is based on the defect types found in this study, but, for the functional defects, we studied and compared existing functional defect classifications. The classification can be useful for assigning code review roles, creating checklists, assessing software evolvability, and building software engineering tools. We conclude that, in addition to functional defects, code reviews find many evolvability defects and, thus, offer additional benefits over execution-based quality assurance methods that cannot detect evolvability defects. We suggest that code reviews may be most valuable for software products with long life cycles as the value of discovering evolvability defects in them is greater than for short life cycle systems.

Instant messaging (IM) has become a significant tool for communication in global software development (GSD) projects. In this paper, we describe experiences of IM use based on 39 semi-structured interviews of participants in six GSD projects. Our results indicate that in successful projects, IM use was more wide-spread and systematical. IM status information was used to assess availability, even though the information was not always up-to-date. IM was used to facilitate multitasking and communication with multiple people simultaneously, and as a side channel in meetings. Many considered the communication initiation barrier lower for IM than for other synchronous communication media, such as the telephone. Saving the transcripts from significant discussions and decisions made during IM sessions was considered important, and failure to do so systematically was a major driving force to use other media, such as email, instead of instant messaging.

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.

This paper presents a controlled experiment comparing the defect detection efficiency of exploratory testing (ET) and test case based testing (TCT). While traditional testing literature emphasizes test cases, ET stresses the individual tester's skills during test execution and does not rely upon predesigned test cases. In the experiment, 79 advanced software engineering students performed manual functional testing on an open-source application with actual and seeded defects. Each student participated in two 90-minute controlled sessions, using ET in one and TCT in the other. We found no significant differences in defect detection efficiency between TCT and ET. The distributions of detected defects did not differ significantly regarding technical type, detection difficulty, or severity. However, TCT produced significantly more false defect reports than ET. Surprisingly, our results show no benefit of using predesigned test cases in terms of defect detection efficiency, emphasizing the need for further studies of manual testing.

We present experiences from a two-year study of adopting pair programming (PP) in a Finnish software product company. When adopting PP, the company used five tactics: the creation of simple PP guidelines, the use of a PP champion, making the use of PP voluntary, creating a positive atmosphere for PP, and instituting a separate PP room. By the end of the study the feelings of PP considerably surpassed developers' preconceptions of PP, and even the feelings of solo programming. Issues identified in the infrastructure for PP were solved through the adoption of the PP room. In the end of the study, a majority of the developers thought that PP should be utilized more than the reached ca. 10% of development effort. Unresolved issues in resourcing PP probably hindered reaching the desired level for the use of PP.

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

This work presents the results of an initial empirical study on the subjective evaluation of bad code smells, which identify poor structures in software. Based on a case study in a Finnish software product company, we make two contributions. First, we studied the evaluator effect when subjectively evaluating the existence of smells in code modules. We found that the use of smells for code evaluation purposes is hard due to conflicting perceptions of different evaluators. Second, we applied source code metrics for identifying three smells and compared these results to the subjective evaluations. Surprisingly, the metrics and smell evaluations did not correlate.

This paper presents research in progress, as well as tentative findings related to the empirical study of so called bad code smells. We present a taxonomy that categorizes similar bad smells. We believe that taxonomy makes the smells more understandable and recognizes the relationships between smells. Additionally, we present our initial findings from an empirical study of the use of the smells for evaluating code quality in a small Finnish software product company. Our findings indicate that the taxonomy for the smells could help explain the identified correlations between the subjective evaluations of the existence of the smells.