Det senmoderna samhällets komplexitet har gjort organisationers riskhantering till en viktig men svårstrukturerad aktivitet. I en förstudie (Sparf, 2004) har en riskhanteringsmetod utifrån sociologisk systemteori utarbetats (STRIM). I föreliggande uppsats är syftet dels att ge en bild av och exempel på hur riskhantering kan gå till i teori och praktik och dels att testa den empiriska giltigheten hos STRIM. De bakomliggande systemteorierna rekapituleras och därtill har teorier om riskhantering lagts. Den empiriska undersökningen har utgjorts främst av två intervjuomgångar med fem informanter i varje. Resultatet ger en fyllig bild av praktisk riskhantering, men uppfyller bara delvis prövningen av STRIM. Den viktigaste slutsatsen är att instrumentella och administrativa riskhanteringsmetoder respektive processer och enstaka insatser i praktiken har svårt att mötas. Dessa problem kan STRIM förmodligen bidra till att överbrygga genom skapandet av en gemensam nomenklatur.

Empati mellan interaktionsdesigners och utvecklare är viktigt för att samarbetet ska fungera och för att parterna ska kunna kommunicera med varandra. Detta tillsammans med förmågan att se situationer ur varandras perspektiv är något som påverkar samarbetet avsevärt. Empati bygger på förståelse, förstår man andra personers perspektiv kan man också känna empati för andra personers prioriteringar och ta hänsyn till dessa. Det är också av stor vikt att interaktionsdesigners och utvecklare har en gemensam bild av situationen och de projekt de arbetar med. En förstudie som genomfördes under hösten 2013 visade att interaktionsdesigners upplevde att utvecklare inte känner empati för deras arbete vilket de upplevde har skapat problem i samarbetet. För att få en djupare förståelse för detta genomfördes en fenomenologisk studie där nio interaktionsdesigners intervjuades. Resultatet visade att interaktionsdesigners upplevde att utvecklare ibland ändrar i en design utan att diskutera detta med dem vilket gör att syftet med designen kan falla bort och i vissa fall känner interaktionsdesigners inte igen sin design i den färdiga produkten. De upplevde även att utvecklare ser på design som något onödigt eller lyxigt som inte behövs för att ta fram bra produkter. Utvecklingen har istället varit det som ses som viktigt och prioriterats i projekten. Interaktionsdesigners har även upplevt denna bristande förståelse på organisatorisk nivå, exempelvis när kunder inte köpt deras tjänster fram tills att produkten är färdig. Därför har det inte funnits möjlighet till avstämning mellan interaktionsdesigner och utvecklare under tiden utvecklare implementerar designen. Missförstånd har då uppstått och produkten har inte nått sin fulla potential. Vissa anser att en stor del av problemet grundar sig i detta, att utvecklare inte i sitt arbete uppmuntras diskutera designen eller följa upp implementationen med den som skapat designen. / Empathy between interaction designers and developers is important in order for the collaboration to work and for them to be able to communicate with each other. This, as well as the ability to see situations from other persons perspective, is something that affects collaboration significantly. Empathy builds on understanding, if one understands other persons perspective one can also feel empathy for other persons priorities and take these in to consideration. It is also of great importance that interaction designers and developers have a common picture over the situation and the projekts they are working with. A pre study was carried out in the fall of 2013 and showed that interaction designers felt that developers does not have empathy for their work, which they experienced has created collaboration problems between them. In order to create a deeper understanding for this, a phenomenological study was carried out where nine interaction designers were interviewed. The result showed that interaction designers felt that developers sometimes changes a design without discussing it with them, which can lead to deviations from the purpose of the design and in some cases the designers does not recognize their design in the developed product. The interaction designers also felt that developers think design is something unnecessary or luxury that is not needed in order to create successful products. The development is instead seen as what is important and what is prioritized in the projects. Interaction designers have also experienced this lack of understanding at an organizational level, for example when customers have not bought their service all the way, until the product is done and ready for release. Because of this there has not been possible for the interaction designers and the developers to talk to each other during the development process. Misunderstandings have then occured and the product has not lived up to its full potential. Some believe that a big part of the problem originates from this, that developers in their work is not encouraged to discuss the design with the interaction designer that created it.

Detta examensarbete utfördes på avdelningsnivån CCS på avdelningen PDU Platforms på Ericsson. Avdelningen ville förändra sin nuvarande arbetsprocess genom att övergå från Daily Build, att bygga och testa en gång om dagen, till ett mer kontinuerligt byggande och testande. CCS hanterar och tillhandahåller kontrollsystemtjänster för RNC applikationer och äldre RBS.   Målet med detta examensarbete var att automatisera testprocesser för att kunna utföra kontinuerliga tester. Första steget i arbetet var att ta fram ett specifikt användningsfall, ett use case, att arbeta mot. Detta skedde genom analys av felrapporter och detta ledde till att nodomstarter definierades som ett första användningsfall. När användningsfallet var definierat, skedde analys av plattform att använda för automatisering, samt vilka steg som behövde automatiseras. De var enligt följande, uppladdning med ftp, exekvering av filer med Telnet och nodkonfiguration med verktyget Cicc.

Agila utvecklingsmetoder används ofta i systemutvecklingsprojekt för grupper som arbetar på en och samma plats. I takt med globaliseringen har många organisationer behövt arbeta på ett distribuerat sätt. Distribuerad systemutveckling i kombination med agila utvecklingsmetoder har blivit ett önskvärt tillvägagångsätt för att arbeta i projektform. Denna symbios innebär ett antal utmaningar och framgångsfaktorer som påverkar varandra och gör distribuerade agila systemutvecklingsprojekt komplexa.   Denna studie undersöker området agila utvecklingsmetoder i samband med distribuerade agila systemutvecklingsprojekt. Syftet är att identifiera och beskriva viktiga utmaningar och kritiska framgångsfaktorer som kan förekomma i ett agilt distribuerat systemutvecklingsprojekt. I studien har tidigare forskningsartiklar använts som stöd för bygga en grund till denna forskning och därefter har en analysmodell utformats för att underlätta identifieringar av utmaningar och framgångsfaktorer i distribuerade systemutvecklingsprojekt. Studien har genomförts genom en kvalitativ metod i form av semistrukturerade intervjuer för att identifiera utmaningar och framgångsfaktorer. Två företag har deltagit i studien och sex respondenter har sammanlagt medverkat i, där samtliga har erfarenhet av att arbeta i agila distribuerade projekt. För att tillfredsställa det djupgående kunskapsmässiga som studien avser undersöka har olika roller valts ut för att säkerställa att upplevelsen inte styrs av en specifik roll, där alla olika rollers erfarenheter skapar ett bredare perspektiv.  Slutsatser som kan dras av denna studie är att socio-kulturella skillnader, koordination, geografiskt avstånd, kunddeltagande, förtroende, projektstatus och kommunikation är de viktigaste utmaningar i distribuerade agila systemutvecklingsprojekt.  Användningen av agila utvecklingsmetoder i distribuerade miljöer har även visat att det finns framgångsfaktorer för att hantera utmaningarna och göra projekt framgångsrika. Dessa faktorer är effektiv kommunikation, kommunikationsverktyg, koordination, förtroende och stå-upp-möte, som till exempel genom att implementera en sorts dagligt webbaserade stå-upp-möte även om arbetet sker på distans.   Det visar sig även att kommunikationsverktyg och stå-upp-möte har underlättat samarbete och kommunikationen mellan distribuerade team och de är viktiga och potentiella determinanter för att bygga interaktioner och förtroende.

Agil systemutveckling och distribuerad systemutveckling är två fenomen som båda växer i popularitet. Flera av de värderingar som agil systemutveckling förespråkar innebär dock vissa utmaningar i kombination med distribuerad systemutveckling, med andra ord distribuerad agil systemutveckling. Kunskapen om distribuerad agil systemutveckling är emellertid i dagsläget låg, liksom hur man går till väga för att göra distribuerade agila projekt framgångsrika. Studien antar av den anledningen en vertikal karaktär för att ingående utreda och beskriva naturen av den ofta största utmaningen i distribuerad agil systemutveckling, nämligen kommunikationen mellan människor (Gurram & Goud Bandi 2012), samt identifiera kritiska framgångsfaktorer med hänsyn till dessa utmaningar. Studien är dessutom avgränsad till intern kommunikation och upplevelser hos svenska leverantörer som arbetar med distribuerad agil systemutveckling i projektform. För insamling av data har studien antagit en kvalitativ ansats i form av semistrukturerade intervjuer. En analysmodell har också utformats och använts i olika steg under forskningsprocessen. Två företag har deltagit i studien och antalet respondenter har uppgått till sju personer sammanlagt. Dessa respondenter har, förutom en matchning mot studiens avgränsning, olika roller i den agila projektorganisationen för att tillfredsställa det kunskapsmässiga djup som studien avser att omfatta med hänsyn till problemområdet. De flesta utmaningar i distribuerad agil systemutveckling har visat sig bero på den distribuerade naturen av de projekt som tillämpar metoden, såsom bristen på kroppsspråk, undermålig ljudkvalitet i ljud- och videokonferenser, språkbarriärer och kulturskillnader. Bland de kritiska framgångsfaktorer som studien har identifierat och bedömt som särskilt betydelsefulla ingår bland annat videokonferenser med intresse för att fånga projektmedlemmars kroppsspråk, användning av hårdvaror med bra kvalitet för uppspelning och upptagning av ljud, en högre grad av skriftlig kommunikation med projektmedlemmar som är mindre bra på att tala engelska samt en större öppenhet om vilka förväntningar som ställs på kommunikationen från andra samlokaliserade projektorganisationer och de projektmedlemmar som ingår i dessa.

Inom dagens systemutvecklingsprojekt har testning en viktig roll för att ett företag ska kunna lyckas leverera en produkt. Testning har ofta nedprioriteras pågrund av att det största fokuset har legat på nyutveckling. Testrollen är väldigt viktig för att kunna försäkra om sin produkt är redo för marknaden.   Syftet med uppsatsen är att ta reda på utmaningar och problem med testautomatiseringens startprocess i en agil systemutvecklingsmiljö. Vad företag och undersökningsföretaget som startar med testautomatiseringen kan förbereda sig på för att kunna lyckas.   Undersökningen som uppsatsen bygger på har använt en induktiv ansats. Undersökningen har skett på ett undersökningsföretag som arbetar agilt inom systemutveckling. Målet är att undersöka verkligheten utan att söka svar och undersöka orsakssambanden. Syftet är att påståenden från teori och tidigare undersökningar ska jämföras med resultatet. Kvalitativ metod har använts för datainsamling i form av intervjuer.   Resultatet av undersökningen bevisar att testautomatiseringen är väldigt viktigt inom den agila systemutvecklingsmiljön och att det finns en många problem och utmaningar som behövs tänkas på när ett system ska börja med testautomatisering. Den agila utvecklingsmetoden har blivit vanligare inom utvecklingsbranschen och därför kommer också testautomatisering bli vanligare. Många av problemen och utmaningarna håller inte ihop, utan påverkas av olika konsekvenser. Resultatet av uppsatsen kom fram till utmaningar och problem med: testdata/testmiljö, förståelse, struktur, verktyg och kompetens.   Målet med uppsatsen är att bidra med nyttig information till ökad medvetenhet om vad som krävs för att starta igång testautomatisering. / Within today´s system development projects, testing have been an important role within company to be able to successfully deliver their product. Testing has often given a lower priority unfortunately, because focuses have been on new development. The test role is very important in order to insure their product is ready for the market.   The purpose of this paper is to find out the challenges and problems with test automation start-up process in an agile system environment. What companies that start with test automation could prepare in order to succeed.   For the survey on which the essay is based on an inductive approach has been used. The investigation has taken place at a research company that works with agile in system. The objective is to investigate reality without getting any answers. The aim is to claims from theory and previous information will be compared with the results. Qualitative methods were used for data collection in the in the form of interviews.   The survey results prove that test automation is very important in the agile system development environment and that there are a lot of problems and challenges that need arise when a system should start with test automation. The agile development methodology has become more prevalent in businesses and test automation will be development. Many of the problems or challenges do not hold together, without affected by different consequences. The results of the thesis came to the challenges and problems with: test data/test environment, understanding, structure, tools and skills.   The goal of this paper is to provide useful information to increase awareness of what is required to start running with test automation.

Sverige har som mål att bli bäst i världen på att nyttja digitaliseringens möjligheter för att skapa effektiv verksamhet i offentlig sektor och en enklare vardag för privatpersoner och företag. År 2017 spenderades 59 miljarder svenska kronor på att digitalisera Sverige med hjälp av externa aktörer. Trots miljardsatsningen är Sveriges utvecklingstakt långsam i jämförelse med flera andra länder i Europa. Svenska myndigheten Riksrevisionen har dessutom identifierat att IT-projekt ofta drar över budget och konstaterar att offentliga verksamheter måste effektivisera sin IT-verksamhet. IT-projekt, inte bara i offentlig sektor, har visat en trend på att dra över budget eller tid och i ett försök att möta denna problematik har den agila filosofin och olika agila projektmodeller vuxit fram. Det agila projektförfarandet har överlag haft en positiv påverkan på IT-projekt och har anammats i en högre utsträckning i den privata sektorn än den offentliga sektorn.  Då det läggs flera miljarder på upphandlingar av IT har vi sett det som viktigt att samverkan med extern part fungerar bra och att projekten effektiviseras. Eftersom den agila projektmodellen visat sig ha en positiv påverkan på IT-projekt har denna studie därför undersökt vilka förutsättningar som finns för att driva IT-projekt agilt mot offentlig sektor. Upphandlingsprocessen och hur den påverkar möjligheten att tillämpa en agil projektmodell har fått särskilt mycket uppmärksamhet i vår studie då lagen om offentlig upphandling (SFS 2016:1145) innebär att den kravspecifikation som skrivs av den upphandlande parten blir svårföränderlig. I vår fallstudie har vi undersökt ett implementationsprojekt i en offentlig verksamhet som drivits med en agil ansats av en extern leverantör i privat sektor. Genom att intervjua respondenter på leverantören, som var involverade i projektet, har vi tillämpat ett leverantörsperspektiv i vår undersökning för att kartlägga upplevda utmaningar i projekt mot offentlig verksamhet. Utifrån empirin har vi kommit fram till att upphandlingsförfarandet lett till att det uppstått (1) utmaningar vid ändring kravspecifikation och att bevisa uppfyllelse av krav, (2) kommunikationssvårigheter mellan Kunden och Leverantören gällande krav och (3) upplevd bristande förståelse för kraven av kunden. Vissa organisatoriska karaktärsdrag för offentlig verksamhet har också identifierats som bidragande till kommunikationssvårigheter mellan Kunden och Leverantören gällande krav. Den agila filosofin förespråkar ett nära samarbete med intressenter och förutsätter förändringar av kravspecifikationen genomgående i projektet. Slutsatsen är således att upphandlingsprocessen, i det studerade projektet, har påverkat möjligheterna för att driva IT-projekt agilt. / Sweden has the goal of becoming best in the world of utilizing the possibilities created by digitalization to create an effective public sector and an easier everyday life for individuals and companies. During 2017, Sweden spent roughly 59 billion Swedish crowns on digitalization with help of external actors. Although these billions of Swedish crowns are spent, the country’s development pace is slower than other European countries. The Swedish authority Riksrevisionen has conducted an audit where they have identified that IT-projects often runs over budget and states that the public sector must streamline its use and procurement of IT. IT-projects have shown a trend of budget overruns and not meeting deadlines, not only in the public sector. In an attempt to turn the trend, the agile philosophy and different agile project models was formed. The agile approach has overall had a positive effect on IT-project and has been embraced in the private sector to a larger degree than the public sector. We see cooperation between external supplier and the actor procuring information systems as well as the streamlining of IT-projects as a critical aspect of the Swedish digitalization. Since the agile approach has shown positive effects of IT-projects, this study has aimed to examine what prerequisites are present in the public sector for running projects in accordance of the agile philosophy. The procurement process and how it affects these prerequisites has received a lot of focus since the procurement law (SFS: 2016:1145) in Sweden implicates that the requirement specification, created by the contracting actor, is difficult to change. In our case study, we have examined an implementation project in the public sector, led by an information system supplier in the private sector. We gathered qualitative data by interviewing employees of the supplier, involved in the project, effectively applying a supplier perspective to map perceived challenges in delivering information systems to the public sector. From the qualitative data we concluded that the procurement process has led to (1) difficulties with changing the requirement specification and proving fulfilment of requirements, (2) communication challenges between the customer and the supplier regarding requirements and (3) experienced lack of comprehension of requirements by the customer. Some organizational characteristics for the public sector have also been identified as a possible cause of communication challenges. The agile philosophy advocates close collaboration with stakeholders and expects changes to the requirement specification throughout the project. The conclusion is thus that the procurement process, in the studied project, has affected the prerequisites to run a project with an agile approach in a negative way.

The purpose of this study was to 1) identify driving forces for introducing new system development methodologies at the Swedish Tax Agency. The preconditions of the Swedish Tax Agency also affect the use of new methodologies. The study therefore also aimed to 2) portrait the influence of the preconditions on the organization. Furthermore, the object of the study was to 3) illustrate the use of methods in system development and also to 4) investigate the contributions of the methods to the organization and the four case projects within the Swedish Tax Agency. The study was carried out through a qualitative methodology, with interviews, and a quantitative methodology, with questionnaires and document collection. A combination of methods was used in order to acquire a holistic perspective of a complex issue. From the study, some conclusions have been drawn. Firstly; being modern, fashionable and a desirable employer are driving forces for introducing new system development methods, together with a desire of increased efficiency when developing systems. Secondly; the main preconditions were identified as the organizational culture and how the purpose of a change is communicated to the affected employees. Thirdly; all of the project teams that were that participated in the study was found to use different hybrids of system development methods, which lead to the fourth conclusion; the used methods was found to contribute with different things, such as structure in project planning and when tracking sources of errors, commitment in work and good group dynamics.

In today’s society, IT-Companies often have a hard time estimating changed requirements. This leads to that the clients’ confidence is negatively affected and is one of the main reasons why this has to be improved. The goal with this study was to find out what the most common problems regarding this issue are in IT-companies that works with agile software development. By analyzing one IT-company through a SWOT- and pareto-analysis the most common problems have been ascertained. The SWOT analysis have been created through interviews with selected employees to get a better understanding of the problems that the IT-company is facing. Furthermore was the pareto-analysis based on a survey that was sent out to many different employees to prioritize the problems. The reason why the survey was sent to different employees was to get a more objective input. The study showed that there was many different problems that needed attention. The most important problems was that the communication towards the client regarding requirements needed to be improved, better communication internally between different departments needed to be established, a method to quickly adapt and estimate change in requirements needed to be implemented and finally a method regarding witch key employees whom need to attend the planning of the program backlog. These problems have then been studied through interviews with other IT-companies and through a literature study. The conclusions that where drawn was that the client needs to be involved and updated through the whole project. Constant monitoring and communication regarding changed requirements needs to be processed and mediated. High standards needs to be set early towards the client in order to obtain as clear an image of the requirements as possible. Many different parties need to attend to the planning process for the program backlog before the start of the project. The client needs to be aware of that changed requirements will arise and that this will lead to that the first estimation may not necessarily be absolute. As long as the client is held up to date as well as participant through the whole project and problems are detected and mediated early, change in requirements should not be a huge problem. This is after all the purpose of being agile. / I dagens läge har IT-företag svårt med att estimera förändrade krav vilket medför att förtroendet hos beställaren påverkas negativt och är en av hu-vudanledningarna till att det måste förbättras. Målet med studien har varit att försöka ta reda på de vanligaste problemområdena inom agil systemut-veckling bland IT-företag med hjälp av en SWOT- och pareto-analys. SWOT-analys konstruerades av intervjuer med anställda på ett IT-företag och an-vändes för att ta reda på problemområden. Pareto-analysen användes med hjälp av en enkät som skickades ut till anställda på samma IT-företag för att prioritera problemområdena. Enkätens svar bygger på anställda från de flesta avdelningar, vilket resulterar i en objektivare syn på resultatet. Under-sökningen har visat att det finns många områden som kan förbättras. De huvudsakliga områdena som behövde förbättras var tydligare kommunikat-ion gällande kravhantering gentemot kunden, bättre kommunikation mellan avdelningarna internt i företaget, införa en metod för att snabbt estimera samt anpassa sig till förändrade krav behövde implementeras och slutligen skapa struktur gällande vilka personer som bör delta i planeringen inför program backlog. De fyra största problemområdena har sedan undersökts med hjälp av intervjuer med andra företag och genom en litteraturstudie. Slutsatsen som drogs var att kunden behöver vara involverad och uppdate-rad genom hela projektet. Konstant uppföljning och kommunikation gäl-lande förändrade krav behöver bearbetas och förmedlas. Höga krav måste sättas på kunden i början för att få en tydlig och genomarbetad förståelse för kravspecifikationen som möjligt. Många olika parter bör vara med på planeringen inför program backlog innan projektets uppstart. Kunden bör vara medveten om att förändrade krav kommer att uppstå och att detta kommer att leda till att den första estimeringen inte nödvändigtvis kommer vara absolut. Så länge kunden är uppdaterad och delaktig genom hela pro-jektet och problem upptäcks samt förmedlas tidigt bör förändrade krav inte vara ett stort problem. Det är syftet med att vara agil.

The purpose of this study was to examine how Nordea could take on agile scaling, focusing on a unit of distributed Scrum teams within their departmentfor digital banking. The aim was to be achieved by attempting to identify appropriate methods and best practices - for scaling agile - to implement for the unit's success. The teams are working in isolation from each other, deployed across Scandinavia, despite the development of the same products/services. By studying the challenges of Nordeas unit, this master thesis could give some concrete examples of how a large organisation can proceed to take on the aspect of agile scaling, involving distributed teams. The conclusions are that Nordea has initiated an agile transformation, but need more uniform teams if they want optimize through synergy effects. To attempt agile scaling for distributed nonuniform teams is not recommended. The management lacks transparency and should get more involved to make an analysis on the current situation so that long-term goals can be set up. Making use of a ready-made framework for scaling is not recommended when there are few dependencies between a small number ofpeople. To continue forward the assistance of external experts, who can analyze and measure the relevant components, is recommended. Recommendations have been given to the the question formulations anda number of other relevant points. These recommendations include appropriate methods and best practices for management to proceed with, and revolve around making the team more uniform without encountering too much of a resistance.