3,425 research outputs found

    When agility meets a project portfolio: A study of success factors in large organisations

    Get PDF
    The iterative nature of agile methods combined with high levels of team and customer interactions and continuously changing IT and software development project requirements make the management of agile project portfolios very complex. To date, the mechanisms under which project portfolio management adapts to these complexities and achieves portfolio success have not been thoroughly investigated. This study explores the notion of success and its impacting factors in large organisations\u27 portfolios of agile IT and software development projects. Using a multiple case study design, we analysed the agile project portfolios of seven large organisations. We identified four success criteria and 15 success factors and categorised them into a unique agile portfolio success framework. Some of these criteria and factors are unique to agile project portfolios. The framework contributes to agile and project management literature by conceptualising the notion of success in portfolios of agile projects while revealing a set of factors that affect the relationship between an agile portfolio with its subcomponents and the surrounding environment. The framework supports managers and practitioners in large organisations in reflecting on their agility efforts to achieve higher success rates in their agile portfolios

    Testing and Improving a Continuous Requirements Risk Profiling Method - A Case Study on Agile Software Projects

    Get PDF
    As requirements play key role in the success of a software development project, identifying and mitigating requirements related risks becomes an important factor in improving software quality. Still, only few methods are offered for that purpose and little results of the feasibility of such methods in industry are reported. In this thesis, feasibility of one requirements risk management methodology was tested in agile software projects and an improved version of the method proposed. The tested method consists of identifying, prioritizing and resolving risks using predefined checklists, patterns and techniques. The objectives of the study were to gain knowledge do professionals working in agile software projects find the method feasible, are such methods found useful and how the method should be improved so that it could be taken into use in the case company. The study was conducted as an interpretive case study which covered several agile software projects from the case company. The primary data collection method for the study were semi-structured theme-centered interviews, in which the method was tested and evaluated by conducting a requirements risk analysis for each of the case projects. The key selection criteria for the interviewees was participation to requirements work and use of some agile software development methodology. The collected qualitative interview data was analyzed using thematic analysis. Based on the results of this study, it was observed that the tested method helped professionals to identify different type of requirements risks and to prioritize those on high level. The interviewed professionals found the tested method useful and feasible in the agile software projects they were currently working with. However, it was also observed that the resolution proposals provided by the method would still need further development. For researchers, the study provided empirical evidence on the feasibility of the method and several suggestions for further research. For professionals working in industry, the study provided one empirically validated method for managing requirements risk, and encouragement for collecting the existing requirements risk management knowledge and sharing it with corresponding methods and tools.fi=Opinnäytetyö kokotekstinä PDF-muodossa.|en=Thesis fulltext in PDF format.|sv=Lärdomsprov tillgängligt som fulltext i PDF-format

    ORGANIC SOFTWARE DEVELOPMENT: A CASE STUDY FOR AGILE DEVELOPMENT

    Get PDF
    This project examines the efforts and results of United States Strategic Command’s (USSTRATCOM) Targeting Process Improvement Working Group (TPIWG) as a case study. The TPIWG conducted an evaluation of USSTRATCOM J52/J2T Joint Targeting Division's current target maintenance processes and identified areas of improvements. After identification of areas requiring improvement, the TPIWG conceived the idea for and began design and development of an automated change detection software program for target maintenance.Methodology includes an analysis of what processes were identified for improvement and how change was implemented, how well software development processes were implemented and adhered to, analysis of the process to secure funding support from the U.S. Air Force and subsequent contracting for full time support of the software. This case study documents challenges, innovative ideas, risks taken and faced by the TPIWG during the course of process analysis, software development and implementation phases. Documentation of challenges to sustainment funding from a cost, schedule, and performance perspective. Exploration of pros and cons to having the completed work then contracted to a secondary party, not part of the TPIWG. Identification of future challenges contractors may face in the sustainment or future improvements of the software. Lastly, this case study tries to determine what the overall improvement and benefit is for the warfighter.Lieutenant Commander, United States NavyApproved for public release. Distribution is unlimited

    Scrum in Practice: an Overview of Scrum Adaptations

    Get PDF
    Agile software development practices have gained widespread acceptance and application across all industries. Scrum, as one of the most widely used agile methods, has been adopted in countless organizations. However, while there is an understanding that practitioners rarely apply Scrum by the book , only little research addresses the actual adaptations and modifications that are made to fit Scrum to real world requirements: whether it is to solve methodological drawbacks, to fit the method to specific contextual constraint, or to add additional value to the method by augmentation or combination with other tools and methods. To get an overview of the proposed adaptations and their implications, this study presents a systematic review of literature reporting on challenges and motivations that lead to modifications of the Scrum method. Based on 31 relevant studies we extract seven distinct motivations for modifying Scrum, as well as six generic solution strategies to adapt the method

    Software Product Line Reengineering: A Case Study on the Geographic Domain

    Get PDF
    The growing adoption of software product lines (SPL) represents perhaps a paradigm shift in software development aiming at improving cost, quality, time to market, and developer productivity. While the underlying concepts are straightforward enough building a family of related products or systems by planned and careful reuse of a base of generalized software development assets the problems can be in the details, as successful product line practice involves domain understanding, technology selection, and so forth. Today, there is an important increment on reporting experiences and lessons about SPL development by capturing aspects that have been gathered during daily practice. Following this line, in this paper we start from our experiences of developing a software product line on the Marine Ecology domain highlighting our reasons for reengineering a previous SPL. Then, we explain step-bystep reengineering activities in terms of motivation, solutions, and lessons learned, which summarize strengths and limitations of the applied practices. Differently from other cases, here we take advantage of using domain standards as well as open source implementations within the geographic domain.Facultad de Informátic

    Agile Methods on the Shop Floor: Towards a "Tesla Production System"?

    Get PDF
    This discussion paper investigates two questions: To what extend can Tesla be regarded as a digital firm, and do we - as a result - see elements of a distinct "Tesla production system"? While the EV-startup is widely approached as a competing automaker focusing on the electric drive train, which it certainly is, this paper argues that it can only fully be understood as a digital firm - a digital car company with a digital product embedded in a digital ecosystem. Its roots in Silicon Valley, its software-first approach, and its strategic exploitation of user activity data point into this direction. In the second part, this paper explores to what extent Tesla's rootedness in software and its Silicon-Valley ancestry gave reason to introduce methods borrowed from software development on the shop floor. To a certain degree, concepts from agile software development found their way to the very assembly-line at Tesla. Although it might be exaggerated to speak of a distinct "Tesla Production system", indications for a considerable and possibly enduring alteration of Lean Production paradigm can be determined

    Software Product Line Reengineering: A Case Study on the Geographic Domain

    Get PDF
    The growing adoption of software product lines (SPL) represents perhaps a paradigm shift in software development aiming at improving cost, quality, time to market, and developer productivity. While the underlying concepts are straightforward enough building a family of related products or systems by planned and careful reuse of a base of generalized software development assets the problems can be in the details, as successful product line practice involves domain understanding, technology selection, and so forth. Today, there is an important increment on reporting experiences and lessons about SPL development by capturing aspects that have been gathered during daily practice. Following this line, in this paper we start from our experiences of developing a software product line on the Marine Ecology domain highlighting our reasons for reengineering a previous SPL. Then, we explain step-bystep reengineering activities in terms of motivation, solutions, and lessons learned, which summarize strengths and limitations of the applied practices. Differently from other cases, here we take advantage of using domain standards as well as open source implementations within the geographic domain.Facultad de Informátic

    Software Product Line Reengineering: A Case Study on the Geographic Domain

    Get PDF
    The growing adoption of software product lines (SPL) represents perhaps a paradigm shift in software development aiming at improving cost, quality, time to market, and developer productivity. While the underlying concepts are straightforward enough building a family of related products or systems by planned and careful reuse of a base of generalized software development assets the problems can be in the details, as successful product line practice involves domain understanding, technology selection, and so forth. Today, there is an important increment on reporting experiences and lessons about SPL development by capturing aspects that have been gathered during daily practice. Following this line, in this paper we start from our experiences of developing a software product line on the Marine Ecology domain highlighting our reasons for reengineering a previous SPL. Then, we explain step-bystep reengineering activities in terms of motivation, solutions, and lessons learned, which summarize strengths and limitations of the applied practices. Differently from other cases, here we take advantage of using domain standards as well as open source implementations within the geographic domain.Fil: Buccella, Agustina. Universidad Nacional del Comahue. Facultad de Informática. Departamento Ingeniería de Sistemas; Argentina. Consejo Nacional de Investigaciones Científicas y Técnicas; ArgentinaFil: Cechich, Susana Alejandra. Universidad Nacional del Comahue. Facultad de Informática. Departamento Ingeniería de Sistemas; ArgentinaFil: Pol'la, Matías. Universidad Nacional del Comahue. Facultad de Informática. Departamento Ingeniería de Sistemas; ArgentinaFil: Arias, Maximiliano Andrés. Universidad Nacional del Comahue. Facultad de Informática. Departamento Ingeniería de Sistemas; Argentina. Consejo Nacional de Investigaciones Científicas y Técnicas; Argentin
    corecore