Agile software development methods are often advertised as a contrast to the traditional, plan-driven approach to software development. The reported and argued benefits on software quality, coordination, productivity and other areas are numerous. The base of empirical evidence to the claimed effects is however thin, and more empirical studies on the effects of agile software development methods in different contexts are needed, especially in large-scale, industrial settings. The purpose of the thesis was to study the impact of using agile principles and practices in large-scale software development projects at Ericsson and it was carried out as a multiple-case study of two projects. One of the projects had implemented a limited number of agile software development practices and was largely plan-driven, while the other project had fully adapted its organization and product design for agile software development. Propositions of possible effects of the use of agile principles and practices in the two projects were generated by a literature review. Empirical data was then collected from online surveys of project members, internal documents, personal contact with key project members and a collection of metrics, to study the presence of the proposed effects. The study was focused on eight different areas: internal software documentation, knowledge sharing, project visibility, pressure and stress, productivity, software quality and project success rate. Agile principles and practices were found to: Lead to a more balanced use of internal software documentation, when supported by sound documentation policies. Contribute to knowledge sharing. Increase project members’ visibility of the status of other teams and the entire project. Increase coordination effectiveness and reducing the need for other types of coordination mechanisms. Increase productivity. Possibly increase software quality. Additionally, the study showed that internal software documentation is important also in agile software development projects, and cannot fully be replaced with face-to-face communication. Further, it was clear that it’s possible to make a partial implementation of agile principles and practices, and still receive a positive impact. Finally, the study showed that it’s feasible to implement agile principles and practices in large-scale software development. It therefore contributes to understanding the effects of agile software development in different contexts.

In this master thesis two different worldviews are compared: a mechanistic, and an organic worldview. The way we think the world and the nature work reflects on how we think organizations work, or how they ought to work. The mechanistic worldview has dominated our way of thinking since the seventeenth century, and it compares the world with a machine. The organic worldview could use a number of different metaphors, but the one addressed in this thesis is complexity theory. Complexity theory is related to chaos theory and is concerned with complex adaptive systems (cas). Complex adaptive systems exist everywhere and are systems such as the human immune system, economies, and ecosystems. What complexity theory tries to do is to understand these systems—how they arise, how they function and how order emerge in them. When looking at complex adaptive systems you can’t just look at the different parts. You must take a more holistic view and look at the whole and the interaction of the parts. If you just look at the parts you will miss the emergent properties that have emerged as the system has self-organized. One prominent aspect of these systems is that they don’t have any central authority, but somehow order do arise. In relation to organizations, complexity theory has something to say about almost all aspects of organizations: from what kind of leadership is needed, and how teams should be organized to the physical structure of the organization. To understand what complexity theory is and how to relate that to (software developing) organizations is the main focus of this thesis. Scrum is an agile and lightweight process which can be applied on development projects in general, but have been used in such diverse examples as software development projects, marketing programs, and business process reengineering (BPR) initiatives. In this thesis Scrum is used as an example of how to apply complexity theory to organizations. The result of the thesis showed that Scrum is highly influenced and compatible with complexity theory, which implies that complexity theory is of some use in software development. However, there are more work to be done to determine how effective it is, how to introduce it into organizations, and to explore more specific implementations. This master thesis should give the reader a good understanding of what complexity theory is, some specific issues to consider when applying complexity theory on organizations, and some specific examples of how to apply complexity theory on organizations.

The basic aim for any software development organization is to maximize value creation for any given investment. To amplify and speed up value creation efforts, Agile Software Development has gained much popularity during the last decade as a response to a volatile and disruptive market. In an Agile environment, the team focuses on lightweight working practices, constant deliveries and customer collaboration rather than heavy documentation and inflexible processes. However, the Agile way of working has complicated how an organization can control and evaluate the process; allowing organizations to believe that all Agile processes is the ideal process. This master thesis was conducted as a case study at Sectra ImIT, an Agile Health IT company working with Imaging and IT solutions that is currently in an early phase of introducing metrics in the System Development process. The purpose of this thesis was to investigate and suggest how the organization could use metrics to control and evaluate value creation in the System Development process. It also aimed to provide strategic recommendations to such an organization how they could continue their work with implementing and using metrics. The descriptive and exploratory purpose of this study was realized through unstructured and semistructured interviews with people involved in the process as well as observations. One of the major findings in this thesis is related to a missing feedback loop from defects occurring at customer site to the internal System Development process. Therefore, this study developed and implemented a concept to generate this feedback. The concept builds on defect information that can be used both to generate feedback and statistics for evaluation. The second major finding in this study is related to the identification of barriers to why the organization is not using metrics in teams to control and evaluate the process. Based on these findings, the authors presented several recommendations that should be considered to create a culture where teams are using metrics to learn more about the process. The first recommendation is that the organization should set guidelines among teams of what should, and is desired to be evaluated with focus on information need. Secondly, metrics need to be higher prioritized through directives from management granting team’s resources to manage metrics, which at the same time provides incentives that the organization believe metrics could improve their work. Thirdly, based on the company context, teams should identify metrics based on an information need derived from their prioritizations, changes, decisions and what is currently left unanswered. Finally, metrics should primarily be used to provide means for discussion and provide feedback with focus on trends rather than absolute numbers. / Det huvudsakliga målet för ett godtyckligt företag inom mjukvaruutveckling är att maximera det värde som skapas i varje enskild investering. För att förstärka och snabba upp värdeskapande har Agil mjukvaruutveckling växt i popularitet som en respons mot volatila och osäkra marknader. I en Agil miljö fokuserar grupper på ”lättviktade” arbetsmetoder, kontinuerliga leveranser och kundsamarbeten över det tidigare arbetssättet som bestod av mycket dokumentation och inflexibla processer. Samtidigt har det Agila arbetssättet gjort det svårt för organisationer att kontrollera och utvärdera processen, vilket har resulterat i att organisationer antar att deras Agila process är ideal och välfungerande med avsaknad av belägg för det. Detta examensarbete genomfördes som en fallstudie på Sectra ImIT, ett Agilt företag inom medicinsk teknik med fokus på bildhanteringssystem och IT lösningar. Företaget är i en tidig fas av att undersöka och introducera mätetal i systemutvecklingsprocessen, där syftet med examensarbetet var att utvärdera och föreslå hur organisationen kunde använda mätetal för att kontrollera och utvärdera värdeskapande i processen. Därtill ämnade studien även att ge strategiska förslag på hur företaget i framtiden kan arbeta med att implementera och använda sig av mätetal. Det deskriptiva och explorativa syftet realiserades genom ostrukturerade och semi-strukturerade intervjuer samt observationer med människor som dagligen arbetade inom processen. En iakttagelse var kopplad till avsaknaden av återkoppling mellan de defekter som uppkommer ute hos kund tillbaka till systemutvecklingsprocessen. Detta resulterade i ett koncept som utvecklades och implementerades av författarna med syfte att skapa återkoppling och möjlighet till statistisk utvärdering av processen som helhet. Den andra iakttagelsen berörde ett antal anledningar till varför organisationen inte använder mätetal i teams för att kontrollera och utvärdera processen. Baserat på en analys av dessa presenterar författarna flertalet rekommendationer som företaget borde ta hänsyn till för att skapa en kultur som främjar användandet av mätetal för att skapa ytterligare förståelse för processen. Den första rekommendationen är att organisationen bör diskutera riktlinjer gemensamt för teams gällande vad som anses önskvärt att utvärdera, med fokus på informationsbehov. Därtill bör organisationen uppmana teams till att allokera mer resurser på mätetal, vilket samtidigt ger incitament att det är något företaget tror kan hjälpa teams att bli bättre. Utifrån företagets kontext bör teams själva tillåtas att identifiera mätetal baserat på deras informationsbehov som ett resultat av exempelvis prioriteringar, förändringar, beslut och vad som för tillfället är obesvarat. Slutligen ska mätetal användas i huvudsak som en grund för diskussion och feedback med fokus på trender snarare än att uppnå specifika mål.

No description available.

Agile software development methodologies these days are not used only in small enterprises or startups, they are getting spread around large enterprises as well. An evidence of this fact could be, that Scrum is nowadays the most commonly used approach to software development. So this thesis focuses on usage of agile approaches, Scrum methodology in particular, in large enterprises. Author presents an approach called Behaviour Driven development and proposes how this approach could help dealing with imperfections or barriers of Scrum when used in large enterprises. The major outcome of this thesis is author's own methodology called ScrumFlow, based on Scrum methodology and extended by Behaviour Driven Development approaches. ScrumFlow methodology is published on a website and available for free.

This study set out to determine various aspects of the agile approaches to software development. These included an investigation into the principles and practices driving these methodologies; determining the applicability of these approaches to the current software development needs; determining whether these methodologies can comply with software engineering standards (as set out for example by ISO); investigating the feasibility of these approaches for the telecommunication industry; establishing whether practitioners are reaping the benefits that are advertised by agile proponents; and attempting to discover short-comings of the agile paradigm. This dissertation examines the aforementioned issues and tries to provide answers to them. It is argued that: Agile software development is suited to projects where the system evolves over the life cycle of the project. These methodologies are intended to seamlessly handle changing requirements. Thus, using an agile approach might provide a competitive advantage in developing e-business solutions which are tightly coupled with the business strategy and needs. It is shown that agile methodologies can comply with software engineering standards such as ISO 12207:1995 and ISO 15288:2002. Furthermore diligent application of certain agile methodologies may result in a level 3 Capability Maturity Model (CMM) grading. Evidence from the feedback of a case study conducted on an XP project team, supports the view that XP, and agile in general, does indeed live up to its 'promises'. However, some potential problem areas were identified that should be kept in mind when implementing these methodologies. Finally, an in situ investigation suggests that there are a number of projects in the telecommunication industry that will benefit from the agile approach and its practices. / Dissertation (MSc)--University of Pretoria, 2005. / Computer Science / unrestricted

For the last decade the IT industry has been transitioning to Agile software development due to the impending need for a more flexible development process. China’s IT industry is growing drastically, but to stay competitive in the global market the Chinese organizations have to constantly adapt and reorient to today’s market needs. The purpose of this study is to determine if Agile methodologies and practices are suitable for the software industry in China. The study describes the fundamentals of Agile software development and analyzes the success factors of Agile adoption. Further analysis of Agile and its relation to culture is conducted, as well as an analysis of China, its national and organizational culture, and its software industry. Several hypothesis regarding potential barriers of Agile adoption in China were constructed to guide the design of the survey questionnaire. In the analysis of the survey data it was concluded that the communication aspect does pose as a barrier for Agile adoption in China, whereas the cognitive, social, organizational culture, competence and recruitment and managerial aspects all are concluded to not be barriers for Agile adoption. The overall result indicates that Agile methodologies are suitable, and should be favorable for the software development organizations in China. / IT-branschen har under det senaste decenniet anammat Agila metoder för att fylla ett behov av en mer flexibel utvecklingsprocess. Kinas IT-industri växer kraftigt, men för att öka sin globala konkurrenskraft måste den utvecklas och ständigt kunna anpassa sig efter marknadens behov. Syftet med denna studie är att avgöra om Agila metoder och arbetssätt är lämpliga för den Kinesiska mjukvaruindustrin. Studien beskriver grunderna i Agil mjukvaruutveckling och analyserar viktiga faktorer vid införandet av Agila metoder. Vidare undersöker den Kinas kultur, organisationskultur samt dess mjukvaruindustri. I studien utformades några hypoteser om möjliga hinder vid anammandet av Agila metoder, som vidare användes för utformandet av en enkätundersökning. I analysen av enkätdata konstaterades det att kommunikationsaspekten är ett hinder, medan de kognitiva, sociala och organisationskulturella aspekterna samt kompetens- och rekryteringsaspekten och organisationsledningsaspekten samtliga ej anses som hinder för införandet av Agila metoder. Slutsatsen är att Agila metoder är lämpliga, och bör adopteras av kinesiska mjukvaruföretag.

Requirements, key artifacts of requirements engineering, are a fundamental part of any software development, used by the different software development roles in their activities, such as designing the interface for a feature, its development, and the creation of test cases made by testers. This study aims to investigate the impact of misalignment in the use, understanding, and intent of requirements between the requirements engineers that create the requirements and other software roles that use them in their work activities and betweendevelopers and testers in their software development and testing activities. The impacted areas that this study focuses on are the work activities of the different roles involved with requirements in the development process, their workload, and their well-being and morale.The two research objectives are:i) How do software development practitioners define the quality of requirements?ii) How do the perceived quality of requirements impact the work of the different roles involved in the software development process?This study was performed as a descriptive interview study that follows the case study guidelines written by Runeson and Höst [14] at a sub-organization of a Nordic bank that developed their own web and apps. The data collection comprises interviewing 20 practitioners:requirements engineers, developers, testers, and newly employed developers, with fiveinterviewees from each group.The results of this study show that there are, in fact, different views across different roles of what makes a requirement good. There are also some similarities between the general characteristics described by the practitioners that they perceive make requirements good and the characteristics described in the ISO [21] and IREB [26] standards.The practitioners stated that, in general, they experienced negative feelings, more work,and overhead communication when they worked with requirements they perceived to be bad. The practitioners also described in general positive effects on their work and feelings when they worked with requirements that they perceived to be good.A conclusion that can be drawn from the study is that the quality of requirements and the requirements engineering process matter to software development and can have big impacts on the morale and effectiveness, and efficiency of the different roles that work with the requirements.

Context: Acceptance testing is an important activity that verifies the conformance of a system to its acceptance criteria. It aims to provide a detailed communication of domain knowledge and is used to evaluate whether the customer requirements are met. Existing literature lacks empirical evidence for acceptance testing. Especially in the context of industry practice, it is not in the authors' consideration, except for a few studies, where the authors have investigated the state of practice in a specific domain. Objective: This study aims to recognize the state of research and practice of acceptance testing in Agile Software Development and investigate the similarities and differences in both perspectives. The study contributes to identify the industry-academia gap in the context of acceptance testing. Research Method: To identify the acceptance testing practices and challenges from research, I have conducted a literature review. For the industry perspective on acceptance testing practices and challenges, I have conducted an interview-based survey of the practitioners working in the Agile Software Development environment. I followed the snowball search strategy to search the primary studies, whereas to select the respondents, I used the convenience and snowball sampling method. For data analysis, I followed the approach of thematic synthesis. Results: The results of this thesis are the outcome of a literature review of 20 selected studies and an interview-based survey with 12 practitioners representing10 companies. I identified acceptance testing practices and challenges from research and industry. In the research, the most recommended form of acceptance testing is acceptance test-driven development (ATDD), and the majority of the studies are referring to the use of FIT for acceptance testing. Customer involvement in different phases of acceptance testing is recommended in research. From the interviews, I come across that acceptance testing is manual at large in the industry, and the most challenging aspect is the customer’s involvement. Conclusions: From the findings of this thesis, it is concluded that there is a gap between the research and industry perspective of acceptance testing practices. Currently, acceptance testing in the industry is mostly manual, the research is not focusing on this aspect of acceptance testing. Despite the differences, there are some commonalities as well. Especially, most challenges of acceptance testing are similar in both perspectives. Researchers have to consider the commonalities, and they have to look at how they can minimize the acceptance testing challenges from the perspective of the industry.

Distribuerade agila mjukvaruutvecklings-metoder har aldrig varit mer populärt. Att kunna arbeta hemifrån för att undvika den dagliga pendlingen eller för att samarbeta med utvecklare utomlands har aldrig varit enklare. Tredjepartsverktyg som Zoom och Google Meet förenklar kommunikationsprocessen, och med introduktionen av verktyg som Visual Studio’s “liveshare” som möjliggör realtids-kodning, har agila metoder verkligen flyttat ut från kontoren. Dock är en av de viktigaste komponenterna av att arbeta agilt att arbeta ansikte mot ansikte, vilket innebär att en av de effektivaste metoderna för kommunikation nu förloras när man flyttas till att arbeta med distribuerade metoder. Att övergå till nya metoder är aldrig enkelt, och när företag övergår till en distribuerad framtid kan mjukvaruutvecklare potentiellt drabbas av denna förändring i miljö och metod. Om företag har riktlinjer för övergången till distribuerade metoder kan det potentiellt göra förflyttninen enklare.Problemet är att det inte finns några sådana riktlinjer. Syftet med denna rapport är att skapa riktlinjer med målet att hjälpa organisationer övergå till distribuerade agila metoder från lokala agila metoder. Metoden i denna rapport är en kvalitativ utforskande litteraturstudie tillsammans med utforskande intervjuer som utforskar de positiva och negativa erfarenheterna utvecklare möter när de gör en övergång till distribuerade metoder. Litteraturstudien användes för att formulera forskningskriterierna och intervjufrågorna. Totalt tillfrågades åtta personer som hade erfarenheter av att göra en övergång till distribuerade agila metoder. Dessa intervjuer resulterade i tre generella riktlinjer som kan användas för att förenkla övergången mellan lokala-och distribuerade agila metoder. / Distributed agile software development has never been more popular. Being able to work at home to avoid the commute or simply collaborating with developers abroad has never been easier. Third party tools such as Zoom and Google Meet makes communication easier than ever, and with the introduction of Visual Studio’s live share that enables real-time collaborative coding, distributed agile development truly has moved out of the offices. Yet, one of the core components of the agile working method is working face to face, meaning that one of the most efficient methods of communication is lost upon moving development into a distributed setting. Transitions towards new methods and settings are never easy, and as companies transition towards a remote and distributed future, software developers are potentially burdened by this change in environment. If companies had access to guidelines they could potentially experience a smoother transition. The problem is that there currently do not exist such guidelines. The purpose of this report is to create such guidelines with the goal of helping organizations transition towards distributed agile methods. In this report, the method utilized is a qualitative and explorative literature study, coupled with interviews aimed to explore the positive and negative experiences developers face when transitioning towards distributed methods. A literature study was used to help formulate the research criteria and the interview questions. In total, eight people that had experienced a recent transition towards distributed agile methods were interviewed. These interviews resulted in three general guidelines that can be used to ease the transition between a local and distributed work environment.