1,721,162 research outputs found
Emerging themes in agile software development: Introduction to the special section on continuous value delivery
Get PDFThe 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
Towards a Taxonomy for Autonomy in Large-Scale Agile Software Development
No full textPublisher Copyright: © 2025 IEEE.Agile development relies on self-organizing teams having a high degree of autonomy. For single-team development, more autonomy is generally considered better. In large-scale agile development, where several teams collaborate on the same software with technical and social dependencies, finding the right balance between autonomy and organizational control becomes critical. To this end, it is helpful to have a framework that helps reason about autonomy to help map out to what degree teams can be autonomous, and in what aspects that autonomy needs to be restricted. This paper presents our work towards building a framework for autonomy in large-scale agile development. The preliminary version identifies five levels, and 21 categories of autonomy grouped into three areas. These aspects of autonomy can be taken into account when analyzing or defining the limits of autonomy in large-scale agile software development. The use of the framework is illustrated with an example.Peer reviewe
Problems, Causes and Solutions When Adopting Continuous Delivery - A Systematic Literature Review
No full textAbstract 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.Peer reviewe
Challenges and success factors for large-scale agile transformations: A systematic literature review
No full textAgile 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.Peer reviewe
SAFe transformation in a large financial corporation
No full textPublisher Copyright: © 2023, The Author(s).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.Peer reviewe
Finding the sweet spot for organizational control and team autonomy in large-scale agile software development
Get PDFAgile 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. © 2021, The Author(s).open access</p
Trends in agile: From operational to strategic agility [practitioners' digest]
No full textNon peer reviewe
Recurring opinions or productive improvements—what agile teams actually discuss in retrospectives
Get PDFTeam-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.Peer reviewe
Teaching university students Kanban with a collaborative board game
No full textKanban is a workflow management method especially suitable for managing continuous software engineering work. We attempted to teach Kanban and lean thinking in a software project management course in Aalto University with a collaborative Kanban board game. Our goal was to measure if the learning goals of the class were reached and to study the student's perceptions of the game. Data was collected from two subsequent classes in 2014 and 2015. Quantitative data was collected with questionnaires and analysed descriptively and statistically. Qualitative data was collected from 57 learning diaries. The students perceived they had learned substantially from the game. They also evaluated the game very positively. However, the qualitative results and the measured learning indicated that the learning goals were only partially reached. The enjoyable game experience did not fully translate into effective learning.Peer reviewe
Comparison of release engineering practices in a large mature company and a startup
No full textModern 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.Peer reviewe
- …
