Agile project management and software development practices have become widely accepted in the industry and much of the currently published literature focuses on the developer's uptake of the methodology. Although it is commonly known that customers play a key role in Agile project success, the extent to which they can influence a project is not as well understood. This case study measures the contribution of customer involvement to the success of Agile projects. The study demonstrates that active customer participation is one of the top three factors for successful Agile projects. It also demonstrates that successful Agile projects have customers that are "knowledgeable, committed, collaborative, representative, and empowered". Similarly, the study shows that successful Agile projects have customers who transfer domain knowledge to project team members efficiently and effectively. The study concludes with recommendations for developers and customers that maximize an Agile project's potential for success. / text

No description available.

Transitioning to the Agile style of software development has become an increasing phenomenon among software companies. The commonly perceived advantages of Agile, such as shortened time to market, improved efficiency, and reduced development waste are among key driving motivations of organizations to Agile. Each year a considerable number of empirical studies are being published, reporting on successful or unfavorable outcomes of enacting Agile in various organizations. Reusing this body of knowledge, and turning it into a concise and reachable source of information on Agile practices, can help many software organizations which are at the edge of transition to Agile, dealing with the uncertainties of such a decision. One of the early steps of transitioning to Agile (or any other process model) is to confirm the adaptability of new process with the current organization. Various Agile adoption frameworks have proposed different checklists to test the readiness of an organization for becoming Agile, or to identify the required adaptation criteria. Transitioning to Agile, as a significant organizational initiative, is a strategic decision, which should be made with respect to key objectives of the target organization. Having a reliable anticipation of how a new process model will impact the strategic objectives helps organizational managers to choose a process model, which brings optimum advantage to the organization. This thesis introduces a framework for evaluating new Agile practices (compartments of Agile methods) prior to their adoption in an organization. The framework has two distinguishing characteristics: first, it acts strategically, as it puts the strategic model of organization at the center of many decision makings that should be performed during Agile adoption; and second, it is based on a repository of Agile practices that allows the framework to benefit from the empirical knowledge of Agile methods, in order to improve the reliability of its outcomes. This repository has been populated through an extensive literature review of empirical studies on Agile methods. The framework was put in practice in an industrial case, at one of the R&D units of Ericsson Company in Italy. The target R&D unit was proposed with a number of Agile practices. The application of framework helped R&D unit managers to strategically decide on the new process proposal, by having a better understanding of its strategic shortcomings and strengths. A key portion of framework’s analysis results were evaluated one year after the R&D unit made the transition to Agile, showing that over 75% of pre-adoption analysis results came to reality after the enactment of new process into the organization.

Today's product managers must quickly determine viable avenues for innovation while carefully balancing the costs and benefits involved. Agile methodologies are highly incremental and often seen as lacking in rigour and due diligence. This thesis explores the relationship between processes and tools that are commonplace for product managers versus those that tend to be reserved for researchers. A case study reveals key opportunities for the practices in each domain to inform each other, and further identifies the need for gaps in the tooling to be addressed. The study uses Think Together, a collaborative mobile application for interactive presentations with rich media content. The application supports individual action layers for each user and session replay, creating several challenging bottlenecks that jeopardize the scalability of the original implementation. A proposal for an alternative network configuration for communication to address these bottlenecks is examined from both a product management viewpoint and from a more traditional research perspective. A simulator is used as a means to analyze and evaluate the proposed configuration, revealing essential trade-o s in terms of efficiency and productivity. Unlike testing on real devices, the simulator is much more in line with agile processes, enabling more power and flexibility without the limitations of physical resources. However, the extent to which simulated results are practical in the real world, in particular to product managers, is an open question. We demonstrate how a lifecycle involving both traditional approaches to research and incremental implementation strategies in agile environments complements each other, and further identify current obstacles involved. / Graduate

Context: Agile practices have created its own mark on recent software development strategies. The significance of agile core values and principles attracted several organizations towards agile software development. Agile methods incorporate core values & principles, whereas agile practices define how agile methods are implemented in practice. However, it is still unclear, which combinations of agile practices are adopted in practice and how are they adapted. Objectives: In this research, our main aim is to find the combinations of agile practices that are most commonly adopted in practice, which includes identifying the practices which mostly appear together and finding the evidences for adaptations of agile practices. Methods: We have developed a survey to collect empirical evidence regarding agile practice adoption and adaptation. The survey is based on a framework consisting of a set of questions to determine agile practice adoption and adaptation. The framework was validated with researchers and practitioners through interviews. In order to identify the practices and possible adaptations we conducted a literature review. The sample population of the survey includes primarily project managers, developers, agile coaches and system types includes majority of information systems, commercial type of software, outsourced and embedded. Results: We have collected 109 responses with the survey. It is important to make the tradeoff between the length of the survey and quality of the responses, so, we needed to pose many questions with regard to the ways how the practices are tailored/adapted. We found that there are certain practices which were given highest priority and mostly appear together, certain practices appears only with particular combinations of practices. Regarding practice adaptations, the empirical findings show the adaptations of each individual practice. Moreover, regarding employee and customer satisfaction, the results indicate that there is a significant level of satisfied employees and customers with agile software development. A conceptual model of agile practices and performance is developed and presented to make a better understanding of implications for practice. Conclusions: During adoption there are certain set of agile practices that were given higher importance, given highest priority during selection and also mostly appears together. Moreover, there are certain practices which are considered as most important, but are given with less priority during selection by practitioners. Furthermore, the empirical findings supports practice adaption depends on change in context factors. Finally, it is interesting to see that almost all of the stakeholders in agile software development are satisfied with its nature.

The agile principles applied to software engineering include iterative and incremental development, frequent releases of software, direct stakeholder involvement, minimal documentation and welcome changing requirements even late in the development cycle. The Agile Requirements Engineering applies the above mentioned principles to the Requirements Engineering process. Agile Requirements Engineering welcomes changing requirements even late in the development cycle. This is achieved by using the agile practice of evolutionary requirements which suggests that requirements should evolve over the course of many iterations rather than being gathered and specified upfront. Hence, changes to requirements even late in the development cycle can be accommodated easily. There is however, no real process to the agile approach to Requirements Engineering. In order to overcome this disadvantage, we propose to adapt the Requirements Generation Model (a plan-driven Requirements Engineering model) to an agile environment in order to structure the Agile Requirements Engineering process. The hybrid model named the Agile Requirements Generation Model is a soft-structured process that supports the intents of the agile approach. This model combines the best features of the Requirements Generation Model and Agile Software Development. / Master of Science

Som svar på ökade krav på IT-relaterade produkter har de så kallade agilautvecklingsmetoderna uppfunnits. Förespråkare för agila metoder hävdar att bättreresultat kan uppnås genom minskning av tydliga, strikta kravspecifikationer,dokumentation och planering inom projekt till förmån för ett större fokus på småsjälvorganiserande arbetsgrupper och ett iterativt utvecklingssätt. De värderingar och den praxis som är förknippade med agila metoder ter sig vara meranpassade för små företag , på grund av den tunga betoningen på små självständigagrupper och brist på formell styrning och kontrakt. Syftet med detta examensarbete harsin grund i den oppositionen. Vilka omständigheter uppstår när en avdelning på ett stortföretag vill omvandla sin projektmetodik till en agil? Specifikt utförs en fallstudie på enutvecklingsavdelning ett stort IT-företag med över 69 000 anställda världen över. I det studerade fallet visar resultaten att intresset för agila metoder är korrelerat mednärheten till mjukvaruutvecklingsprocessen . Mjukvaruutvecklarna i studien anser att detfinns stora problem med dagens utvecklingsprocess och fann bristen av flexibilitet ikravhantering samt begränsat kundengagemang oerhört frustrerande. Andragruppmedlemmar var mindre bekymrade. Genom att anamma företagets lednings samtkundens synsätt blev det klart att mer agila utvecklingsprocesser försvårar strategiskplanering av företags totala projektportföljer. Författarna föreslår att en agil transformation inom ett stort företag kräver starkaförespråkare inte bara från utvecklarlaget utan även från företagets affärssida samtkunden. Anammandet av agila metoder ställer stora krav på tillit i relationen mellanutvecklingsteam och ledning samt mellan utvecklingsteam och kund, eftersomsamarbetet till lägre grad bör styras av strikta kravspecifikationer som speglas i fastakontrakt.

Dans l'ingénierie avionique, les tests d'intégration sont cruciaux : ils permettent de s'assurer du bon comportement d'un avion avant son premier vol, ils sont nécessaires au processus de certification et permettent des tests de non-régression à chaque nouvelle version d'un système, d'un logiciel ou d'un matériel. La conception d'un test d'intégration coûte cher car elle mêle la réalisation de la procédure, le paramétrage de nombreux outils couplés au banc de test ainsi que l'adressage des interfaces du système testé. Avec des procédures de test écrites en langage naturel, l'interprétation des instructions d'un test lors de son rejeu manuel peut provoquer des erreurs coûteuses à corriger, en raison notamment des actions précises à entreprendre lors de l'exécution d'une instruction de test. La formalisation et l'automatisation de ces procédures permettraient aux équipes de testeurs de se concentrer sur la réalisation de nouveaux tests exploratoires et sur la mise au point de tels systèmes au plus tôt. Or, un système avionique est composé de plus d'une centaine de systèmes embarqués, chacun concernant des compétences spécifiques. Notre contribution est alors un framework orchestrant les langages de test dédiés à l'intégration de systèmes avioniques dans une vision Agile. Nous introduisons tout d'abord le concept de langage spécifique à un domaine (Domain Specific Language ou DSL) et montrons comment nous l'utilisons pour la formalisation des procédures de test dédiées à un type de système particulier. Ces langages devront pouvoir être utilisés par des testeurs avioniques qui n'ont pas forcément de compétences en informatique. Ils permettent l'automatisation des tests d'intégration, tout en conservant l'intention du test dans la description des procédures. Puis, nous proposons l'approche BDD (Behavior Driven Development) pour valider l'intégration de systèmes par scénarios comportementaux décrivant le comportement attendu de l'avion. Nous nommons Domain Specific Test Languages (DSTL) les langages utilisés par les testeurs. A chaque système (ATA ou Air Transport Association of America) correspond un DSTL métier. Un premier DSTL concernant les systèmes de régulation de l'air a été développé entièrement en tant que preuve du concept à partir de procédures existantes pseudo-formalisées. L'expérimentation s'est poursuivie avec les calculateurs standardisés IMA (Integrated Modular Avionic) pour lesquels les procédures de test sont décrites en langage naturel et sont donc non automatisables. A partir d'un corpus de procédures, nous proposons un premier processus empirique d'identification des patrons de phrases peuplant un DSTL. Le corpus fourni est composé de dix procédures totalisant 108 chapitres de test et 252 tests ou sous-tests comportant au total 3708 instructions pour 250 pages Word. Rendre agile ces tests d'intégration consiste à proposer une approche collaborative pour formaliser un DSTL que ce soit pour les patrons de phrase de la grammaire concrète ou pour les patrons de transformations vers des langages exécutables. / In avionics engineering, integration tests are crucials: they allow to ensure the right behavior of an airplane before his first flight, they are needed to the certification process and they allow non-regression testing for each new version of a system, of a software or of a hardware. The design of an integration test is expensive because it involves the implementation of the procedure, the configuration of tools of the bench and the setup of the interfaces of the system under test. With procedure written in natural language, the interpretation of statements of a test during the manual execution can lead to mistakes that are expensive to fix due to accurate actions needed to perform a statement. The formalization and the automation of those procedures allow testers team to focus on the implementation of new test cases. First of all, we introduce Domain Specific Language (DSL) and show how we use it to formalize tests procedures dedicated to a kind of system. Those languages should be able to be use by avionic testers which do not necessarily have programming skills. They allow test automation, while maintaining test intention in the test description. Then, we proposed a BDD (Behavior Driven Development) approach to validate the integration of systems thanks to behavioral scenarios describing the expected behavior of the airplane. Our contribution is a framework which orchestrate DSLs dedicated to integration test of avionic systems in an Agile vision. We named Domain Specific Test Languages (DSTL), languages used by expert testers. For each system (ATA ou Air Transport Association of America) corresponds a DSTL business. A first DSTL about the validation of airflow control systems has been developed as a proof of concept from existing procedures pseudo-formalized. The experimentation has been continued with IMA (Integrated Modular Avionic) calculators for which test procedures are written in natural language and thus are not automatable. From a corpus of procedures, we propose a first empirical process to identify sentence patterns composing the DSTL. The corpus provided is composed by ten procedures totaling 108 test chapters and 252 tests or subtests involving 3708 statements for a total of 250 Word pages. Make Agile integration tests in this context consist to propose a collaborative approach to formalize a DSTL and to integrate it in the orchestration framework to generate automatically the glu code.

Šiame magistro baigiamajame darbe analizuojama Lietuvos IT įmonės, kuriančios valstybės informacines sistemas, galimybė pakeisti nuoseklųjį PĮ kūrimo metodą į Agile. Šio darbo tikslas yra išsiaiškinti, kokį poveikį įmonės veikloms: PĮ testavimui ir dalyvavimui viešuosiuose pirkimuose, turės įmonės perėjimas prie naujo metodo. Darbe analizuojami įmonės vidiniai procesai (testavimas) ir įmonės išorinės aplinkos (įstatymų ir viešųjų pirkimų proceso) poveikis jiems. Remiantis kokybiniais tyrimo metodais surinkta informacija, darbe apžvelgiama Agile metodo ideologija, veikimo principai ir nauda, kurią gali atnešti perėjimas prie Agile. Taip pat darbe plačiai analizuojama testavimo, kaip svarbios kokybės gerinimui veiklos, skirtumai tarp nuoseklaus ir Agile metodų bei viešųjų pirkimų IT paslaugų sferoje problematika. Remiantis atlikta įmonės veiklos ir literatūros analize yra aprašomi rekomenduojami pokyčiai veikloje, kuriuos įmonė turėtų atlikti pasiruošdama Agile metodo įvedimui ir pilotinio projekto inicijavimui. Tyrimas parodė, kad dėl viešųjų pirkimų proceso specifikos įmonėje Agile metodas gali būti taikomas su tam tikrais apribojimais. Nepaisant šių apribojimų, Agile metodas tinka įmonės tikslam siekti ir įmonė gali išnaudoti Agile privalumus gerindama savo veiklos rezultatus. / This master thesis analyzes the ability of IT company developing IS for the public sector to adopt Agile ISD methodology instead of the currently practiced traditional (waterfall) one. The aim of this work is to identify impact of moving to Agile for two company`s processes: the (internal process of) software testing and (the external process of) tendering in the procurement process. Specifically, the impact of external environment (law and procurement process) on company’s business is analyzed. Using qualitative research methods, the author presents an overview of the Agile approach and the principles and benefits of moving to Agile. Other important contributions of this work include analyzes of testing as important tool of quality improvement, the differences between Waterfall and Agile testing and compatibility of Agile method with the public procurement process. The recommendations based on the analysis of company`s activities and the literature what should be done before starting a pilot project and moving the company to Agile methodology are given. The results of research show that the company can`t use the “original” Agile methodology without limitations. Despite these limitations, the Agile method suits company`s goals and the company can exploit the benefits of Agile ISD methodology to improve its results.

The objective of the study was to generate a ‘theory’/ ‘hypothesis’  on the important factors to focus on in implementing agile project methods in globally distributed teams. Using the grounded theory method, five key categories emerged from the so-called theoretical sampling, which entails the joint collection of data, coding and analysis. The study involved 33 individuals in four different companies, three in the Philippines and one in Sweden. The data collected for this thesis consisted of individual interviews in the Philippines and Sweden (Sept-Dec 2014), focus group sessions, observations of formal agile practices and experiences in the substantive area, conducted in the Philippines during the period Sept-Nov 2014.  The following five key categories emerged as the main concerns of the individuals involved in implementing agile project methods in globally distributed teams in software development projects:  (i) Working Communication, (ii)  Self-organizing Teams, (iii) People-centric organization, (iv) Continuous Learning and (v) Sustaining Infrastructure.  The respondents meant that these concerns should be addressed and resolved in such a way that the implementation of Agile project methods would resemble the case of a collocated Agile project team. The key categories, their fundamental characteristics and the subconcepts behind them were presented and analyzed in relation to the empirical data.The analysis included reported incidents and direct citations from the respondents, focus groups and from observations during the field study, in order to shed light on the process used to arrive to the categories, as well as explain the characteristics of the concepts in the emerging ‘grounded hypothesis’.