Comparative Study on Agile software development methodologies

Today-s business environment is very much dynamic, and organisations are constantly changing their software requirements to adjust with new environment. They also demand for fast delivery of software products as well as for accepting changing requirements. In this aspect, traditional plan-driven developments fail to meet up these requirements. Though traditional software development methodologies, such as life cycle-based structured and object oriented approaches, continue to dominate the systems development few decades and much research has done in traditional methodologies, Agile software development brings its own set of novel challenges that must be addressed to satisfy the customer through early and continuous delivery of the valuable software. It is a set of software development methods based on iterative and incremental development process, where requirements and development evolve through collaboration between self-organizing, cross-functional teams that allows rapid delivery of high quality software to meet customer needs and also accommodate changes in the requirements. In this paper, we significantly identify and describe the major factors, that Agile development approach improves software development process to meet the rapid changing business environments. We also provide a brief comparison of agile development methodologies with traditional systems development methodologies, and discuss current state of adopting agile methodologies. We speculate that from the need to satisfy the customer through early and continuous delivery of the valuable software, Agile software development is emerged as an alternative to traditional plan-based software development methods. The purpose of this paper, is to provide an in-depth understanding, the major benefits of agile development approach to software development industry, as well as provide a comparison study report of ASDM over TSDM.Comment: 25 pages, 25 images, 86 references used, with authors biographie

An Empirical Study on Decision making for Quality Requirements

[Context] Quality requirements are important for product success yet often handled poorly. The problems with scope decision lead to delayed handling and an unbalanced scope. [Objective] This study characterizes the scope decision process to understand influencing factors and properties affecting the scope decision of quality requirements. [Method] We studied one company's scope decision process over a period of five years. We analyzed the decisions artifacts and interviewed experienced engineers involved in the scope decision process. [Results] Features addressing quality aspects explicitly are a minor part (4.41%) of all features handled. The phase of the product line seems to influence the prevalence and acceptance rate of quality features. Lastly, relying on external stakeholders and upfront analysis seems to lead to long lead-times and an insufficient quality requirements scope. [Conclusions] There is a need to make quality mode explicit in the scope decision process. We propose a scope decision process at a strategic level and a tactical level. The former to address long-term planning and the latter to cater for a speedy process. Furthermore, we believe it is key to balance the stakeholder input with feedback from usage and market in a more direct way than through a long plan-driven process

Artefacts and agile method tailoring in large-scale offshore software development programmes

Context: Large-scale offshore software development programmes are complex, with challenging deadlines and a high risk of failure. Agile methods are being adopted, despite the challenges of coordinating multiple development teams. Agile processes are tailored to support team coordination. Artefacts are tangible products of the software development process, intended to ensure consistency in the approach of teams on the same development programme. Objective: This study aims to increase understanding of how development processes are tailored to meet the needs of large-scale offshore software development programmes, by focusing on artefact inventories used in the development process. Method: A grounded theory approach using 46 practitioner interviews, supplemented with documentary sources and observations, in nine international companies was adopted. The grounded theory concepts of open coding, memoing, constant comparison and saturation were used in data analysis. Results: The study has identified 25 artefacts, organised into five categories: feature, sprint, release, product and corporate governance. It was discovered that conventional agile artefacts are enriched with artefacts associated with plan-based methods in order to provide governance. The empirical evidence collected in the study has been used to identify a primary owner of each artefact and map each artefact to specific activities within each of the agile roles. Conclusion: The development programmes in this study create agile and plan-based artefacts to improve compliance with enterprise quality standards and technology strategies, whilst also mitigating risk of failure. Management of these additional artefacts is currently improvised because agile development processes lack corresponding ceremonies

Model of Critical Factors for Outsourcing Agile Development

Companies are beginning to combine outsourcing with Agile software engineering techniques with the goal of receiving the benefits of both – faster time to market, greater quality, and smaller costs. Since Agile was originally developed to work principally with small collocated teams, scalability of Agile to the enterprise, and simultaneous use of Agile and outsourcing are questions concerning applicability of Agile techniques to global business environments. This paper first summarizes current experience studies and research in Agile, enterprise Agile and Agile outsourcing, to identify factors likely to affect success on Agile projects. It then extends a model originally developed by Chow and Cao (2007) to account for these factors. Finally it outlines an experiment whose goal is to determine which of these factors drives successful projects that use both Agile and outsourcing

Scrum Game: An Agile Software Management Game

For the past few years, in their attempt to avoid the heavyweight bureaucracy of traditional project management methods such as the Waterfall model, companies have started incorporating agile methods (e.g. Extreme Programming, Scrum, Crystal) for their project development. These methods are characterised by their incremental and iterative delivery, their ability to incorporate change at any stage of the project lifecycle, as well as their small and co-located teams. Even though these methods are included in the syllabus of many software engineering modules at university level, many students currently feel more confident with traditional, rather than agile methods. Many employers find that recent graduates are not equipped with the desired skills of a software engineer because, even though they are knowledgeable in the different software engineering practices, they lack practical experience of these methods. The combination of these two factors show that the university’s approach to teaching software management methods is only theoretical and it does not give students the opportunity to apply them to their projects so they can get a better understanding of their use. The project developed the prototype of a computer game that simulates the use of the Scrum method within different projects, named Scrum Game. The game is supplementary material for a lecture course, and its purpose is to guide students through the Scrum lifecycle. Students can thereby get a small glimpse of the different phases of Scrum, the way that the different Scrum roles interact with each other, and the way that Scrum is used to implement real projects. In addition, the Scrum Game has an administrator mode enabling lecturers to view a log of the progress of all their students in the game. They can use this mode to create new projects or to alter existing ones by adding new tasks or problems, thereby adjusting the level of difficulty to the level of their students, or so that it fits their teaching. The web-based system was developed using PHP, MySQL, HTML, CSS, JavaScript, AJAX (jQuery) and Google Charts API. The system was thoroughly tested against the initial requirements and other system tests. The Scrum Game was evaluated by 22 peer colleagues reading for an MSc in Software Engineering at the University of Southampton, to identify whether the system achieved its goal of introducing students to the Scrum methodology and reaching a deeper understanding of its practical use during project implementation. The results of a questionnaire showed that little prior knowledge was assumed during the game, and that 86% of the participants felt that the game helped them learn more about Scrum. When asked, “Do you think that if this game was part of your Project Management module, would you get a better understanding about Scrum?” an impressive 95% (21 out of 22 participants) agreed that the game would be helpful, and rated the system 8 out of 10 on average

Uppskalning av agil systemutveckling: en flerfallstudie av ramverket Scaled Agile Framework

Agile software development methods have been extensively studied in the context for which they were originally developed: small, collocated and cross-functional teams. The proven benefits of agile methods have caused larger organizations and programs to take an interest in them, although adopting such methods at large is far more challenging. Several frameworks for adopting agile methods in a larger context exist but research surrounding them is scarce, consisting almost entirely of industry-produced experience reports. In this thesis we have studied the adoption of a popular scaling framework, the Scaled Agile Framework (SAFe), in two Finnish companies: Comptel, a telecom company; and NAPA, a company specialized in ship design and operation software. We sought to understand why these organizations chose to adopt SAFe, how they did it, what successes and challenges related to the adoptions the organizations encountered, and what effects the adoptions had. We reviewed existing literature in order to find out why and how other organizations had adopted SAFe. Using the results of the review we constructed a set of questions which we used in 16 interviews at the case organizations. The interviews spanned all organizational layers of SAFe: we interviewed people from leadership, middle management, and teams. The results of the interviews support many of the findings of the literature review, showing that planning the adoption in detail, training key personnel, and putting significant effort into the first planning session are key success factors in adopting SAFe. The interviews also showed that internal drivers of change are vital in establishing support for the adoption. Our results indicate that SAFe is a viable option for scaling agile software development, potentially improving visibility, collaboration and alignment.Agila systemutvecklingsmetoder blir allt vanligare och har studerats extensivt i den kontext för vilken de ursprungligen utformats: små självorganiserande och samordnade team. De påvisade fördelarna med agila metoder leder allt fler och större organisationer till att försöka implementera dem---dock växer svårighetsgraden i takt med organisationsstorleken. Ett flertal ramverk för uppskalning av agila metoder existerar, men akademisk forskning kring ämnet saknas nästan helt då majoriteten av litteraturen är fallstudier av varierande kvalité. I detta diplomarbete har vi studerat ibruktagningarna av det populära ramverket Scaled Agile Framework (SAFe) i två finska företag: Comptel, ett globalt telekommunikationsföretag; och NAPA, ett företag specialiserat på mjukvara för formgivning och anförande av fartyg. Vi ville förstå varför företagen valt att ibrukta SAFe, hur de gjort det, vilka problem och framgångsfaktorer de stötte på, samt vilka effekter ibruktaganden hade. Vi undersökte den existerande litteraturen för att få preliminära svar på de ovannämnda frågorna, och skapade en serie intervjufrågor på basis av resultaten. Dessa brukade vi i 16 intervjuer vid fallföretagen, där vi intervjuade ledare, mellanchefer samt medlemmar av team i ett försök att täcka alla de lager av organisationen som även SAFe täcker. Intervjuresultaten stöder många av litteraturstudiens resultat: noggrant planerande av ibruktagningen, utbildning av nyckelroller, samt en storsatsning på det första planeringstillfället är viktiga framgångsfaktorer för ibruktagandet. Intervjuerna visade också att interna pådrivare av förändringen är essentiella för att samla stöd för ibruktagandet. Våra resultat tyder på att SAFe är ett genomförbart alternativ för att uppskala agil systemutveckling, då det kan medföra ökad synlighet, ökat samarbete samt bättre anslutning mot ett gemensamt mål

OpenScrum: Scrum methodology to improve shared understanding in an open-source community

While we continue to see rise in the adoption of agile methods for software development, there has been a call to study the appropriateness of agile methods in open-source and other emerging contexts. This paper examines Scrum methodology adopted by a large, globally distributed team which builds an open-source electronic medical records platform called OpenMRS. The research uses a mixed method approach, by doing quantitative analysis of source-code, issue tracker as well as community activity (IRC logs, Mailing lists, wiki) in pre and post Scrum adoption, covering a period of 4 years. Later we conducted semi-structured interviews with core developers and followed it up with group discussions to discuss the analysis of the quantitative data and get their views on our findings. Since the project is "domain heavy", contributors (developers and implementers) need to have certain health informatics understanding before making significant contributions. This puts knowledge-sharing and "bus factor" as critical points of management for the community. The paper presents ideas about a tailored Scrum methodology that might better suited for open-source communities to improve knowledge-sharing and community participation, instead of just agilit

To schedule or not to schedule? An investigation of meetings as an inter-team coordination mechanism in large-scale agile software development

Coordination of teams is critical when managing large programmes that involve multiple teams. In large-scale software development, work is carried out simultaneously by many developers and development teams. Results are delivered frequently and iteratively, which requires coordination on different levels, e.g., the programme, project, and team levels. Prior studies of knowledge work indicate that such work relies heavily on coordination through personal modes such as mutual adjustment between individuals or through scheduled or unscheduled meetings. In agile software development processes, principles and work structures emerge during the project and are not predetermined. We studied how coordination through scheduled and unscheduled meetings changes over time in two large software development programmes relying on agile methods. Our findings include transitions from scheduled to unscheduled meetings and from unscheduled to scheduled meetings. The transitions have been initiated both bottom-up and top-down in the programme organizations. The main implication is that programme management needs to be sensitive to the vital importance of coordination and the coordination needs as they change over time. Further, when starting a program, we recommend to early identify the important scheduled meetings, as having enough scheduled meetings is important to develop a common understanding of domain knowledge