Denna uppsats studerar förutsättningarna för att implementera mjukvaruutvecklings - metoden Continuous Delivery (CDE). Problemställningen som lade grunden för studien, var att det inte finns någon enhetlig standard för CDE. Studien ämnade att undersöka om detta innebar att metoden har varierande innebörd inom olika företag och om de således, i viss mån tillämpar skilda tillvägagångssätt med metoden. Ytterligare en aspekt var att se vilka utmaningar företagen upplevde vid övergången till CDE. Att undersöka om det var främst organisatoriska eller utvecklingsrelaterade problem som upplevts. Samt hur de hanterade kommunikation och tillit till medarbetarna och arbetet inom verksamheten under förändringen. För att belysa problemen, beskrevs teori med fokus på organisatoriska och tekniska utmaningar med Continuous - metoderna: Continuous Integration (CI), Continuous Delivery (CDE) och Continuous Deployment (CD). Teorikapitlet samt tidigare studier inkluderade även forskning om kringliggande koncept som DevOps och LEAN. Metoder, vilka kan underlätta implementationen av CDE. Datainsamlingen genomfördes med öppna individuella intervjuer med representanter från sex stycken företag, där de delade med sig av deras erfarenheter av och syn på CDE. Studien visar att anledningen till att företag väljer att arbeta med CDE, är att de vill gå från utvecklingsmetoder, vilka kräver många beslut inför varje förändring, till ett mer flexibelt arbetssätt där de funnit fördelar som: bättre kvalitet på det som levereras, snabbare leverans av affärsvärde till kunder samt kortare feedback - loopar. Företag som gör en övergång till CDE väljer dessutom ofta att inte automatisera hela vägen ut till produktion, enligt CD, då de ser utmaningar med att säkra kvalitén. Studien har identifierat ett antal faktorer som viktiga för en framgångsrik implementering av CDE, samt faktorer som kan resultera i en svår övergång. / This thesis studies the conditions needed for implementing the software development method Continuous Delivery (CDE). The problem identified for the study, is that there is no standardized approach for CDE as of today. The intentions of the study were to determine whether this means that the method will have a shifting tenor within different companies, and if so, will these companies implement the method with different approaches. Another aspect was to determine which types of challenges the companies were faced with during the transition towards CDE. To review whether the challenges were foremost organisational or development related. And how the organisations handled the communication and trust towards the co-workers and the development work within the organisation during the change towards the method. To highlight these issues, we presented theories with focus on organisational and technical challenges with the different Continuous practices were made. The practices being: Continuous Integration (CI), Continuous Delivery (CDE) and Continuous Deployment (CD). The theory chapter and former studies also contains research about surrounding concepts such as DevOps and LEAN methods, which can aim to facilitate the implementation of CDE. The empirical data collection was performed using open individual interviews with informants from six different companies, where they shared their experience and views on the method CDE. The study demonstrates that the reason organisations chose to implement CDE, is that they want to transform from software development methods, which requires a lot of decision making for any change, to a more flexible work procedure, in order to experience benefits such as: better quality of what is delivered, faster deliveries of business value to the customers and faster feedback-loops. Organisations that make the transition towards CDE also tend not to automate all the way to production, as in agreement with CD, this because the organisations identify challenges with assuring that the quality is sufficient. The study has identified a number of factors that are essential for a successful implementation of CDE, along with factors that may result in a less successful implementation.

IT-system utvecklas idag ofta i globalt distribuerade organisationer. Detta görs för att möta de krav som ställs från omgivningen samt för att finna specialkompetens. En global organisation kan medföra distribuerat arbete, alltså att utvecklingsgrupper sprids över flera platser. Ett problem med detta kan vara att få alla delar av verksamheten att arbeta mot ett gemensamt mål. Koordination – att hantera beroenden mellan element i komplexa organisationer för att möjliggöra effektivt arbete mot ett gemensamt mål – blir då en viktig aktivitet. Att kommunicera över distans i den takt organisationen kräver är en omöjlighet utan att implementera informations- och kommunikationsteknik (IKT) – digitala verktyg med fokus på kommunikation och spridandet av information. Vi vill i denna uppsats undersöka hur koordination sker i distribuerade IT-projekt, samt vilken roll IKT-stöd har vid koordination av distribuerade IT-projekt. Syftet med denna studie är att bidra med kunskap gällande användandet av IKT-stöd för koordination i distribuerade IT- projekt. Vi genomför denna kvalitativa fallstudie hos IFS World Operations AB – en global affärssystemsleverantör. Data har samlats in genom intervjuer med personer i olika roller inom det undersökta it projektet. Vi har ställt de empiriska resultaten i relation till teorier inom områden som koordination, IT-projekt samt IKT. Våra resultat visar att koordination i agila, distribuerade IT-projekt sker på två nivåer; strategisk samt operationell koordination. Dessa syftar att uppnå mål på olika nivåer. Vi har också kunnat dela in koordinationshandlingar i tre typer utvecklade från teori och observationer; ömsesidig anpassning, framväxande standardisering och organisationsförvaltning. Vi kan även sluta oss till att IKT-stöd främst förhåller sig till koordination på tre sätt i ett distribuerat IT-projekt; möjliggörande, medierande samt begränsande. Med stöd av de ovan presenterade resultaten har vi tagit fram faktorer vi funnit påverka möjligheten att koordinera IT-projekt. Dessa är; gruppdynamik, graden av distribution, fasta utvecklingsgrupper, utveckla teknik tillsammans med organisation samt standardiserade kommunikationskanaler. / Information systems are often developed in globally distributed organizations. Many times the reason for being distributed is to meet requirements and demands from the organizations surrounding and to acquire a specialized set of skills. Global organizations may choose to work distributed, which means that development teams are spread out over multiple locations. This can create problems; how do you make all parts of the organization work together towards a common goal? Thus, coordination – The management of interdependent elements in a complex organization so as to enable them to work together effectively toward a specific goal – becomes important. Long distance communication using information and communication technology (ICT) – digital tools with the purpose of endorsing communication and knowledge – is required to coordinate between locations. In this thesis we examine how coordination is performed in distributed IT-projects. We will also address the role that information and communications technology plays in coordination of these projects. The purpose of the study is to contribute with knowledge in the area of using ICT tools for coordinating distributed IT-projects. This qualitative case study was conducted in cooperation with IFS World Operations AB – a global provider of an Enterprise Resource Planning system. Our empirical data has been collected using five interviews, all with different types of roles from within IT-projects. The data has then been put in relation to theories concerning coordination, IT-projects and ICT. Our findings show coordination in distributed, agile software development projects is working on two levels; strategic and operational coordination. The difference lies with the motivation to complete goals on different levels of the organization. We can also conclude that there are three different kinds of means to carry out coordination; Mutual Adjustment, Emerging standardization and organizational management. Concerning the role of ICT in the coordination of distributed IT-projects we have found it to be threefold; enabling, mediating and limiting. Based on these findings we conclude this study by presenting five factors that influence the ability to coordinate distributed IT-projects. These are: group dynamics, level of distribution, fixed development teams, parallel development of technology and organization and standardized communication channels.

This paper is a degree project on the C-level, 15 points at University West, Department of Business and IT dept. Informatics. This study is about agile methodology and its impact on IT projects. Requirements management is a process within an IT project, where customer has certain requirements that must be met by an IT system. The difference between the traditional and agile development is in the requirements management process and it can cause problems in a project. Requirements change during IT projects and to manage requirements, agile principles apply. Specification and planning in the waterfall model is time consuming. Working agile means to have close contact with the client. This minimizes the risk of project failure. With agile methods, functions can be developed at a faster rate and the customer receives prompt delivery. There are currently several different methods for systems development and project management. Some are based on research, others are new and some have been around a long time in the IT world. This work has identified customer involvement; Risk Reduction and Delivery which contribute to several projects fail under traditional systems. Agile methods are flexible, agile and welcome change and the customer will be able to steer the project. Agile methods have however provided the opportunity for developers to more quickly deliver functionality to the customer. / Detta arbete är ett examensarbete på C-nivå, 15 poäng vid Högskolan Väst, Institutionen för ekonomi och IT avd. informatik. Denna studie handlar om agila metodiken och dess inverkan på IT-projekt. Kravhantering är en process inom ett IT-projekt, där kund har vissa krav som måste uppfyllas av ett IT-system. Skillnaden mellan det traditionella och agila utvecklingsmetoder ligger i kravhantering process och det kan orsaka problem i ett projekt. Krav förändras under IT-projekt och för att hantera kraven bör agila principer tillämpas. Kravspecifikation och planering inom vattenfallsmodellen är tidskrävande. Att jobba agilt innebär att ha nära kontakt med beställaren. Därmed minimerar det risken för projektets misslyckande. Med agila metoder, kan funktionerna utvecklas i en snabbare takt och kunden får snabb leverans. Det finns idag flera olika metoder för systemutveckling och projektledning. Vissa är baserade på forskning, andra är nya och vissa har funnits en lång tid i IT-världen. Arbetet har identifierat kundinvolvering, Riskreducering och Leveranstid vilka bidra till att flera projekt misslyckas under traditionell systemutveckling. Agila metoder är flexibla, smidiga och välkomnar förändring och kunden kommer att kunna styra projektet. Agila metoder har däremot gett möjlighet för utvecklarna att på ett snabbare sätt leverera funktioner till kunden.

Agila arbetssätt och den agila filosofin har över de två senaste decennierna blivit ett självklart element I det flesta IT-systemutvecklingsprojekt. Fördelarna som följer med den agila filosofin (exempelvis ökad kundanpassning och snabbare leveranser) har bidragit till att större företag börjat att införa agila arbetssätt i hela organisationen – det vill säga inte bara i enskilda projekt. Denna idé har lett till att olika generella ramverk som benämns för Skalade agila ramverk (Scaled Agile Framework) har introducerats på marknaden. Ett par exempel på befintliga ramverk är Scrum of Scrums, LeSS, Scaled Agile Framework och Lean Scalable Agility. Av existerande ramverk är “Scaled Agile Framework” (SAFe) den mest implementerade och väletablerade. Det finns emellertid flera utmaningar med att införa SAfe i stora verksamheter. En utmaning är att skalade agila ramverk är komplexa och tar lång tid att införa. En annan utmaning är att det saknas verktyg som stöttar organisationer i deras försök att implementera ramverket. Detta är problematiskt eftersom det kan leda till en ineffektiv implementeringsprocess, högre kostnader och att vinsterna med den agila filosofin reduceras. Detta har lett oss till det problem som vi adresserar i studien; det saknas kunskap om hur bedömningsmodeller för SAFe skall designas. Problemet har sporrat oss att utföra en studie där vi, tillsammans med en organisation i näringslivet, har designat och utvärderat ett användbart och icke-komplext verktyg för bedömning av skalade agila ramverk. Syftet är med verktyget är att det skall effektivisera implementeringsprocessen av SAFe. Problemet har också legat till grund för vår forskningsfråga som lyder: Hur bör ett verktyg för bedömning av SAFe implementationer designas? För att finna svar på forskningsfrågan har vi valt att följa forskningsmetoden Action Design Research (ADR). ADR metoden vill bidra IS-forskning genom att 1) den adresserar ett problem i en specifik organisatorisk kontext genom design av en IT-artefakt samtidigt som den 2) stödjer identifiering av designprinciper. Studiens resultat visar att bedömningsmodellen fungerar, att den bidrar till att lösa det adresserade problemet samt att de designprinciper som presenteras är korrekta. / Agile methods and the agile manifesto has been for the last two decades a central focus point of software development in the world. The benefits that come with the usage of the agile philosophy (for example, increased customer adaptation and quicker deliveries) has led larger companies to try to adopt the principles on their entire organization - not only on smaller projects. This adoption has translated to the emergence of various frameworks that are generally labeled as Scaled agile frameworks. A few examples of these frameworks are Scrum of Scrums, LeSS, Scaled Agile Framework and Lean Scalable Agility. These frameworks are being widely adopted by large companies, with SAFe (Scaled Agile Framework) being the most adopted on the market. However, these frameworks have become a pinnacle of complexity due to the large size of the frameworks which proves to be a challenge for the company that is using them. This is problematic because there are no real tools to evaluate the implementation of scaled agile frameworks. With no tools to use, there is a risk of having an inefficient implementation process which constitutes to higher costs and that the general benefits of Agile manifesto are lost on the way. This has led us to the problem that we’re addressing in this study: There is a lack of knowledge on how to design assessment models for the SAFe framework. This problem has spurred us into conduct a study where we, together with an organization within the IT-industry, have designed and evaluated a tool that effectively assesses the implementation of SAFe. The problem set the groundwork for our science and the question we seek to answer in this study is: How should a tool for assessment of SAFe implementation be designed? Consequently, to find answers to this question, we have chosen to use the research method Action Design Research (ADR). The method of ADR wants to contribute to IS-research by 1) To design an uncomplex tool that can help IT industry to evaluate their scaled agile framework implementation and 2) provide theoretical knowledge translated into design principles that will contribute to other design efforts in similar contexts. The result provided in this study will help show that the design knowledge works, provide rigor to the study, help solve the given problem of the study and show that the design knowledge is correct

Agile principles for software development are now the industry standard for innovative projects. Agile is often hailed for being flexible, but there is also a commonly held 'truth' that agile principles and software security do not work well together. For this reason it is not uncommon to place all security responsibilities with a separate team, which goes against the agile principles of being team-centered and may affect flexibility or timeframe of a project. Additionally, software security is difficult and requires extensive experience and knowledge, something that varies a lot among software developers. This study presents a threat modeling process tailored for the specific needs and capabilities of the agile developer team. The process combines features of attack trees and abuser stories with other supplementary techniques in a pedagogical instruction manual to create an accessible and easy-to-get-started method intended to be driven by the developers themselves. The process has been developed through extensive review of extant threat modeling methods and the circumstances of the agile team, and trialed through user tests at an agile ITorganization in the financial services. / Agila principer för mjukvaruutveckling är nu industristandard för innovativa projekt. Agila metoder hyllas ofta för sin flexibilitet men det finns också en vidspridd uppfattning att agila metoder och mjukvarusäkerhet inte går bra ihop. Av den anledningen är det inte ovanligt att säkerhetsansvar och -uppgifter drivs av en separat säkerhetsgrupp, vilket går emot de agila principerna om fokus på utvecklarteamet. Detta kan få effekter både för projektets flexibilitet och dess tidsram. Dessutom är IT-säkerhet ett svårt ämne som kräver både erfarenhet och avsevärd kunskap, något som funnits variera mycket bland mjukvaruutvecklare. Den här studien presenterar en hotmodelleringsprocess som skräddarsytts för utvecklarteamets specifika behov och styrkor. Processen kombinerar funktioner från attackträd och abuser stories med andra, komplementära tekniker i en pedagogisk instruktionsmanual för att leverera en lättillgänglig och snabbstartad metod menad att drivas av utvecklarna själva. Processen har utvecklats genom omfattande studier av etablerade hotmodelleringsprocesser, samt den agila teammiljön, och testats och vidareutvecklats genom användartester hos en agil IT-organisation inom finansbranschen.

Manufacturing firms are realising the customer value and competitive edge that can be captured through digitalisation. Manufacturing firms are therefore striving to integrate digital technologies on the existing product range to create an ecosystem of connected products to create, monitor and manage the aftermarket product services. The integration introduces multiple conflicting innovation regimes into the organisation namely product innovation and digital innovation regime. This changes the way traditional manufacturing companies work with dynamics business models and dynamic market conditions requiring a new approach to maintaining customer relationships, rethinking the organizational structure and product developmental processes. The current study focuses on the product development challenges to which the manufacturing companies are exposed while developing connected products. Physical development processes are characterised by physical materiality, long lead times, upfront planning, early binding following a linear development framework while digital innovation is characterised by digital materiality, shorter lead time, multiple launches, late bindings which follows an iterative agile model of development. The contrasting characteristics create challenges for executing physical-digital product development projects. A Swedish manufacturing company is considered as a case study company and 19 process challenges are identified and reported in the current study through interviews with 26 stakeholders from diverse functions along with secondary data observations from project interaction meetings. These challenges are prioritised and group into five overarching challenges which are lack of integrated development process, coordination issues, integration issues, knowledge gap and resources issues. Three external companies are interviewed to compare challenges in the physical-digital product development process and identify process and practices adopted by the companies to mitigate those challenges. Based on the insights from the literature study, interviews from the case company and external companies, six recommendations were proposed. The recommendations include defining clear roles and responsibilities, creating a TRL chart for connectivity, strengthen front-loading activities, developing connectivity integrated NPD process, creating a flexible framework for functions to coordinate and develop connectivity integrated testing process. / Allt fler tillverkningsföretag inser det ökade kundvärdet och konkurrenskraften som digitalisering kan medföra. Tillverkningsföretag strävar därför efter att integrera digital teknik i det befintliga produktsortimentet för att skapa ett ekosystem av digitalt uppkopplade produkter för att utforma, övervaka och hantera produkter och tjänster på marknaden. Integrationen kan skapa konflikter mellan företagets innovationsregimer i organisationen, såsom produktinnovation och digital innovationsregim. För att kunna upprätthålla kundrelationer samt omstrukturera organisationen och produktutvecklings-processerna krävs en ny strategi, eftersom integrationen förändrar hur traditionella tillverkningsföretag arbetar med dynamiska affärsmodeller och dynamiska marknadsförhållanden. Denna studie fokuserar på de utmaningar i produktutveckling somn tillverkningsföretag möter i utvecklandet av uppkopplade produkter. Utvecklingsprocesser för fysiska produkter kännetecknas av långa ledtider, planering i förväg samt tidiga beslut utifrån ett linjärt utvecklingsramverk, medans digital innovation kännetecknas av kortare ledtider, flera lanseringar, och senare beslut som följer en iterativ, agil utvecklingsmodell. Skillnaderna i utvecklingen av digitala och fysiska produkter skapar utmaningar för att genomföra fysisktdigitala produkttvecklingsprojekt. En fallstudie utfördes på ett svenskt tillverkningsföretag där 19, olika processutmaningar identifieras och rapporteras i denna studie. Studien baseras på intervjuer med 26 intressenter från olika avdelningar, samt sekundära dataobservationer från projekmöten. Utmaningarna prioriteras och grupperas i fem övergripande problemområden; utmaningar avseende samordning, integration, kunskap, respektive resurser, samt avsaknad av en integrerad utvecklingsprocess. Tre externa företag intervjuas för att jämföra utmaningar i den fysiskt-digitala produktutvecklingsprocessen samt för att identifiera processer och metoder som företagen har använt för att hantera dessa utmaningar. Baserat på litteraturstudien, intervjuer från företaget och de externa företagen föreslås sex rekommendationer. Dessa inkluderar att definiera tydliga roller och ansvarsområden, skapa ett TRL-diagram för anslutningar, stärka front-loading-aktiviteter, utveckla en integrerad produktuvtvecklings process för uppkopplade produkter samt skapa ett flexibelt ramverk för funktioner för att samordna och utveckla en integrerad testprocess för uppkopplade produkter.