•Systematic review on large-scale agile transformations analyzing 52 papers.•We identify 35 reported challenges in 9 categories, and 29 success factors in 11 categories.•Few academic studies (6), ...mostly experience reports (46) identified.•Challenges e.g. difficulty of implementing, integrating other functions, and change resistance.•Success factors e.g. choosing and tailoring, management support, and mindset.
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.
Background: Accurate effort estimation is crucial for planning in Agile iterative development. Agile estimation generally relies on consensus-based methods like planning poker, which require less ...time and information than other formal methods (e.g., COSMIC) but are prone to inaccuracies. Understanding the common reasons for inaccurate estimations and how proposed approaches can assist practitioners is essential. However, prior systematic literature reviews (SLR) only focus on the estimation practices (e.g., References 26 , 127 ) and the effort estimation approaches (e.g., Reference 6 ). Aim: We aim at identifing themes of reasons for inaccurate estimations and classify approaches to improve effort estimation. Method: We conducted an SLR and identified the key themes and a taxonomy. Results: The reasons for inaccurate estimation are related to information quality, team, estimation practice, project management, and business influences. The effort estimation approaches were the most investigated in the literature, while only a few aim to support the effort estimation process. Yet, few automated approaches are at risk of data leakage and indirect validation scenarios. Recommendations: Practitioners should enhance the quality of information for effort estimation, potentially by adopting an automated approach. Future research should aim at improving the information quality, while avoiding data leakage and indirect validation scenarios.
•We mapped out 17 requirements engineering practices adopted by agile practitioners so far.•Identified 5 challenges of traditional requirements engineering overcome by adopting agile requirements ...engineering.•Found 8 challenges posed by following agile requirements engineering.•Findings suggest that research context needs attention in terms of more empirical.•The empirical results can help to analyse impact of adopting agile requirements engineering.
Unlike traditional software development methods, agile methods are marked by extensive collaboration, i.e. face-to-face communication. Although claimed to be beneficial, the software development community as a whole is still unfamiliar with the role of the requirements engineering practices in agile methods. The term “agile requirements engineering” is used to define the “agile way” of planning, executing and reasoning about requirements engineering activities. Moreover, not much is known about the challenges posed by collaboration-oriented agile way of dealing with requirements engineering activities. Our goal is to map the evidence available about requirements engineering practices adopted and challenges faced by agile teams in order to understand how traditional requirements engineering issues are resolved using agile requirements engineering. We conducted a systematic review of literature published between 2002 and June 2013 and identified 21 papers, that discuss agile requirements engineering. We formulated and applied specific inclusion and exclusion criteria in two distinct rounds to determine the most relevant studies for our research goal. The review identified 17 practices of agile requirements engineering, five challenges traceable to traditional requirements engineering that were overcome by agile requirements engineering, and eight challenges posed by the practice of agile requirements engineering. However, our findings suggest that agile requirements engineering as a research context needs additional attention and more empirical results are required to better understand the impact of agile requirements engineering practices e.g. dealing with non-functional requirements and self-organising teams.
•Agile and non-agile software development typically have similar front-end phases.•Agile software development with less detail in the front-end phase performed better.•The front-end phase content ...should be context-dependent avoiding one-size-fits-all.•Studies show a lack of robustness regarding causal connections.•There has been a low research interest in the front-end phase.
Software development of new products and services often involves a front-end phase where user needs are analysed, costs and benefits are estimated, and initial plans are created.
This study aims to learn more about how the introduction of agile software development has affected practices and outcomes related to cost and benefit estimation in this front-end phase and to understand better what would improve this phase.
We identified, reviewed and aggregated the results from 42 relevant research articles by searching literature databases and snowballing relevant articles.
The front-end phase of agile was found to be, on average, similar and just as comprehensive as that of non-agile software development. This may be unfortunate, given the finding that more successful agile software development is connected with less detail in cost estimation and planning-related activities. A less comprehensive front-end phase may be especially beneficial for low-risk agile software development.
The results of this review suggest that agile principles, so far, have had a limited influence on the front-end phase. We recommend more flexibility and context-dependency in how the front-end phase of agile software development is conducted, including less comprehensive estimation and planning activities for low-risk software development contexts.
Agile software development has dominated the second half of the past 50 years of software engineering. Retrospectives, one of the most common agile practices, enables reflection on past performance, ...discussion of current progress, and charting forth directions for future improvement. Because of agile's burgeoning popularity as the software development model of choice and a significant research subdomain of software engineering, it demands a retrospective of its own. This article provides a historical overview of agile's main focus areas and a holistic synthesis of its trends, their evolution over the past two decades, agile's current status, and, forecast from these, agile's likely future. This article is part of a theme issue on software engineering's 50th anniversary.
Governments need to adapt to changes in their internal and external environments and create systems that allow them to scan trends, identify developments, predict their potential impact on the ...organization, and quickly learn how to implement changes to their standard operating procedures. As a response, government organizations are adopting agile approaches as part of their process redesigns, project management, and software development approaches. Although agility and adaptiveness are long in use in the private sector, they have been increasingly adopted in the public sector literature and practices. In order to understand the existing theoretical and practical foundations of the field, we have conducted a systematic literature review and identified four streams of research areas: (1) software development approaches, (2) project management approaches, (3) application areas, and (4) potential outcomes. In this article, we synthesize this literature, provide an outlook on future research questions, and introduce several articles as part of the current special issue focused on agile government.
•A systematic literature review on agile government research is provided.•Agility is needed in adopting and realizing the benefits of new technologies.•A holistic agile government approach across different organizational levels is desired.•Four papers on agile government application and practices are introduced.
On the basis of 13 agile transformation cases over 15 years, we identify nine challenges associated with implementing Scaled Agile Framework, Scrum at Scale, Spotify, Large-Scale Scrum, Nexus, and ...other mixed or customized large-scale agile frameworks. These challenges should be considered by organizations aspiring to pursue a large-scale agile strategy. We also provide recommendations for practitioners and agile researchers.
Defining and designing a software product is not merely a technical endeavor, but also a socio-technical journey. As such, its success is associated with human-related aspects, such as the value ...users perceive. To handle this issue, the product manager role has become more evident in software-intensive companies. A unique, challenging context for these professionals is constituted by software startups, emerging companies developing novel solutions looking for sustainable and scalable business models.
This study aims to describe the role of product managers in the context of software startups.
We performed a Socio-Technical Grounded Theory study using data from blog posts and interviews.
The results describe the product manager as a multidisciplinary, general role, not only guiding the product by developing its vision but also as a connector that emerges in a growing company, enabling communication of software development with other areas, mainly business and user experience. The professional performing this role has a background in one of these areas but a broad knowledge and understanding of key concepts of the other areas is needed. We also describe how differences of this role to other lead roles are perceived in practice.
Our findings represent several implications for research, such as better understanding of the role transformation in growing software startups, practice, e.g., identifying the points to which a professional migrating to this role should pay attention, and the education of future software developers, by suggesting the inclusion of related topics in the education and training of future software engineers.
Given the relevance of coordination in the field of global software engineering, this work was carried out to further understand coordination mechanisms. Specifically, we investigated meetings and ...the collaboration tool Slack. We conducted a longitudinal case study using a mixed-methods approach with surveys, observations, interviews, and chat logs. Our quantitative results show that employees in global projects spend 7 h 45 min per week on average in scheduled meetings and 8 h 54 min in unscheduled meetings. Furthermore, distributed teams were significantly larger than co-located teams, and people working in distributed teams spent somewhat more time in meetings per day. We found that low availability of key people, absence of organizational support for unscheduled meetings and unbalanced activity from team members in meetings and on Slack were barriers for effective coordination across sites. The positive aspects of using collaboration tools in distributed teams were increased team awareness and informal communication and reduced the need for e-mail. Our study emphasizes the importance of reflecting on how global software engineering teams use meetings and collaboration tools to coordinate. We provide practical advice for conducting better meetings and give suggestions for more efficient use of collaboration tools in global projects.
•A longitudinal study on coordination in global software development.•Data from interviews, observations, documents, Slack logs, and a survey.•Developers spend more time in unscheduled than scheduled coordination.•Employees in global projects spend 16 h and 36 min per week in meetings.•Collaboration tools increase awareness and informal communication and reduce the need for e-mail.
Software development projects have undergone remarkable changes with the arrival of agile development approaches. Although intended for small, self-managing teams, these approaches are used today for ...large development programs. A major challenge of such programs is coordinating many teams. This case study describes the coordination of knowledge work in a large-scale agile development program with 12 teams. The findings highlight coordination modes based on feedback, the use of a number of mechanisms, and how coordination practices change over time. The findings can improve the outcomes of large knowledge-based development programs by tailoring coordination practices to needs over time.