Planering och projektuppföljning med Scrum och Line of balance En undersökande och teoriprövande fallstudie

Transkript

1 Examensarbete i Informatik Kandidatnivå med inriktning Systemvetenskap Planering och projektuppföljning med Scrum och Line of balance En undersökande och teoriprövande fallstudie Författare: Martin Mattsson Handledare: Håkan Sterner Examinator: Jan Aidemark Handledare, företag: Jesper Svensson, Fortnox Datum: Kurskod: 2IK10E, 15 hp Ämne: Informatik Nivå: Kandidat Institutionen för Informatik 1

2 Sammanfattning Inledningsvis i uppsatsen introduceras läsaren till ämnet som grundar sig i utveckling av programvara vars projekt enligt dagens uppfattning bör hanteras med så kallade agila metoder. Dessa metoder innebär såväl fördelar som problem för verksamheten. Enligt tidigare forskning kvarstår problemet som man tidigare försökte lösa med agila metoder, nämligen att projekten ofta överskrider tid och budget medan de inte levererar det förväntade värdet. Det har uppstått meningsskiljaktigheter om varför detta problem kvarstår. I denna uppsats undersöks bristfällig projektuppföljning som en möjlig orsak, baserat på uppgifter från en verksamhet som har upplevt detta problem. I samband med att härleda problemet till verksamhetens kontext undersöks line of balance som fenomen för att ta reda på om den kan fungera som komplement till deras nuvarande metoder. Teori om löpande projektuppföljning i sin helhet har varit av intresse för undersökningen. Sedan har den generella teorin brutits ner till att behandla projektuppföljning och planering i agila projekt. Det har fortsättningsvis brutits ner till teori om hur projektuppföljning bedrivs enligt arbetsformen Scrum. Line of balance har ett eget kapitel som består av två delavsnitt som behandlar hur den ursprungligen var menad att fungera och hur den sedan har anpassats för att användas i agila projekt. Metoden som används är en kvalitativ metod i form av en utforskande fallstudie med teoriorövande inslag. Fallet i fråga är ledningsgruppen som har upplevt problemet inom verksamheten, som bedriver utveckling av programvara. En fokusgrupp upprättades för att med en diskussion reda ut tänkbara hinder med deras nuvarande projektuppföljning och i samband med detta diskutera komponenter från line of balance som skulle kunna komplettera deras nuvarande metoder. Resultatet innebar en redogörelse för vilka hinder verksamheten kopplade till projektuppföljning och vilka möjligheter de såg med line of balance. Resultatet delades upp i olika teman som var och en representerar en aspekt gentemot projektuppföljning. De teman som identifierades var förståelsen för line of balance, planering av milstolpar/etapper, projektuppföljning, hantering av förändringar, identifiering av flaskhalsar och kommentarer som rent generellt talar för eller emot line of balance. Vid vidare analys visade det sig att uppskattning av mängden arbete och tid inför ett projekt var både svårt och till viss mån onödigt eftersom omständigheterna ändå alltid förändras under projektets gång och estimaten blir fel. Detta talade emot line of balance eftersom man i teorin, trots att den ska vara anpassad för agila projekt, förespråkade en fördefinierad plan. Fortsättningsvis uppstod dock en diskussion om hur metoden skulle kunna anpassas ytterligare för att verksamheten skulle kunna använda sig av komponenter de upplevde gynnsamma. Slutsatsen som drogs var att Scrum inte motsvarar riktlinjer för vad som anses vara projektuppföljning som kan säkerställa att projektet är på rätt kurs. Detta ansågs också vara en av anledningarna till varför verksamhetens kontext leder till att projekt överstiger tid och budget. Line of balance ansågs ha nödvändiga komponenter för att bedriva projektuppföljning enligt riktlinjerna men metoden passar inte in i fallets kontext på grund av det agila förhållningssättet. Ett alternativt användningsområde identifierades som föreslår att line of balance kan användas för samla historisk data att grunda sina framtida beslut på. Nyckelord: Projektuppföljning, Line of balance, LOB, Agil planering, agil projektuppföljning, Scrum

3 Summary The beginning of this paper is meant to introduce the reader to the topic of interest founded in development of software which in today s society is ought to be driven by agile methods. These methods carries problems and possibilities for businesses. Prior research indicates that the problem which agile methods were meant to solve, still exists, namely projects that intend to transcend allocated time and budget while not delivering the expected value. There has been differences in opinion about why this problem still exists. This research examines how insufficient monitoring during projects could be a reason, based on communication with a business whom have experienced this problem. In relation to finding the source for this problem in the business context the research will examine line of balance as a phenomenon to evaluate if it could be functional as a complement to their current methods. Theory about continuous monitoring during projects in its entirety has been of interest for this research. In addition it has been broken down to monitoring and planning in agile projects and henceforth broken down to Scrum as an agile practice. Line of balance has its own chapter with two parts where one of them describes line of balance as it was initially supposed to work and the other how it has been adapted to work within agile projects. The method used is a qualitative, exploratory case study with partial purpose to try theory. The case at hand is the group of leaders whom conduct the development of software and have experienced the problem within their business. A focus group was initiated in the research in order to take part of a discussion regarding constraints connected to their current monitoring activities and in relation to that discuss components included in line of balance which could complement their current methods. The result of the study included a recitation of which constraints the informants connected to monitoring activities and what possibilities they saw with line of balance. The result got divided into different themes each one representative of an aspect relating to monitoring activities. Themes identified were the understanding of line of balance, planning of milestones/sprints, project monitoring, handling of changes, identification of bottlenecks and comments regarding pros and cons related to line of balance. Closer analysis showed that estimation of workload and time before initiation of a project was perceived as hard and in some regards unnecessary because the circumstances was experienced to always change and therefor make the estimation wrong. This spoke against line of balance because in theory, even though it s supposed to be adapted, it advocates a defined plan. Furthermore a discussion arose about adapting the method even more with the purpose of getting the components from line of balance which were perceived as favorable. The study concluded that Scrum doesn t live up to guidelines for what is believed as monitoring that could ensure that the project is on the right course. This was also believed to be one of the reasons why the business context leads to overruns regarding time and budget. Components included in line of balance was sawn as necessary to follow these guidelines but the method didn t fit in the context due to the agile approach. Another possible area of use got identified during the analysis, namely using line of balance as a method to gather historic data for future decision making. Keywords: Project monitoring, Line of balance, LOB, Agile planning, agile monitoring, Scrum

4 Innehåll 1. Introduktion Inledning/Bakgrund Tidigare forskning Problem Syfte och frågeställning Avgränsning Teoretiskt ramverk Löpande projektuppföljning Agil planering och estimering SCRUM Line of Balance Applicering av LOB i produktion Applicering av LOB i projekt med arbetsformen SCRUM Metod Vetenskaplig utgångspunkt Val av ansats Val av metod för datainsamling Urval Genomförande Val av analysmetod Validitet och Reliabilitet Validitet Reliabilitet Etiska ställningstaganden Empiri Beskrivning av fallföretag Resultat Förståelse för LOB Planering av milstolpar/etapper Projektuppföljning Hantering av förändringar Identifiering av flaskhalsar Resultat som talar för och emot LOB Analys och diskussion Analys av generell uppfattning Planering av milstolpar/etapper Projektuppföljning... 25

5 5.4 Hantering av förändringar Identifiering av flaskhalsar Sammanfattning Metoddiskussion Avslutning Slutsats Förslag på fortsatt forskning Referenser Bilagor... 33

6 1. Introduktion Detta avsnitt avser att introducera läsaren till det belysta området, dess problem och bakgrund samt utifrån det ge en bild över vad syftet sätter för ramverk för denna studie och vilka frågor som förväntas besvaras i studiens slutskede (Creswell, 2014). Därefter sker begränsningar för att ytterligare precisera studien och konstatera vad som inte är möjligt eller relevant att inkludera. 1.1 Inledning/Bakgrund IT-system blir allt viktigare och innebär idag en stor konkurrensaspekt för verksamheter oavsett vilken bransch de verkar i. Företag är villiga att satsa stora summor pengar för att implementera eller upprätthålla avancerade, moderna system som stöttar verksamheten. Dessa satsningar är riskabla. I snitt visar statistik, från en undersökning bedriven på IT-projekt med en budget på över 15 miljoner dollar, att 17 % av dessa projekt har hotat hela organisationens existens genom att misslyckas. Dessa projekt överskrider budgeten med 45% och tiden med 7 % medan de levererar 56% mindre värde än förväntat. Undersökningen poängterar även att utveckling av programvara löper den största risken för att överskrida budget och tid (Bloch, Blumberg, Laartz, 2012) Agila metoder har sedan 2001 blivit en växande trend vid utvecklingsprojekt. Visionen med agila metoderna var att råda bot på de traditionella utvecklingsmetodernas problem i föränderliga omgivningar (Wang, Conboy, Cawley, 2012). Grundtankarna bakom agil systemutveckling är att utvecklingen ska ske inkrementellt och iterativt för att i nära samarbete med huvudintressenter kunna utvärdera mindre leveranser. Syftet med detta förhållningssätt är att kunna behandla nya behov och önskemål kontinuerligt under ett utvecklingsarbete (Agile Alliance, 2015). Detta ska leda till utveckling av produkter av hög kvalité på kort tid och med ett mindre behov av dokumentation (Sampaio, Pinheiro, Tamanini, 2014). Scrum är en av de mest använda agila metoderna (Sampaio et al., 2014, Miranda & Borque, 2010, Mahnic & Hovelja, 2012). Det är tydligt att Scrum inte är en teknik eller en process för att utveckla produkter utan snarare en uppsättning verktyg, tekniker och processer vars syfte är att underlätta processen för att utveckla produkter. Eftersom SCRUM endast är en uppsättning beståndsdelar, varje med sitt eget syfte anser Sampaio et al., (2014) att man utifrån sina egna förutsättningar bör välja ut de delar som med den befintliga verksamheten skapar bästa praxis. En av dessa beståndsdelar är en grafisk representation över hur mycket arbete det är kvar att göra gentemot hur lång tid det är kvar i ett projekt, burn down charts (Dinwiddie, 2009). Burn down charts är lätthanterliga men de inte en fullständig bild över projektets tillstånd. De visar hur mycket arbete som har gjorts och hur mycket arbete det är kvar för att ge någon form av indikation på vart projektet bör befinna sig med förutsättningen att det har fortlöpt under ett jämt flöde. De misslyckas med att visa relationen mellan vad som faktiskt är kvar att göra och vad som bör vara kvar att göra om projektet ska motsvara sina åtaganden (Miranda & Borque, 2010). Efter att ha inlett kontakt med ett företag som utvecklar programvara enligt arbetsformen Scrum visade det sig att tid- och budgetöverträdelser förekom och kontaktpersonen trodde att detta berodde på brister i deras nuvarande metoder relaterat till projektuppföljning. De upplevde att det var svårt att mäta prestation och bestämma projektets status vilket leder till att det inte finns något att gå på när det behövs lämpliga anpassningar för att nå målet i tid. Det finns förbättringar som kan leda till en minskning av misslyckade IT-projekt i förhållande till tid och budget i samband med ett förväntat värde. En övergång från de traditionella metoderna, t.ex vattenfallsmetoden är en början men faktum är att man även saknar aspekter från den typen av metoder. Det man saknar är fördelarna av en noggrann planering som man väljer bort i utbyte mot en mer flexibel projektorganisation med anpassningsbar planering (Palmquist, Lapham, Miller, Chick, Ozkaya, 2013). 1

7 Genom att undersöka om line of balance (LOB) kan appliceras på en arbetsform enligt SCRUM är förhoppningen att kunna föreslå ett mellanting som ska ge IT-projekt bättre förutsättningar för att lyckas i tid utan att påverka den flexibilitet som önskas i agila projekt. 1.2 Tidigare forskning Tonnquist(2012) listar 8 anledningar till varför IT-projekt misslyckas i förhållande till tid, budget och mindre värde än förväntat. Ett otydligt mål och syfte, att målet ändras under projektet och en brist på involvering av användare menar han kan lösas med agila metoder. Dålig planering, Orealistisk tidsoch resursbedömning och brist på stöd från ledningen menar han kan undvikas med en väldefinierad tidsplan och bra kunskaper i den valda projektmetodiken. De resterande två anledningarna är brist på kommunikation och teamkänsla samt brist på yrkesskicklighet menar Tonnquist(2012) är personliga brister och kan därför inte härledas till någon specifik metod. Tidigare har forskare även försökt härleda problemet med tid- och budgetöverskridningar till mer specifika anledningar, som att tiden det tar att implementera och testa användarfall är svår att uppskatta. Det har därför genomförts studier på en metod vars syfte är att uppskatta denna tid, planning poker som är vanligt förekommande i agila utvecklingsprojekt (Mahnic & Hovelja, 2012). Under två studier med liknande experimentella metoder har det visat sig att desto mer expertis involverad i dessa planning poker -sessioner, desto större pessimism upplever man gentemot tiden det tar att genomföra en sprint. Det man även kom fram till var att grupper med låg expertis, i detta fall studenter, tenderade att öka graden av optimism i dessa gruppdiskussioner gentemot tiden det skulle ta att genomföra samma sprint. (Mahnic & Hovelja, 2012, Molokken-Ostvold, Haugen, Benestad, 2008). Det finns dock meningsskiljaktigheter kring vad som är den största anledningen till varför detta problem är så pass vanligt i agila projekt. Det finns även en uppfattning om att problemet härstammar i svårigheterna att kontinuerligt identifiera flaskhalsar under projekt. Att Kanban-tavlor och burn down charts och liknande verktyg för uppföljning som vanligtvis används under agila projekt saknar komponenter för denna identifiering (Petersen, Roos, Nyström, Runeson 2014). I en studie utförd av Petersen et al., (2014) presenterades ett verktyg, vars syfte var att identifiera och visualisera flaskhalsar i storskaliga agila projekt, för personer som upplevde detta som ett problem. Efter att ha fått återkoppling angående denna visualisering visade det sig att deltagarna vid presentationen ansåg att man troligtvis skulle få en förbättring i form av ledtider och genomflöde men det fanns en delad uppfattning huruvida visualiseringen skulle leda till bättre kvalité på produkterna (Petersen et al., 2014). Miranda och Borque (2010) anser likt Petersen et al., (2014) att problemet ligger i hanteringen av tid under projektets fortlöpande. Att man måste mäta framsteg med åtaganden relaterat till förbestämda kontrollpunkter under projektets gång. Detta för att kunna prioritera och fokusera användandet av resurser mot vart de behövs mest genom att identifiera flaskhalsar. Användandet av LOB i agila projekt tror man är lösningen på detta problem. Det ursprungliga syftet är att säkerställa att alla aktiviteter i en iterativ produktion ska hålla ett jämt flöde i en fart som är kompatibel med målen fastställda i en plan (Miranda & Borque, 2010). Miranda (2005) skrev en artikel om hur man teoretiskt kan bedriva uppföljning med LOB i en verksamhet som hanterar trouble reports som innebär beskrivning, rapportering och lösning av identifierade problem. En ny artikel publicerades av Miranda (2006) där det hade ägt rum en fallstudie på ett företag som hade denna typ av verksamhet. LOB hade i detta fall applicerats med goda resultat. Personer inom verksamheten upplevde det som att man fick ut mer relevant information från en statusrapport av denna typ samtidigt som det inte tog längre tid att konstruera en sådan jämfört med andra tidigare använda metoder (Miranda 2006). Tidigare forskning indikerar att LOB skulle kunna vara ett bra sätt att bedriva uppföljning, åtminstone för verksamheter med en etablerad process för att hantera trouble reports. Det som är av intresse nu är att kunna applicera LOB på flera arbetsformer som tenderar att leda till projekt som är svåröversiktliga och till följd av detta inte når fram till målen i tid. Miranda och Borque (2010) menar att de i en studie 2

8 har anpassat LOB till en metod som är applicerbar i ett agilt utvecklingsprojekt. Applicerbarheten exemplifieras med teori om Scrum och Feature Driven Development (FDD). Teorin har ännu inte testats i en verksamhet och därför anses det relevant att även testa om LOB rent praktiskt är applicerbart i en verksamhet som arbetar enligt en av arbetsformerna, Scrum. 1.3 Problem Ett agilt utvecklingsprojekt ska per definition var flexibelt och kunna hantera oförutsägbara förändringar i omgivningen internt, i form av nyinkomna krav och omprioriteringar, eller externt i form av ny lagstiftning eller sviktande konjunkturer. Behov prioriteras i agila projekt medan aspekter som tid och budget alltid är viktiga i projekt oavsett använd metod. De traditionella metoderna förespråkar en mer väldefinierad plan med en tidsram, i milstolpar, där behoven var ämnade att passa in, vilket för prioriteterna mer mot budget och tid. Det upplevda problemet hos verksamheten och även i andra sammanhang är att man inte vill välja det ena före det andra utan kunna ta det bästa från två världar. LOB är ett av flera förslag på lösningar för detta problem. Det som skiljer LOB från andra lösningar är att den inte är fokuserad på en aspekt av tid, som till exempel tidsuppskattning eller tidsåtgång, utan jämför de båda för att under förbestämda tillfällen kunna dra en relation mellan dem och konstatera nuläget för att nå fram i tid. Metoden ska även enligt teorin vara anpassad efter de agila metoderna vilket gör den ett föremål för att undersöka om den är applicerbar i agila kontext som komplement och därmed kunna ta hänsyn till både behov och tid. 1.4 Syfte och frågeställning I relation till problemet är syftet med denna undersökning att ta reda på hur en verksamhet bedriver projektuppföljning och planering enligt Scrum och varför det med den uppstår problem i relation till tid och budget. Det man vill göra är att bedriva en undersökande, kvalitativ datainsamling som grundar en analys vars syfte är att pröva teori om LOB och hur den kan användas i kombination med en redan etablerad arbetsform enligt Scrum. Undersökningen är en enskild behjälplig fallstudie, som fångar upp relevanta individers erfarenheter av problemet och dess kontext samt åsikter om den förslagna teorin. Studien förväntas besvara två undersökningsfrågor där den förstnämnda avser att ge en förståelse för fallföretagets kontext: F1: Hur hanterar den agila arbetsformen Scrum planering och projektuppföljning samt varför leder fallföretagets projekt till tidsöverträdelser på grund av denna? Svaret på den första frågan avser sedan att fungera som grund för att avgöra om line of balance kan appliceras på den agila arbetsformen Scrum. F2: Kan teori från line of balance appliceras för att komplettera Scrum utifrån aspekterna planering och uppföljning för att lösa problemet med tidsöverträdelser utan att hämma Scrums prioritet gentemot behov? 1.5 Avgränsning På grund av givna förutsättningar för tid och faktumet att en liknande undersökning ännu inte verkar ha bedrivits kommer det att ske begränsningar. Det anses vara realistiskt i relation till tid att genomföra en fallstudie med ett strategiskt urval på ett enskilt företag. Det anses också vara relevant med en fallstudie i denna omfattning eftersom det möjliggör en mer noggrann analys av det enskilda fallets kontext. 3

9 2. Teoretiskt ramverk Kapitlet för teori belyser existerande litteratur relaterade till ämnet. Under en fallstudie kan påståenden ses som förslag på generalisering. Detta för att man summerar sin upplevelse och sina tolkningar från fältet och adderar dem till egna erfarenheter och relevant litteratur (Creswell 2014). För att kunna bidra med ett sådant förslag stakas det nedan upp litteratur vars syfte är att senare jämföras med insamlad empiri. 2.1 Löpande projektuppföljning och 2.2 Agil planering och estimering syftar till att ge ökad förståelse hur fallföretaget arbetar relaterat till hur de teoretiskt bör arbeta. 2.3 Line balance beskriver den förslagna metoden som senare blir föremål för diskussion i en fokusgrupp som fortsättningsvis analyseras med teori och erfarenheter om den kontext där den teoretiskt ska passa in. 2.1 Löpande projektuppföljning Projekt kritiseras för att de inte håller tid och budget vilket Hallin och Gustavsson Karrbom(2012) menar kan motverkas genom en noggrann styrning av projektet eftersom det då går att fånga upp fördröjningar eller fördyrningar tidigt under projektet. Dessutom fungerar löpande uppföljning som beslutsunderlag för åtgärder som att tillsätta mer personal eller utrustning under projektets gång (Hallin & Gustavsson Karrbom, 2012). Tonnquist (2012) hävdar att täta delleveranser skapar engagemang hos de som utför arbetet, hos de som äger projektet och hos kunderna. Vidare menar författaren att det i en ledarroll är viktigt att upprätthålla kontroll över prestation och hur resurser spenderas gentemot vad som var planerat. Detta är fundamentala aspekter för att uppskatta projektets nuläge. För att säkerställa att ett projekt håller sig på rätt kurs behöver man fortlöpande följa upp utfallet och om nödvändigt göra förändringar. Man måste alltså både titta bakåt i tiden för att granska det man hittills har gjort och bedöma det arbete som återstår att göra. (Tonnquist, 2012, s.241) En ledare som inte vet hur projektet ligger till i förhållande till funktion, tid och kostnad samt som inte vet hur intressenterna uppfattar projektet kan inte styra projektet åt rätt håll (Hallin & Gustavsson Karrbom, 2012). För att upprätthålla detta förhållningssätt till projektledning stakas ett par övergripande aktiviteter upp som ska möjliggöra detta. Dessa citeras nedan från Tonnquist (2012, s.242): Kommunicera och rapportera Följa upp resultat gentemot tidsplan eller burndown charts Följa upp resurser och kostnader gentemot budget Analysera konsekvenser Hantera ändringar Följa upp avtal och resurskontrakt Av dessa aktiviteter är det en som är av större vikt för denna studie än de andra, nämligen att följa upp resultat gentemot en milstolpeplan eller burn down charts. Dessa två metoder kommer från olika projektfilosofier, varav den ena, tidsplanen kommer från en mer traditionell, sekventiell filosofi (Tonnquist, 2012) och den andra, burn down charts från en mer agil, iterativ filosofi (Schwaber & Sutherland, 2014). Med det agila förhållningssättet kallas tidsramarna för etapper istället för milstolpar (Tonnquist, 2012). Figur 1 nedan illustrerar en klassisk milstolpeplan. För närmare beskrivning av det agila förhållningssättet till planering och uppföljning, se kapitel 2.2 Agil planering och estimering. 4

10 Figur 1. Exempel på milstolpeplan Det man får ut av en milstolpeplan, se figur 1, och uppföljning av denna är vilka milstolpar som är klara i jämförelse med planen vid en viss tidpunkt (Tonnquist, 2012). Med denna plan styrs projektet mot det planerade målet inom ramarna för funktion, tid och ekonomi (Hallin & Gustavsson Karrbom, 2012). En milstolpe beskriver en väl definierad leverans där allt inkluderat ska vara uppfyllt innan den accepteras som nådd. Planen i sig är en uppsättning väl definierade milstolpar. Milstolpar kan tillåtas att flyta i tiden om det är nödvändigt för att de fördefinierade behoven ska bli uppfyllda. Markeringar över den streckade diagonalen visar att projektet ligger före plan, och markeringar under visar motsvarigheten (Tonnquist, 2012). 2.2 Agil planering och estimering Inledningsvis i ett projekt som arbetar agilt behöver en plan omfatta information om ungefär vilken tid projektet förväntas vara klart, t.ex. under vilket kvartal av året samt en uppskattad mängd och en ungefärlig beskrivning av funktioner. Detta för att intressenter ska få en grund för beslutsfattande. Senare i projektet behöver planen justeras så att den blir mer precis och därmed användbar som underlag för intressenter (Cohn, 2006). Planering under ett agilt projekt är viktigare än själva planen inför projektet. Eftersom förändringar bör uppmuntras eller åtminstone förväntas under projektet handlar det mycket om att balansera ansträngningar för planering med vetskapen att det så småningom ändå kommer att ändras. If you are planning a twenty mile trip, you should plan on looking ahead at least five times, once every four miles. Because you cannot see past the horizon, you need to look up often and adjust your plan. (Cohn 2006, s.27) Det finns en stor risk att fortsätta med en plan som passerat horisonten, dvs. det som på förhand finns en god uppfattning om. Författaren understryker vikten av att låta personen som planerar projektet få tid tillgänglig för att lyfta huvudet och vara mottaglig för omständigheter som leder till förändringar i planen (Cohn, 2006). I agila projekt hanterar man den dynamiska planeringen med uppföljningen i form av etapper. Den största skillnaden mellan en milstolpe och en etapp är att innehållet i en etapp inte är väl definierad på förhand utan accepterar nya behov under tiden. Tiden det får ta för att uppfylla behoven i en etapp är dock på förhand bestämd (Tonnquist, 2012) 5

11 Vid uppföljningsmöten diskuteras det med produktägare och om möjligt, kunder, hur prioriteringar ska ske i efterföljande etapp. Om det har tillkommit krav under föregående etapp är detta tiden för att diskutera hur det nytillkomna kravet ska prioriteras i relation till de redan definierade behoven för den efterföljande etappen (Tonnquist, 2012). Utifrån de förändrade omständigheterna görs nödvändiga ändringar i projektets leveransplan vars utformning skiljer sig mellan agila arbetsformer. SCRUM är en sådan arbetsform och även en med relevans för denna studie. Hur planeringen sker mer konkret kommer därför att förklaras med teori från arbetsformen SCRUM i efterföljande delkapitel SCRUM Schwaber och Sutherland (2014) är pionjärer bakom Scrum och definierar arbetsformen enligt följande citat: A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. (Schwaber & Sutherland, 2014, s.3) Vilket kan översättas till att det är ett ramverk som möjliggör att människor, inom ramarna, kan ta itu med anpassningsbara, komplexa, problem medan man produktivt och kreativt levererar produkter med högsta möjliga värde. Författarna är tydliga med att SCRUM inte är en teknik eller en process för att utveckla produkter utan snarare en uppsättning roller, händelser, artefakter och regler som alla har ett eget syfte för att leda till ett lyckat projekt. Artefakterna i ett projekt som arbetar enligt Scrum är av relevans för denna studie. De som finns är produktkatalogen som samlar den totala mängden arbete och etappkatalogen som består av mängden arbete som bör utföras under en enskild etapp. Den förstnämnda möjliggör skapandet av artefakten burn down chart. En burn down charts syfte är att illustrera arbetet kvar att göra och arbete genomfört i projektet, enligt figur 2. Detta bör illustreras så ofta som möjligt men åtminstone efter varje etapp (Dinwiddie, 2009). Figur 2. Exempel på hur en burn down chart kan se ut i ett projekt. Figur 2 visar mängden story points som för tillfället har avverkats i projektet och hur många som är kvar. En story point är ett värde som representerar och bestämmer hur pass omfattande en delfunktion är. Det går även att utvinna information om hur många story points det har avverkats under en enskild 6

12 sprint vilket gör att man kan dra paralleller mellan sprintar. Den visar negativa trender genom att kurvan för arbete genomfört blir flatare, dvs. färre story points blir tillgodoräknade, och det motsatta genom att kurvan blir brantare. Man kan även baserat på arbete genomfört illustrera ett estimerat slut på projektet (Dinwiddie, 2009). Det figur 2 inte redovisar är relationen mellan arbetet som är kvar och vad som bör vara kvar att göra om projektet ska motsvara förväntningarna man haft enligt plan. Inte heller visar den orsaken till negativa trender. 2.3 Line of Balance Denna metod använder man sig till fördel av när en repetitiv process äger rum under ett projekt. Ursprungligen vid produktion av material eller vid hopbyggnad av enheter i en fabrik (Harrof, 2008) samt på senare tid förslagsvis som en metod för att övervaka agila utvecklingsprojekt som också innebär repetitiva processer (Miranda & Bourque, 2010). I detta kapitel beskrivs LOB med det ursprungliga syftet och tillvägagångssättet samt hur det har anpassats för att kunna användas i agila projekt. LOB är en process som innebär att man hanterar kontrollen under ett projekt genom att mäta och presentera fakta som relaterar till tid, kostnad och åstadkommande i jämförelse med en förbestämd plan. Syftet är att kunna jämföra faktiska framsteg med de som är förväntade i planering och med fokus på avvikelser avgöra deras allvarlighetsgrad i relation till vad som är kvar att göra i projektet. Syftet är också att få information vid rätt tillfälle om problemområden som behöver ses över. I och med dessa syften ska det med metoden vara möjligt att med träffsäkerhet kunna förutse framtida prestationer (Harrof, 2008). LOB kommer från en grupp människor med George E. Fouch i spetsen som på Goodyear Tire & Rubber Company övervakade produktionen med denna metod, Det blev sedan applicerat under produktionsplaneringen och schemaläggningen av den amerikanska flottans mobiliseringsprogram under andra världskriget och visade sig även vara ett värdefullt verktyg för att ge synlighet under leveransbevakning av produktion under de Koreanska fientligheterna (Harrof, 2008). Metoden har anpassats för att passa i många olika sammanhang. Som till exempel för aktiviteter inom forskning och utveckling. Fortsättningsvis sker en demonstration för hur den från början är menad att fungera, hur den sedan har anpassats och därmed hur den nu fungerar i ett annat specifikt sammanhang (Harrof, 2008) Applicering av LOB i produktion LOB inleds med att specificera målet för projektet (Harrof 2008). Nedan följer ett exempel som visar att man har kontrakterats för produktion av 90 enheter inom tidsramen. Detta visas i det övre vänstra hörnet av figur 3. 7

13 Figur 3. LOB Chart över en hypotetisk tillverkning- och monteringsverksamhet (Harrof, 2008, Exhibit 1). I det nedre högra hörnet av figur 3 finner vi identifierade milstolpar som representerar en eller ett kluster av aktiviteter i projektet vars uppföljning blir föremål för kontroller (Harrof, 2008). Figur 3 visar i sin helhet, projektets tillstånd som det är den 10 maj, 97. Efter att ha bestämt projektets mål definieras en plan för att uppnå detta genom att kartlägga inbördes samband och hur varje del av föremålet passar i monteringsprocessen samt vid vilken tidpunkt delen är tänkt att ingå i processen (Harrof, 2008). Figur 3 visar att ledtiden för montering av ett enskilt föremål ska ta 24 dagar. Detta kan man se i den undre mittersta delen av figur 3. Den visar även hur många dagar in i den enskilda processen varje aktivitet måste vara utförd. I relation till denna ser vi i den övre högra delen av figur 3 hur processen faktiskt har gått till, alltså hur många enheter som har passerat en viss milstolpe vid den givna tidpunkten, som enligt exemplet är 10 maj, 97. Denna del kombineras med den blåa linjen som metoden är uppkallad efter, balanslinjen, som indikerar hur projektet presterar i relation till hur det bör prestera för att motsvara förväntningarna (Harrof, 2008). Vid den här tidpunkten kan man alltså se att produktionen skulle ha uppnått 48 enheter för att motsvara förväntningarna och man har istället producerat 38 enheter. Vid en närmare inspektion ska man vid tillfället utifrån detta diagram kunna identifiera flaskhalsar som leder till förseningen (Harrof, 2008). Dessa flaskhalsar synliggörs genom att de hamnar under den blåa balanslinjen Applicering av LOB i projekt med arbetsformen SCRUM Med en anpassning av LOB vill Miranda och Bourque (2010) ge projektledningen insyn och handfast information om projektets status. Även om yrkesverksamma som praktiserar agila metoder förespråkar att den största vikten ligger vid att veta att arbete blir gjort så finns det alltid intressenter som vill veta statusen av projektet (Miranda & Borque, 2010). Även fast planering inför ett agilt projekt som Cohn(2006) beskriver det ska vara en grov sådan så skall LOB vara anpassad för det. Genom att 8

14 uppskatta en ungefärlig mängd arbete från början och sedan ha metoden integrerad med ett vanligt förekommande versionshanteringssystem ska nyinkomna behov automatiskt adderas till produktkatalogen och därmed mängden arbete utökas. För att kunna avgöra projektets status poängterar författarna att vikten ligger vid att jämföra prestation med förväntan vilket förutsätter att det finns något att jämföra med. Detta medföljer att en större vikt bör läggas vid en inledande planering. Författarna insisterar dock att även fast metoden innebär en del förändringar så är den anpassad efter den dynamiska planeringen som agila projekt innebär (Mirande & Borque 2010). Eftersom SCRUM används i projekt som avser att utveckla programvara kan naturligtvis inte antal enheter i produktion användas som referens när man mäter mängden arbete. Istället används funktioner, användarfall eller ett poängsystem för användarfall som enhet när man mäter mängden arbete i ett projekt (Miranda & Bourque, 2010). Figur 4. LOB statusdiagram över hur många användarfall som ska ha passerat en fas vid en bestämd tidpunkt och hur många det bör ha passerat idealt i jämförelse med hur många som faktiskt passerade. I figur 4 används användarfall som mätbar enhet. De olika faserna motsvarar de sensorer använda i produktion. Genom att jämföra förväntade antal användarfall och faktiskt antal genomförda användarfall kan vi se i figur 3 att några användarfall har halkat i testfasen om 3 användarfall. Det går alltså att identifiera att det finns ett problem i faserna som kan riskera att förväntningarna på projektet inte möts. Detta är, likt den i produktion, grundtankarna bakom LOB. Inom terminologin för LOB är kontrollpunkten ett tillfälle i utvecklingsprocessen med bestämda kriterier för vad som ska vara klart, vilket gör dem föremål för mätningar av arbete under behandling och arbete som har passerat kontrollpunkten (Miranda & Bourque, 2010). Det blir alltså även relevant i detta sammanhang att mäta ledtider för ett enskilt användarfall (Miranda & Bourque, 2010), likt enhetens ledtid i produktion. En kontrollpunkts ledtid är den genomsnittliga tiden det tar för ett användarfall att ingå i en fas till att den avslutas (Miranda & Bourque, 2010). Här skiljer det sig, sett till hur man mäter ledtider, mellan LOB i produktion och Miranda och Bourque s (2010) förslagna applicering av LOB på SCRUM Uträkning av ledtider för användarfall Originalets tillvägagångssätt skiljer sig på så sätt att man kartlägger när aktiviteter ska påbörjas, dagar emellan, och avslutas vilket leder till att man kan uppskatta ledtiden för alla aktiviteter tillsammans och därmed för processen. För att kunna vara mottaglig för nyinkomna krav, i en föränderlig omgivning som 9

15 i agila projekt, så måste denna mätning ske annorlunda. Man räknar istället vid en valfri tidpunkt ut hur lång tid i snitt ett användarfall befinner sig i varje fas av processen i det pågående projektet (Miranda & Bourque, 2010). Tiden det tar för ett användarfall i en fas kalkyleras enligt formel 1. Formel 1. Tiden det tar för en specifik fas(q) i ett specifikt användarfall(i). Genom utföra en likadan uträkning för samma fas(q) i flera användarfall(i) kan man räkna ut medelvärdet och median för en fas samt även få individuella ledtider för den valda fasen. Data som behövs för att göra dessa kalkyleringar går att hämta ut från många versionshanteringssystem (Miranda & Bourque, 2010). Data som behövs är datum i relation till användarfallens övergångar mellan faser. Detta illustreras närmare i tabell 1 som visar datum för övergångar mellan varje fas och tabell 2 som visar distributionen av tider för varje fas. Startad Designad Testad Accepterad Utgiven 1 dec 2 dec 5 dec 8 dec 10 dec 1 dec 2 dec 4 dec 8 dec 9 dec 1 dec 3 dec 6 dec 9 dec 9 dec 1 dec 4 dec 10 dec 12 dec 13 dec 1 okt 2 okt 4 okt 7 okt 7 okt 1 okt 2 okt 5 okt 8 okt 9 okt Tabell 1. Visar exempeldatum om när ett användarfall(vertikalt) har ingått i en fas (horisontalt). 10

16 I \ Q Startad Designad Testad Accepterad 1 9=1+ 8=3+ 5=3+ 2= =1+ 7=2+ 5=4+ 1= =2+ 6=3+ 3=3+ 0= =3+ 9=6+ 3=2+ 1= =1+ 5=2+ 3=3+ 0= =1+ 6=3+ 3=2+ 1= =1+ 8=2+ 6=6+ 0=0+0 Median(d/f) Medelvärde(d/f) Median(Ledtid) Medelvärde(Ledtid) Tabell 2. Visar distributionen av tid i varje fas för ett användarfall(värdet höger om =) och distributionen av ledtider för varje kontrollpunkt(värdet vänster om =). Dessutom visas median och medelvärde för dagar i fas(d/f) och ledtid. Ledtiderna används senare för att upprätta ett statusdiagram för projektet vars syfte är att avgöra hur man ligger till i relation till plan och identifiera faktorerna som leder till det tillståndet. Enskilda tider i varje specifik fas för ett användarfall är också av intresse eftersom man kan härleda långa eller korta ledtider till personer bakom arbetet och användarfallets innehåll (Miranda & Bourque, 2010). Median kan vara att föredra före medelvärdet i detta sammanhang eftersom det motverkar att väldigt komplexa eller enkla användarfall gör statistiken missvisande (Mirandra & Bourque, 2010). 11

17 Beräkning av projektets status i relation till planering När ledtiderna har kalkylerats för så många användarfall som möjligt och beslut om att lita sig på statistikens median eller medelvärde har bestämts går det att kontrollera projektets status med LOB. Detta förutsätter dock att man har en fördefinierad leveransplan (Miranda & Bourque, 2010) enligt exemplet nedan, figur 5. Figur 5. Visar en leveransplan enligt LOB med y-axelns mängd återstående arbete i antalet användarfall i relation till projektets tidsram, x-axeln. Detta sätt att illustrera leveransplanen skiljer sig från originalets på så vis att den även visar en linje för hur projektet idealt ska prestera om det bedrivs i ett konstant flöde. Detta ska motverka onödiga reaktioner som följd av missade deadlines och fungera som indikator för negativa trender (Miranda & Bourque, 2012). Utöver den skillnaden så ska utgivningsplanen, likt originalet, jämföras med den faktiska prestationen vid en viss tidpunkt för att få fram projektets status. 12

18 Figur 6. Visar hur många användarfall som har genomförts vid en viss tidpunkt i jämförelse med planeringen och det optimala flödet. Vid en bestämd tidpunkt, som figur 6 visar ska 87 stycken användarfall vara utgivna för att man ska ligga enligt plan och uppfylla det förväntade vid nästa etapputvärdering. Utöver antalet utgivna så visar även staplarna hur många som bör ha genomgått varje fas enligt plan. Detta bestäms genom att man tar dagens datum och adderar den genomsnittliga ledtiden(eller median) för den kontrollpunkten. Som exempel är ledtiden för startad i genomsnitt 8.42 dagar, så antalet startade användarfall vid datumet 5/1 bör motsvara mängden utgivna vid datumet 13/5. För att få ut den ideala mängden använder man den ideala kurvan istället för den planerade vid datumet, så för samma exempel bör 106 st användarfall idealt vara startade den 1/5. Man kan i ovan figur 6 se att projektet motsvarar förväntningarna vid denna tidpunkt när det kommer till hur många användarfall som har startats och designats men hamnar efter planeringen vid test, acceptans och utgivning. Den största flaskhalsen som går att identifiera är vid testfasen då man vid denna tidpunkt förväntas ha testat 88 användarfall och det har endast testats 85. Den ideala prestationen är mycket högre än den planerade på grund av ett förväntat bortfall av arbetskraft vid denna tid till följd av jul-ledighet. Man förväntar sig inte att lägga sig i linje med det ideala flödet fören mot projektets förväntade slut. Trots de låga förväntningarna under denna tidpunkt så är projektet efter i planeringen vilket rättfärdigar en stark reaktion om missad deadline och indikerar att det finns en negativ trend i utvecklingen. Detta ska enligt LOB leda till att man ser över planeringen av det återstående arbetet och möjligtvis göra införskaffningar eller omprioriteringar av resurser (Miranda & Bourque 2010). 13

19 3. Metod Syftet med detta kapitel är att ge läsaren fullständig förståelse för hur studien bedrevs. Den bakomliggande filosofiska världsbilden inleder kapitlet som en utgångspunkt för de beslut som har fattats gentemot hur forskningen har designats (Creswell, 2014). Val av ansats beskriver abstrakt hur empiri har samlats in och val av metod för datainsamling beskriver processen mer konkret (Jacobsen, 2002). Fortsättningsvis behandlas valet av analysmetod och vad man behöver ta hänsyn till i form av validitet, reliabilitet och etiska ställningstaganden. 3.1 Vetenskaplig utgångspunkt Denna studie utgår från en social konstruktivistisk världsbild. Det innebär att man med studien vill förstå individernas sätt att arbeta på. Varje individ har sin egen uppfattning om verkligheten baserat på sin bakgrund vilket innebär att de kan bidra med ett subjektivt perspektiv på hur de upplever ett fenomen. När man kombinerar flera individers uppfattning om verkligheten får man då ett komplicerat, brett perspektiv på ett fenomen vilket bidrar till ett innehållsrikt föremål för analys (Creswell, 2014). Målet med studien var att helt förlita sig på individerna som ingår i den och använda sig av deras perspektiv för att förstå problemet och resonemangen kring lösningen. För att göra det behöver man även kartlägga den kontext som arbetet sker i och förstå den kulturella och historiska bakgrund som individerna har (Creswell, 2014). Sammanfattningsvis ska betydelsen för studien växa fram från det sociala forumet där interaktionen mellan människor är källan för empiri. Det är vanligt att forskare som bedriver fallstudier utgår från en konstruktivistisk världsbild (Baxter & Jack, 2008). 3.2 Val av ansats Ansatsen för studien balanserar mellan att vara deduktiv vilket innebär att forskaren prövar teori genom att jämföra den med hur det ser ut i verkligheten och induktiv som innebär att man samlar in empiri med så få förutfattade meningar som möjligt (Jacobsen, 2002). Den induktiva ansatsen låter forskaren ta del av verkligheten med ett öppet sinne (Jacobsen, 2002) vilket kan anses som en fundamental grund för att man med en konstruktivistisk världsbild ska kunna ta del av andras perspektiv med en så objektivt synvinkel som möjligt. På ett induktivt sätt tog undersökningen del av informanters erfarenheter om problem och kontext. Sedan diskuterades det utifrån erfarenheterna om den förslagna teorin är applicerbar. Det fanns på förhand inga antaganden om hur den skulle uppfattas men trots det så var syftet att bekräfta eller förkasta teori vilket lutar mot en deduktiv ansats. 3.3 Val av metod för datainsamling En kvalitativ metod har använts för att samla in data. Kvalitativa metoder har inte avsikten att ta fram något generellt utan de är det speciella och unika som är av intresse (Jacobsen, 2002). Det som är det speciella i detta fall är det upplevda problemet om att inte lyckas föra ett projekt i mål inom den givna tidsramen och det unika är den föreslagna lösningen. För att kanalisera detta intresse till något som är intressant ur en forskningssynpunkt såväl som för verksamheten som upplever problemet har en fallstudie ägt rum. En fallstudie innebär att man ska gå in på djupet och ta fram en helhetsanalys av ett fall (Creswell, 2014). Typen av fallstudie kan baseras på syftet med den, om syftet till exempel är att den ska vara behjälplig för det enskilda fallet genom att identifiera ett problem för att sedan illustrera det så är fallstudien av typen enskild behjälplig fallstudie (Single instrumental case study). Det finns två till typer där den ena kallas samlad eller mångfaldig fallstudie som även den har syftet att identifiera ett problem men som skiljer sig genom att illustrera problemet med flera fall. Den tredje typen kallas för verklig fallstudie och den innebär att man fokuserar sig på ett speciellt fall som är av intresse för att den är unik eller ovanlig utan ett identifierat problem (Creswell, 2006) Fallstudien som har bedrivits i denna undersökning är av typen enskild behjälplig fallstudie eftersom man utifrån ett identifierat problem hos verksamheten illustrerar problemet i ett enskilt fall. Genom att 14

20 diskutera problemet och en potentiell lösning kan det finnas möjligheter med att fallstudien, i linje med typen av studie, även blir behjälplig. Diskussionen nämnd ovan har skett i en fokusgrupp. Vilka som ingår och hur den har genomförts kommer att redovisas i de efterföljande kapitlen Urval och Genomförande. En fokusgrupps syfte är att samla in kvalitativ data, från en grupp människor som har något gemensamt. Deltagarnas diskussion riktas specifikt mot det de har gemensamt vilket gör att det är interaktionen mellan deltagarna som utgör empirin (Hylander, 2001). Det gemensamma i detta fall är det upplevda problemet, projektuppföljning och hur man kan lösa det, möjligtvis med hjälp av LOB. Fokusgrupper kan användas som enda metod för att öka förståelse, förklara och generera teori, i explorativt syfte om ett komplicerat fenomen (Hylander, 2001) Urval En fokusgrupp drar fördel av att urvalet är så homogent som möjligt. Att de har några gemensamma karakteristiska drag för att kommunikationen emellan deltagarna ska hämmas så lite som möjligt (Hylander, 2001). Det kan därför vara av intresse att bestämma deltagare genom ett strategiskt urval. De som har deltagit i den inledande fokusgruppen var 2 stycken projektledare och 4 stycken produktägare som utgör 75 % av populationen som består av ledarroller om 2 projektledare och 6 produktägare inom utvecklingsavdelningen. Hyllander (2001) menar att dagens rekommendationer för antalet deltagare vid en fokusgrupp är 6-10 personer. Syftet med detta strategiska urval var att de för tillfället sköter den verksamhet som är av intresse, dvs. planering, organisering och uppföljning av projekt vilket gör att de har det upplevda problemet gemensamt. Utöver urvalet av deltagare, som ska väljas efter syftet för undersökningen, så bör även plats, situation, händelse och process bestämmas på förhand (Creswell, 2014). Eftersom en fallstudie bör äga rum under naturliga förhållanden för deltagaren, i en trygg omgivning (Hylander, 2001), bunden till plats och tid (Jacobsen 2002), så kommer fokusgruppen äga rum på utvecklingsavdelningen på fallföretaget i ett lämpligt konferensrum. För att en fallstudie ska vara relevant att bedriva så bör fallets kontext vara i fokus för att förstå hur deltagarna tolkar ett fenomen (Baxter & Jack, 2008) Genomförande Före genomförandet av gruppdiskussionen förbereddes en powerpointpresentation, se bilaga 1, som inledningsvis beskrev några av de nuvarande sätten att följa upp projekt som ansågs vara relevanta för verksamheten. Detta var beskrivningar av en milstolpeplan och två olika användningsområden för en burndown chart. Fortsättningsvis visades och beskrevs en leveransplan enligt LOB och hur man under ett givet tillfälle kalkylerar ledtider för enskilda användarfall samt hur lång tid de befinner sig i en enskild fas under utvecklingen. Efter det presenterades det ett statusdiagram för projektet som först efter kalkyleringen av ledtider kan konstrueras. Detta statusdiagram ledde sedan till en beskrivning av vad man kallar LOB, ett stapeldiagram som visar arbete genomfört i varje fas relaterat till hur mycket man bör ha genomfört om projektet ska förhålla sig till planen. Denna presentations prövades i form av en pilotstudie på en grupp studenter som har arbetat på företaget, enligt arbetsformen Scrum. Efter pilotstudien genomfördes relevanta ändringar i presentationen med hänsyn till kommentarer från studenterna. Under presentationen på fallföretaget, som varade i ungefär 7 minuter, ställdes det frågor och yttrades förtydliganden som kan visa sig vara intressanta för att avgöra hur pass väl deltagarna under diskussionen förstår det nya verktyget. Utifrån presentationen ägde sedan diskussionen rum som var tänkt och upplevdes som öppen, dvs. det ställdes inga konkreta frågor. Det uppstod självutnämnda teman kring problemet och lösningen vilket ledde till en önskad diskussion kring egna erfarenheter gentemot de egenkonstruerade temana. 15

21 Diskussionen pågick i 48 minuter vilket utgör en total tid på 55 minuter med fokusgruppen och samtlig tid spelades in med mikrofon. Moderatorns roll under diskussionen var att besvara frågor kring LOB och annan relevant teori kring ämnet. Inga åsikter yttrades av moderatorn om hur LOB kan användas till fördel eller nackdel under projekt. Detta på grund av att moderatorn inte innehar någon form av praktisk bakgrund som skulle kunna härleda teorin som en fördel eller nackdel gentemot deras kontext. 3.4 Val av analysmetod Hyllander (2001) menar att det inte finns några speciella riktlinjer för hur data från fokusgrupp bör dokumenteras och analyseras. Alla kvalitativa analysmetoder som kan användas på text är applicerbara och baseras på hur man har valt att dokumentera datainsamlingen. Vissa menar enligt Hyllander (2001) att man utifrån en inspelning, eller från minnet av diskussionen, endast skriftligt bör sammanfatta den medan andra tycker att en inspelning är ett krav och att ord för ord bör återges i skrift. Fokusgruppen spelades som tidigare nämnt in vilket gav en ljudinspelning om 55 minuter. Denna har sedan transkriberats ord för ord, kopplat till en deltagare under tillfället, bortsett från det moderatorn sade under tillfället. Detta är enligt linje med det första steget i Creswell (2014) förslag på hur man bör analysera kvalitativ data som innebär att man transkriberar, organiserar och arrangerar data efter dess källa och mening. Steg två innebär att man läser igenom materialet för att försöka få ett generellt intryck av fokusgruppens inställning och uppfattningar (Creswell, 2014). Detta intryck har sammanfattas i ett stycke för att få en generell bild av fokusgruppen. Vidare ska man enligt Creswell (2014) koda data vilket innebär att man plockar ut segment och kategoriserar den under lämpliga kategorier. Detta har också skett i enlighet med Creswell (2014) förslag och kommer att utgöra studiens resultat, kapitel 4.2 Resultat. Senare i studien analyseras kategorierna utifrån den kvalitativa metoden fallstudie. Enligt Creswell(2014) ska man utifrån en noggrann beskrivning av fallets kontext analysera teman och problem i relation till teori och tidigare forskning. I studien har teman bestäms som blir föremål för jämförelse med bakomliggande teori och för diskussion kring fokusgruppens kontext. 3.5 Validitet och Reliabilitet År 2003 skrev Riege(2003) en artikel om hur validitet och reliabilitet bör testas vid insamling av kvalitativa data. Han hävdar att validitet och reliabilitet är viktigt för att säkerställa undersökningens stabilitet och kvalité(riege 2003). Det finns några grundläggande aspekter som bidrar till detta. Dessa aspekter innebär att man bör ha en tydlig, väldefinierad frågeställning, vars svar med goda förutsättningar kan grundas i en fallstudie. Att det finns ett syfte med de valda datainsamlingsmetoderna samt att data samlas in systematiskt och analyseras korrekt. Detta bidrar till att personer som tar del av studien själva kan avgöra undersökningens validitet och trovärdighet (Baxter & Jack 2008). Utifrån Riege(2003) kommer validitet att diskuteras kring termerna begreppsvaliditet samt inter- och extern validitet. Tillförlitlighet kommer att vara det centrala begreppet för reliabilitet Validitet Begreppsvaliditeten bestäms utifrån vilka logiska samband man drar mellan empiri och slutsats. Man avgör alltså om slutsatserna man drar är de mest lämpliga utifrån insamlad data (Riege, 2003). Det som leder till hög begreppsvaliditet är förmågan att beskriva användandet av metoder i detalj, påvisa att man har fått med alla relevanta aspekter och säkerställa att all data finns tillgängligt för en ny analys (Riege, 2003). Det som på förhand kan garanteras är att all data finns tillgänglig för eventuell analys sen är det upp till läsaren att bedöma resterande aspekter för begreppsvaliditet. Intern validitet innebär att man avgör undersökningens trovärdighet. Detta säkerställs genom att låta informanterna granska transkriberad data och bekräfta dess riktighet eller låta dem ändra felaktigheter (Riege, 2003). För att ytterligare öka undersökningens interna validitet bör man återberätta 16

22 tillvägagångssättet för insamlingen så att läsaren kan avgöra om den har bedrivits på ett lämpligt sätt (Riege, 2003). Utöver att ha skickat ut transkriberad data till informatörerna för bekräftelse har även en pilotstudie uträttats innan undersökningen på fallföretaget. Pilotstudiens syfte var att just säkerställa att den bedrivs på ett lämpligt sätt och tillvägagångssättet återberättas under Genomförande vilket ger läsaren en chans att avgöra lämpligheten själv. Extern validitet är enligt Riege (2003) jämförbar med begreppen överförbarhet. Alltså hur pass väl undersökningen skulle kunna appliceras i ett annat fall. Det som tyder på hög extern validitet är dels att det tillhandahålls tydliga beskrivningar som ger läsaren en möjlighet att själv avgöra om studien är applicerbar på deras verksamhet. Dels kan hög validitet innebära att insamlad data på något sätt är kopplad till tidigare teori (Riege, 2003). Denna studie anses ha hög validitet eftersom det finns en stark koppling till tidigare teori och en transparens i utförandet av undersökningen och resultatet av den. Rent spontant är uppfattningen att denna studie skulle kunna vara applicerbar i ett annat sammanhang och verksamhet som upplever samma problem Reliabilitet Uppskattningen av studiens tillförlitlighet baseras på hur tekniker eller procedurer är konsekventa under undersökningen (Riege, 2003). Vilket tolkas som att sättet man styr insamlingen av data på inte ska skilja sig mellan tillfällen för datainsamling. I detta fall finns det inga skarpa tillfällen att jämföra med eftersom alla informanter ingick i samma fokusgrupp. Det skulle kunna tolkas som att alla informanter utsattes för samma tekniker och att reliabiliteten därmed ökar. Det skulle också kunna tolkas som att tillförlitligheten blir väldigt låg eftersom det inte finns något tillfälle att jämföra med och därmed ingen möjlighet att avgöra reliabiliteten. 3.6 Etiska ställningstaganden Inför en undersökning är det viktigt att ta hänsyn till den forskningsetik som relaterar till hur man på ett professionellt sätt bedriver en undersökning. Det finns standarder som beskriver etiska dilemman och möjliga lösningar, ofta kopplade till en bransch eller vetenskap (Creswell, 2014). Nedan kommer relevanta etiska dilemman diskuteras i relation till den förslagna undersökningen, dvs. hur man bedriver en fallstudie och använder sig av fokusgrupper med god forskningsetik. Istället för att följa en viss standard föreslår Creswell (2014) etiska dilemman som är bra att ta hänsyn till innan en undersökning påbörjas, när den påbörjas, under tiden data samlas in, angående hur data analyseras och hur man väljer att rapportera och lagra data. Införskaffa nödvändiga tillstånd, vilket innebär att man innan undersökningen får tillstånd från en kontaktperson med lämplig auktoritär position inom företaget som innebär tillträde till verksamheten och lämpliga informanter (Creswell, 2014). Detta blir onekligen en relevant aspekt vid en fallstudie och tidigt i projektet upprättades det kontakt med ledningen för den avdelning inom företaget som var av intresse. Där upprättades muntligen ett tillstånd om att få ta del av de resurser som krävs för att studien ska bli lyckad. Välj en plats utan investerade intressen, innebär kort att det inte är en bra idé att bedriva en undersökning vars resultat har personlig betydelse. Detta skulle i en kvalitativ undersökning leda till att man inte tar med de perspektiv som leder till ett, för en själv, ogynnsamt resultat (Creswell, 2014). Detta dilemma beaktas för att undersökningen bedrevs av en person som tidigare har praktiserat på företaget under en kort period. Den personliga uppfattningen är dock att det inte finns några förväntningar på resultatet eftersom det är från en undersökning med ett explorativt syfte. Identifiera ett fördelaktigt forskningsproblem, när man bestämmer ett problem är det viktigt att det är ett som är relevant för verksamheten och dem som ingår i undersökningen och inte bara för forskaren (Creswell, 2014). I detta fall är det verksamheten som har identifierat problemet och de som påverkas av problemet är informanter i datainsamlingen vilket bör leda till att resultatet blir behjälpligt ur någon synpunkt. Detta leder också till att man avslöjar syftet med undersökningen för de som ingår vilket 17

23 Creswell (2014) också tycker är ett viktigt hänsynstagande. Respektera möjlig maktobalans, här syftar Creswell (2014) på balansen mellan informatör och moderator. Han menar att man måsta ta hänsyn till hur känsligt ämnet är, vilket makt informatören har över moderatorns tolkningar och vilka konsekvenser intervjun kan leda till för informatören i sin verksamhet. Lösningen är inte att jämna ut maktbalansen utan att respektera den (Creswell, 2014). Det uppstår viss makt från moderatorns sida eftersom det skiljer sig mellan 2 projektledare i fokusgruppen som innehar en ledarroll över de resterande 4 informanterna. Under fokusgruppen uppfattades inte detta som ett problem då båda parter ofta var överens men vid tillfällen de inte var det hade de inga problem med att uttrycka sin åsikter och konstatera att det fanns meningsskiljaktigheter kring ämnet. Undvik att ta informatörernas sida och undvik att endast visa positiva resultat, Vid behandling och analys av insamlad data är det lätt att ta informatörernas sida och endast diskutera det som försätter informatörerna i ett positivt ljus. Det kan leda till att man inte tar hänsyn till data som skulle kunna bekräfta eller förkasta en hypotes eller svara på en frågeställning med ett mer fullständigt resultat (Creswell, 2014). Vidare menar Creswell (2014) att det även är dålig forskningsetik att endast redovisa resultat som är positivt för undersökningen. Detta innebär i en kvalitativ undersökning att allt som datainsamlingen gav ska finnas tillgängligt och all relevant data, vare sig det talar för eller emot det önskvärda, ska redogöras i undersökningens resultat (Creswell, 2014). Samtliga åsikter under fokusgruppen har transkriberats och finns tillgängligt som rå data. Utöver det har relevant data tagits ut och redovisas under undersökningens resultat och då inkluderas även data som talar för ett negativt svar på forskningsfrågan. Utöver ovanstående ställningstaganden finns det en del etiska dilemman som berör dokumentation och delning av arbetet. Det får till exempel inte förekomma någon form av plagiering eller fabricering och inga ska komma till skada till följd av undersökningen (Creswell, 2014). Dessa ses som naturliga hänsynstaganden när det kommer till dokumentering och rapportering. 18

24 4. Empiri För att få värdefull kunskap från en fallstudie behövs en noggrann beskrivning av miljön som den bedrivs i för att kunna ta hänsyn till den vid vidare analys gentemot insamlad data och relevant teori(creswell, 2014). Därför presenteras först en kort beskrivning av fallföretaget i detta kapitel, följt av en redogörelse av resultatet från undersökningen. 4.1 Beskrivning av fallföretag Fokusgruppens diskussion ägde rum på företaget Fortnox i Växjö. Sedan starten i början av 2000-talet har Fortnox vuxit till Sveriges ledande leverantör av webbaserade affärssystem med kunder (Fortnox, 2014). Affärsidén bakom Fortnox är att fullt ut använda den nya internetbaserade teknikens möjligheter till att leverera unika fördelar inom affärsområdet administrativa rutiner och tjänster. Detta innebär att de ska erbjuda sina målgrupper ett brett sortiment med effektiva administrativa lösningar som stöttar deras dagliga behov. Med hjälp av volymbaserade skalfördelar ska de leverera dessa program till låga priser och med så hög lönsamhet som möjligt (Fortnox, 2014). I juni 2014 fastställdes mål för verksamheten som innebär att Fortnox för varje år fram till år 2020 ska ha en genomsnittlig tillväxt om 25 % och en rörelsemarginal om 20 %. Deras övergripande mål är att Fortnox ska vara marknadsledare inom affärssystem till mindre företag i Sverige (Fortnox, 2014). Sedan den 6 oktober 2014 tillträdde Sara Arlidsson som vd för Fortnox och med henne sitter det en utvecklingschef, försäljningschef, eftermarknadschef, marknadschef och en HR-chef i företagsledningen(fortnox, 2015). Utifrån samtal med verksamheten uppskattades ungefär 50 % av företaget sitta på utvecklingsavdelningen. På avdelningen återfinns delområden som test, drift och utveckling som tillsammans utgör en arbetskraft om ungefär 50 personer. Av dem består avdelningsledningen av 6 stycken produktägare och 2 stycken projektledare. Utvecklingsverksamheten utvecklar programvara enligt arbetsformen Scrum eller med komponenter från Scrum kombinerat med egna metoder och tekniker. De använder sig av samverkansverktyget JIRA för att hantera och spåra deluppgifter i projekt, för att exempelvis se i vilken fas av utvecklingsprocessen en deluppgift befinner sig. Mer specifikt ägde fokusgruppens diskussion rum i ett konferensrum som rymmer 8 personer. Inredningen består av 8 stolar kring ett litet bord och en whiteboardtavla. En widescreen TV vars storlek uppskattas till 50 tum fanns även till hands, med möjligheter att koppla in dator. På denna widescreen presenterades teori med en powerpoint, se bilaga Resultat Detta avsnitt kommer att presenteras under på förhand och efterhand definierade teman som utgör relevanta aspekter för vidare analys. Dessa teman är valda efter relevans för studien, förståelse för LOB, i relation till forskningsfrågorna, planering och uppföljning, dess kontext som innebär förändringar samt en identifierad värdefull aspekt, flaskhalsar. Sammanfattningar om vad den generella uppfattningen kring temat är samt citat som styrker den och åsikter som talar emot uppfattningen kommer att utgöra resultatet av undersökningen. Informanternas roller i studien listas nedan: A, F: Projektledare B, C, D, E: Produktägare Förståelse för LOB Under presentationen av LOB och under diskussionen ställdes det frågor och förståelsen för LOB ville informanterna ytterligare ha bekräftad genom att konstatera sina uppfattningar om den. Detta gav en tidig indikation på att de var intresserade av att åtminstone diskutera den förslagna lösningen. Att metoden var förstådd bekräftades senare genom att flera deltagare försatte metoden i sammanhang från egna erfarenheter i stil med följande citat: 19

25 B: Det beror ju på. Så gör vi delvis redan idag. Vi tar fram statistik till Jocke. Det är ju lite, ja, man hade ju lika gärna kunna ta fram data till de här graferna. B: När det gäller själva datan så är det säkert något vi kan få ut från våra existerande system, vi vet ju. Våra statusar heter ju andra saker. Själva grunddatan har vi ju. Om man skulle vilja prova med den statistiken enligt den här. Men som sagt vi har ju fortfarande det här grundproblemet med scopet då. Det finns liksom inget projekt där vi har scopet klart. Som inte redan är slutfört då. Även härledningar till vilka verktyg man kan använda för att utvinna relevant data för metoden yttrades: A: Om vi skulle börja med det här skulle vi behöva prata med JIRA rätt mycket. Och med lite bearbetning av data så skulle man få fram detta. Samt ett intresse för att undersöka metoden närmare: A: Kan man inte applicera detta på redan slutförda projekt för att se hur det såg ut 3 månader in i det här projektet enligt data som fanns då? Planering av milstolpar/etapper Under detta tema pågick diskussionen kring termer om vad informanterna kan, bör och måste göra eller inte göra för att få en stabil planering och projekt. Det blev tydligt att det skiljer sig mycket mellan projekt men att en gemensam nämnare var estimering av mängden arbete och återstående tid. Att det skiljer sig mellan projekt blir tydligt med detta citat: B: Nej, och vi jobbar lite olika i olika projekt dessutom. I mina projekt skapar jag epics som består av stories och sen får teamet själva bryta ner det i stories som är lagom för dem att jobba med. Och det gör ju dom på sprintbasis. En story är en motsvarighet till användarfall och en sprint motsvarar en etapp. Ovanstående citat är ett svar på en kommentar om att de inte jobbar med att på förhand definiera upp så mycket som möjligt utifrån vad de vet. Men andra erfarenheter och kommentarer indikerar att det kan finnas ett intresse för att göra det: B: När jag gjorde min milestone-lista, och jag har ändå sålt in det här till produktrådet. Att det här är scopet och sen har jag bara dragit till med att det kommer kosta så här mycket pengar. För det är den data som jag har då, men där har jag ändå tänkt scope. Sen handlar det ju bara om att detaljera ner det i rätt form. Data finns ju och sen skulle man kunna estimera hur mycket varje tar. Det blir ju inte sådana här snygga grafer av det kanske. Scopet är den totala mängden arbete för projektet. Fortsättningsvis menar en informant, i ett annat sammanhang, att det är upp till en själv hur mycket man är villig att förbereda inför ett projekt eller en del av ett projekt: C: Man kan ju bestämma hur mycket man ska bestämma innan man börjar den här delen av projektet också, hur mycket fördel man ska ha innan man skiter i allting, i förstudien ska du fanimej ha bestämt vilket programspråk du ska använda, kolla så att man har folk som kan det osv. Det väljer man ju, hur mycket man vill förbereda. Vi kanske väntar lite och tar allt när vi har börjat ibland och det blir lite obehagligt. Och det finns även yttranden som poängterar att någon form av plan inför ett projekt är viktig för att kunna kontrollera projektets status: F: Det blir lättare att motivera varför vi blev sena i det projektet i sådana fall. Men allting kommer 20

26 tillbaka till en bra planering med milstolpar och liknande, att ni verkligen äger produkten på det sättet. Alla sådana här(statusdiagram) blir bara så här bra om det inte är ett välgrundat projekt ifrån början. Det blir tydligt att rapportering och motivering gentemot företagsledningen är en av orsakerna till varför man vill kunna fastställa projektets status och planera mera. Detta blir även tydligare med nedanstående citat: B: Det hör ju lite till konflikten, att vi ska jobba agilt och såhär men ändå så har vi en ledning som vill veta vad det är jag får och hur mycket kommer det att kosta. Där av kanske det inte är så dumt att definiera upp några milestones i alla fall. Annars har vi ju ingen aning om vi ska lägga 3 man-år på detta. Liksom vart landar vi någonstans. Hur mycket får man för dem pengarna? Även fast det finns ett intresse för att på förhand definiera upp så mycket som möjligt så är alla överens om att detta är extremt svårt göra dessa estimat i en föränderlig omgivning som är en del av den agila mjukvaruutvecklingens natur: B: Jag vet ett problem som vi har här, det är ju att vi oftast inte vet den totala mängden vilket gör det väldigt svårt att estimera och få en bra burn down, vi vet inte om det är 250 eller 400 storypoints vi kommer att göra i det här projektet. Ovanstående citat relaterar till att uppskatta mängden arbete i projektet vars upplevda problem resulterar i en svårestimerad tidsåtgång för projektet: B: Man kan ju gissa(datum) per milstolpe, hur mycket man delar upp det och hur många storypoints det är på en sådan Om mängden då ändras kommer tidsestimatet bli fel. Informanterna diskuterar mycket kring hur man skulle kunna lösa svårigheterna med estimat när det vid tillfällen inte finns data att grunda dem på. B: Man kan ju, jag skulle kunna skapa upp epics för alla mina milestonesdelar till exempel men då får man räkna med 20 % osäkerhet i de 5 närmsta och 35 % i de kommande 5. Man kan ju sätta upp någon sådan schablon. Och i ett annat sammanhang: B: Om man då lägger på en schablon på varje milstolpe för osäkerhet. Alltså det är klart att det fortfarande blir en gissning men det är en mer rundad gissning. Just nu är den inte det alls. I grund och botten är man intresserad av att kunna illustrera projektets status och för att göra det är man medveten om att en inledande planering är viktig. Man tror att problemet beror på att förändringar i omgivningen inte går att ta med i beräkningen och därför blir den inledande planeringen lidande till följd av att det är svårt att estimera mängden arbete Projektuppföljning Det råder ingen tvekan om att uppföljning under projekt som grundar sig på data är önskvärt trots att förutsättningarna för att kunna bedriva en sådan uppföljning är problematisk. När informatörerna jämför LOB med deras nuvarande metoder för uppföljning gavs följande kommentar: F: Precis. Syftet är ju ungefär densamma. Målet är ju definitivt densamma. Att vi någonstans vill se någon form av progress i data och inte bara gå på magkänsla. Problemet är dock precis samma sak, vi vet inte det totala scopet. Man kan se lite trender och sådant i det jag ber er fylla i men det är ju inte heller någonting att men det vore skönt att se att vi har 60 av 100 stories gjorda så vi är 60 % in kan man säga. Sen kan det vara så att man har 65 av 110 nästa gång och då ser man att kraven utökades, det var så tanken kom upp men det bygger ju fortfarande någonstans på att man i början 21

27 lägger in allt man vet då för att det ska funka. Ett förslag på hur man kan kringgå behovet av att estimera ett helt projekt och ändå bibehålla fördelen med att kunna mäta statusen ges: F: Jag tänker om man bryter ner det, att man inte tänker sig att man har ett fullständigt scope i alla projekt utan att man har ett fullständigt scope per milstolpe åtminstone. Om det på något sätt går att mäta progressen per milstolpe då Det man också säger är att oavsett hur pass väldefinierat projektet är på förhand så går det ändå att få ut relevant information ur en status: F: Och att man någonstans säger som produktägare att vi har 5 milstolpar men dom är inte 20 % var utan den är ju 30 % och den är nog bara 20, alltså så att man någonstans ändå kan säga uppskattade datum och då kan man ju någonstans iaf tycka att vi borde vara där första maj, blir det den första juni så betyder det då med största sannolikhet att vi även är sena i slutet också. Men det blir väldigt mycket uppskattningar, man skulle helst vilja ha mer data att gå på Hantering av förändringar Ett resonemang som fångar upp problemet med föränderliga omgivningar relaterat till hur mycket en utvecklare vill ha fördefinierat inför ett projekt gavs under diskussionen: B: Det är också lite hur mycket ni på utvecklingssidan vill bryta ner saker till stories och planera med vetskapen att vi på den här sidan av bordet(produktägare) kan ändra på förutsättningarna innan ni hinner jobba med det, det är lite därför man väntar med att analysera och bryta ner, det kan ju alltid ändras liksom. Och svaret på detta blir från en projektledare som ansvarar för utveckling: A: Det blir waste i sig. Att speca grejer långt i framtiden för det vi alldeles säkert vet är att det kommer ändra sig och vi kommer behöva ändra det igen så nej det är vi inte speciellt sugna på. Frågan är då hur långt man måste speca för att kunna sätta milestones. Man måste gärna ha ett estimat ju. Den generella uppfattningen om hur man löser förändringar för tillfället är att informanterna prioriterar om. Det informanterna helst gör inom verksamheten är att skjuta fram datumet för att i så stor utsträckning som möjligt uppfylla alla behov. B: I de allra flesta fall i våra projekt så är det innehållet som har prio. Det vill säga att vi flyttar fram datumet om vi inte är klara med det vi hade tänkt. Men det är alltid intressant att veta när det är klart, det finns alltid folk som är intresserade av det Identifiering av flaskhalsar En komponent i LOB som fokusgruppen uppskattade var möjligheten att identifiera flaskhalsar. Detta blir tydligt med följande citat: A: Jag gillar tanken att man mäter throughputten så att man ser att, oj, vad vi utvecklar men det blir inte testat. Eller tvärtom, här borta sitter test och gör ingenting och här gör de jättemycket, kan vi göra någonting åt det? F: Det tangerar ju lite det som vi försöker åstadkomma med dem här manuella datan som vi fyller i då. Just för att kunna identifiera om det kanske är en flaskhals på test. (Fliker in)eller om någon är utlånad till andra projekt. (Fortsätter) Exakt, så det är någonstans det här vi vill åstadkomma. 22

28 De resonerade i samband med detta när det är relevant att försöka identifiera flaskhalsar: A: Men då blir det svårt att veta om man har problem under de 2 veckorna utan då blir det egentligen att tillfället man hämtar ut datan blir efter en sprint, det blir relevant då. Då kan du se att den här låg i 13 dagar och så testades den, den 14de och så blev den utvecklad den förste. Det är kanske det man är ute efter. Hur skulle det påverka de här diagrammen? En av informatörerna var inte av samma åsikt som de andra angående identifieringen av flaskhalsar. Han menade att de är lätta att identifiera ändå: B: Förutom det dära, ja vi ligger efter på test, men det vet man ju vid varje sprintslut om man har saker som inte är testade så, det behöver vi egentligen inga siffror för att veta Resultat som talar för och emot LOB Efter föregående avsnitt är det lätt att anta att det som mest talar emot ett användande av LOB är svårigheten att på förhand definiera en plan för hur mycket arbete som ska vara genomfört över tid, indelat i sprintar och ett förväntat slutdatum. När man under ett tillfälle talar om LOB rent allmänt uppstår denna dialog: A: Men jag kan ändå inte låta bli att känna att det finns en stor risk för sådana här false positives. Det finns fortfarande väldigt mycket som är okänt hela tiden som kan hända som kan försena allting med 100 %. F: Men som sagt om teamet då sprint efter sprint ligger efter med test? A: Ja, sant och det kan vi mäta om vi är ineffektiva under arbetet men jag tänker om vi ändå kan forecasta när vi faktiskt går live. F: Nej, nej det tror jag inte. Det informatören menar med forecasta är förmågan att förutse. Utöver dessa kommentarer som talar emot LOB så var det också kommentarer som på ett rikligt sätt beskriver behovet av den: F: I sådana stora projekt kan det finnas en fördel med att mäta det tidigt jämfört med business caset, alltså att du ändå har uppskattat, en väldigt grov uppskattning då att det ska ta så här lång tid om man delar upp det i x antal milstolpar. Så någonstans kan man få ett datum på att vi borde vara klara med milstolpe 1 där för att hålla det som business caset bygger på. Och det kanske är intressant att veta att vi ligger på det datumet, ungefär kring den tidsplanen eller att man ska flagga för att det här business caset stämmer inte bra längre. Den poängen finns ju med att då har man ju i alla fall den här förväntat linjen någonstans. Och det verkar som att informanterna kontinuerligt under diskussionen upptäcker fler fördelar med metoden, här i form av att man kan motivera varför ett projekt behöver längre tid: F: Om någonting(en plan) har blivit godkänt så att säga, det här blir bra, nu kör vi. Man kanske behöver argumentera för att få in det där(en story). Det kanske fortfarande är 1.0 som är planerad vilket gör att det blir även tydligare att vi var överens om att det där ska vara med så därför tar det en månad till utifrån det som var planerat. Och man visar att det finns en vilja att pröva: B: Det bör gå att göra en förstudie på detta eftersom vi har all data som behövs. Det blir genast mer intressant om man applicerar det på riktigt data. 23

29 5. Analys och diskussion Här kommer uppfattningen av fenomenet LOB i relation till problem och kontext att analyseras och diskuteras kopplat till teori och tidigare forskning. Inledningsvis sker en generell analys följt av en mer specifik relaterad till de teman som tillsammans bildade resultatet samt en sammanfattning av detta. Egenkonstruerade diskussioner kommer att ske löpande i samband med analysen och en mer ingående diskussion om metod äger rum under avsnittet 5.7 Metoddiskussion. Analysen ska fortsättningsvis leda till att slutsatser kan dras relaterat till frågeställningen i efterföljande kapitel. 5.1 Analys av generell uppfattning Den generella tolkningen av fokusgruppens inställning var att den förhöll sig vara skeptisk, problemfokuserad men ändå förväntans- och hoppfull. Man upplevde att problemet med projektuppföljning härstammade i en, på förhand, svårestimerad mängd arbete och förändringar under projektets gång. Intrycket var att svårigheter med estimat har varit ett diskuterat ämne sedan tidigare men möjligtvis inte i detta forum. Det som fångade informanternas uppmärksamhet mest från en positiv synvinkel angående LOB var identifieringen av flaskhalsar. Det som talade emot LOB mest var den på förhand definierade mängden arbete. Detta är helt i linje med vad Cohn (2006) menar med att planering under ett agilt projekt är viktigare än själva planen inför projektet. Eftersom förändringar bör uppmuntras eller åtminstone förväntas under projektet handlar det mycket om att balansera ansträngningar för planering med vetskapen att det så småningom ändå kommer att ändras. Den svårhanterliga estimeringen är på grund av att det endast går att estimera den tid det tar för mängden arbete man har kännedom om i nuläget. Vilket enligt Cohn (2006) är en naturlig del av ett agilt projekt och ska behandlas därefter genom att kontinuerligt under projektet lyfta huvudet och greppa nya omständigheter för projektets fortlöpande. Cohn (2006) pratar om förändringar relaterat till mängden arbete, exempelvis nya behov men jag anser att det finns flera syften med att lyfta huvudet kontinuerligt under projektet och det visar även resultatet av undersökningen. Vid detta tillfälle skulle man exempelvis kunna identifiera flaskhalsar och eventuellt prioritera om resurser. Enligt Miranda och Bourque (2010) har LOB, under deras arbete, anpassats för att kunna appliceras på agila projekt, närmare bestämt Scrum och Feature Driven Development, men det finns inget som styrker att den faktiskt är applicerbar på dessa arbetsformer. Det visar sig ganska snabbt med åsikter och teori om att en fullständig fördefinierad plan inte bör eller kan vara en del av ett agilt projekt. Det finns dock ingenting som talar emot en ytterligare anpassning av metoden, som till exempel göra den mer dynamisk i planeringen och försöka motsvara idéer från empirin om att istället planera och följa upp per milstolpe. 5.2 Planering av milstolpar/etapper Diskussionen antydde att det inte finns en gemensam standard för planering hos informanterna utan det är produktägarnas ansvar att bestämma hur den ska gå till inför varje projekt. Några informanter pratar om planering i milstolpar och andra i sprintar vilket gör att det blir svårt att bestämma fallets kontext som fenomenet LOB ska passa in i. Min tolkning är att de arbetar enligt Scrum som arbetsform med sprintar om två veckor men även med en mer långsiktig planering i milstolpar. Alla uppfattar LOB som att det krävs en för omfattande planering inför projekt för att man ska kunna ta del av dess fördelar men samtidigt resonerar informatörerna också kring vad de för tillfället gör och skulle kunna förbättra för att kunna ta del av fördelarna. Som sagt under fokusgruppen behöver man ibland illustrera ett tänkt projekt i form av ett business case. Som enligt Cohn (2006) är för att motivera för intressenter varför projektet behövs, ungefär hur mycket det kommer att kosta och ungefär hur lång tid det kommer att ta. För att få en ungefärlig tid och kostnad behöver man göra någon form av uppskattning av mängden arbete vilket informanterna då gör. Mirandas (2006) fallstudie med appliceringen av LOB på problemrapporter utgick från en fördefinierad mängd rapporter och den ursprungliga appliceringen av LOB i produktion utgår ifrån en specificerad 24

30 mängd producerade enheter. Därför kan antaganden dras om att de förbisåg problemen med en fördefinierad plan i ett agilt projekt och därför inte anpassade den därefter. Informatörerna menar sedan att förhållandet mellan business caset och det faktiska genomförandet kommer att vara underlag för att motivera för ledningen varför projektet behöver mer tid eller resurser. De var inne på att LOB skulle kunna hjälpa till med detta eftersom man inledningsvis kan illustrera förväntningarna på projektet baserat på business caset och sedan använda dessa förväntningar som referens när man avgör projektets status. När man i inledande planen motiverar projektet och gör en uppskattning av komponenterna som behövs för ett business case kan det i samband med detta även bestämmas ett sätt att illustrera det på. Som en av informatörerna var inne på så bestämmer de som produktägare själva hur mycket de vill bestämma innan projektet påbörjas, bestämmer man för lite upplevs situationen som obehaglig. Faktum är att informanterna innehar ledarroller vars syfte är att leda arbetsgrupper enligt den agila arbetformen men det finns även ett behov från företagsledningens håll att få kontinuerlig status och en inledande uppskattning om projektets budget och tidsåtgång. Dessa två talar emot varandra eftersom ledningens behov inte uppfylls av den bedrivna arbetsformen utan talar för en mer traditionell sekventiell stil där de på förhand bestämmer mängden arbete, tid och budget. Det verkar finnas en vilja om att försöka uppfylla ledningens behov samtidigt som informanterna inte vill frångå sitt agila arbetssätt. Det uppstår alltså en konflikt där man vill komma åt det bästa från två världar. Den ena som prioriterar kunden och dess behov genom att kontinuerligt vara öppen för förändringar under projektets gång. Den andra som inom en tidsram och budget definierar mängden arbete. Enligt informanterna så innebär den ena problematik för den andra, exempelvis när de vill motivera för ledningen varför de behöver mer tid och budget för att uppfylla fler behov. En statusrapport som tydligt illustrerar behovet av detta är vid tillfället användbar men förutsättningarna för att kunna tillhandahålla en sådan verkar kontraproduktiv när det kommer till att uppfylla kundernas behov. En idé som kom upp är den som innebär att man planerar detaljerat men kortsiktigt i sprintar och milstolpar och då skulle projektet enligt tidigare analys och diskussion kunna gå till på följande sätt: A) Ett business case med en grov uppskattning av arbete och en ungefärlig tid författas. B) En leveransplan fastställs. C) En mer detaljerad plan över de kommande sprintarna, som utgör en milstolpe, genomförs och appliceras på leveransplanen. D) Efter varje sprint avgörs projektets status och E) efter varje milstolpeslut definieras och uppskattas nästa period av sprintar. F) Leveransplanen ändras för att motsvara de förändrade omständigheterna. Även om en sådan anpassning skulle vara genomförbar så är det inte vad teorin om LOB förespråkar. Enligt teori om agil planering så bör planeringen ske kontinuerligt där beslut grundas på det man vet för tillfället. Därför resoneras det kring hur schabloner kan användas när de vet mängden arbete men det blir fortfarande gissningar. Skillnaden blir att det finns utrymme för felgissningar. Informatörerna pratar om hur det skulle vara intressant att applicera LOB på riktig data, möjligtvis på ett redan avslutat projekt. Det som då är teoretiskt genomförbart är att de utvinner data från JIRA om när varje användarfall genomgick respektive fas i ett avslutat projekt och sedan jämför det med vart de trodde att projektet skulle vara vid ett valt tillfälle. Det gör det även möjligt att identifiera om det var flaskhalsar som ledde till ett försenat projekt eller om det var en stor mängd nyinkomna krav. Denna idé öppnar för en användning av LOB som ett lärande system med historisk data att gå på vid planering och uppskattning av tid, samt vart det möjligtvis behövs mer resurser vid nästkommande projekt. 5.3 Projektuppföljning Som Tonnquist (2012) och informanterna är inne på så är uppföljning av avtal och resurskontrakt en av aktiviteterna som behövs för att avgöra om projektet är på rätt kurs. Sedan går Tonnquist (2012) igenom flera aktiviteter som ska säkerställa detta och en av dem är uppföljning gentemot tidsplan eller burn down chart. Om man istället skulle illustrera arbetet med LOB och gör uppföljningar gentemot denna 25

31 menar jag att det skulle täcka alla aktiviteter och inte bara vara en av aktiviteterna. Man kan med en statusrapport enligt LOB kommunicera projektets status, se resultatet jämfört med tidsplanen, analysera konsekvenser i form av flaskhalsar och hantera ändringar genom att minska eller utöka produktkatalogen (Miranda & Bourque, 2010). Denna typ av information skulle enligt informatörerna vara skön att få kontinuerligt under ett projekt men för tillfället går dem oftare på magkänsla än historisk data. Man resonerar kring när statusen skulle vara bäst lämpad att få och de flesta var överens om att det skulle vara bäst att fastställa den efter man har genomfört en sprint. Detta talar för idén om att man per milstolpe bryter ner och uppskattar mängden arbete mer detaljerat eftersom uppföljningen i så fall bör ske med tätare mellanrum, exempelvis efter varje sprint. Informationen om hur man ligger till i projektet kan då lätt bli missvisande eftersom man inte har vetskapen om hur efterföljande sprintar och milstolpar ser ut på detaljnivå. Detta menar också informanterna är fallet och att man måste passa sig för så kallade false positives. Men det finns annan nyttig data att utvinna ur dessa täta statusrapporter. Utöver att visa information om vart projektet ligger i förhållande till planen så kommer statusen indikera i vilken takt man måste arbeta i för att nå det förväntade målet med milstolpen i tid som i sig är viktig information enligt informanterna. Utifrån den kan informanterna med bakomliggande data realistiskt prioritera nyinkomna krav och identifiera om det finns några flaskhalsar i utvecklingen som kan leda till problem om de inte hanteras. Problemet med detta resonemang är att det talar för en prioritet gentemot tid även fast Scrum och informanterna talar för att prioriteten ska ligga i behoven. 5.4 Hantering av förändringar Enligt Miranda och Bourques (2010) teori skiljer det sig när det kommer till att hantera dessa ändringar med LOB i jämförelse med hur man gör med en burn down chart. Med en burn down chart kan nyinkomna användarfall enligt Dinwiddie (2009) läggas till i produktkatalogen och sedan hanteras i nästkommande sprintplanering. Detta är även fallet med Miranda och Bourques (2010) LOB men det skiljer sig i hur man tar bort behov i en pågående utvecklingsprocess. Istället för att endast subtrahera ett användarfall från en burn down chart måste man med LOB utöver att ta bort användarfallet från produktkatalogen även kontrollera vilka faser den har ingått i och då subtrahera användarfallet därifrån också. Det jag vill säga med denna teori är att oavsett när ändringarna sker så går de att behandla på ett lämpligt sätt men det tar längre tid. I fokusgruppen diskuterar informanterna hur mycket de behöver speca för att få ett bra estimat i relation till vad estimatet får för värde om det ändå kommer att förändras. Informanterna menar att merarbete behöver äga rum vid dessa förändringar och det uppfattas som waste, alltså icke-värdeskapande tid. Istället för att i nuläget endast subtrahera ett på förhand definierat användarfall så kommer det krävas ytterligare lite tid om det skulle ske enligt LOB. Den icke-värdeskapande tiden blir alltså den inledande planeringen av användarfallet som inte kommer till användning samt tiden det tar att hantera borttagningen. Eftersom förändringar både enligt teorin och informanterna är en naturlig del av projektet måste en balans upprättas för att minska den, enligt informatörerna, icke-värdeskapande tiden så mycket som möjligt samtidigt som man måste vara beredd på den. Att planera kortsiktigt med täta uppföljningstillfällen anses även vara en lösning för det man talar om angående detta tema. Att de vid varje uppföljning konstaterar vilka förutsättningar de har för att behandla nyinkomna behov. Baserat på nuläget kan de avgöra om de behöver skära ner mängden arbete, kan utöka mängden arbete eller om de behöver förlänga milstolpens tid och därmed projektets genom att addera en ny sprint. Att skära ner mängden arbete är något som informanterna väldigt sällan vill göra. 5.5 Identifiering av flaskhalsar Under uppföljningen av projektet vill man ha en övergripande bild över dess tillstånd i relation till planen men också en specifik anledning till varför det förhåller sig på sättet det gör. Analys av konsekvenser utgör en av Tonnquist(2012) aktiviteter för att säkerställa projektets fortlöpande. Med LOB görs det 26

32 genom att identifiera vart i utvecklingsprocessen det uppstår flaskhalsar och sedan undersöka varför dessa uppstår (Miranda & Bourque, 2010). Informatörerna gick in på att de redan har en metod för att försöka identifiera dessa och att LOB tangerade syftet med denna metod fast baserat på data istället för produktägarens erfarenheter. Förslaget om att med korta intervaller undersöka projektets status leder till ett ökat värde för identifiering av flaskhalsar. Genom att fastställa statusen enligt LOB får man en klar indikation om vilken av faserna som inte motsvarar förväntningarna vid det tillfället. Detta gör att man på mikronivå kan omplacera resurser för att vid nästa uppföljning avgöra hur det har påverkat balansen i projektet. Saknaden av denna förmåga i agila projekt är en av anledningarna till att projekt går av över tid och budget enligt Petersen et al. eftersom en oidentifierad flaskhals kan vara orsaken till att utvecklingstakten blir långsammare tidigt i projektet och därmed påverkar hela projektets fortlöpande. Deras forskning var ämnad för storskaliga projekt och därför kan relevansen i denna kontext diskuteras eftersom begreppet storskalig är relativ vilket kan betyda att det som en av informanterna säger kan vara möjligt. Det han menade var att det vid varje sprintslut går att avgöra om det har uppstått några flaskhalsar i projektet och att det inte behövs någon data för identifiera dem. 5.6 Sammanfattning Tidigare forskning pekar på olika anledningar till varför ett agilt projekt tenderar att gå över tid och budget och har försökt lösa problemet på olika sätt. Mahnic, Hovelja (2012) och Molokken-Ostvold et al. (2008) härledde problemet till svårigheter med att uppskatta tid och föreslog en lösning som man sedan testade. Även fast detta skulle kunna vara en del av lösningen så kvarstår informanternas upplevda problem med att uppskatta mängden arbete vilket behövs för att kunna uppskatta tiden. Här föreslår informanterna istället att man bestämmer mängden arbete på kort sikt i enlighet med Scrum och uppskattar tiden med hjälp av erfarenhet och schabloner vars syfte är att fungera tidsbuffert. Fortsättningsvis anser Petersen et al. att problemet ligger i oförmågan att kontinuerligt identifiera flaskhalsar vilket de menar är ett resultat av de illustrationer som används i agila projekt, till exempel burn down charts som saknar komponenterna som behövs för identifiering. Denna aspekt är av informanterna sedan tidigare behandlad och anses som viktig men det är också tydligt att det inte är en helhetslösning. Det är också enligt en informant inte ett problem eftersom det enligt hans erfarenhet går att avgöra om det finns flaskhalsar under ett projekt utan att behöva gå på data. Idealt sätt vill man under ett givet tillfälle under projektet kunna avgöra när projektet kommer ta slut och hur mycket det kommer att kosta samtidigt som det ska leverera det förväntade värdet. Generellt för projekt inom mjukvaruutveckling och i synnerhet inom de som bedrivs med agila arbetsformer är det omöjligt att med säkerhet bestämma det. Det man istället vill ha är en dynamisk planering och en konstant uppfattning om nuläget för att tillgodose alla behov. Det informanterna verkar vilja ha är en kompromiss mellan det agila förhållningssättet och en bra grund för kommunikation med företagsledningen. Miranda och Bourque(2010) anpassade LOB för att passa i agila projekt men de glömde att ta hänsyn till de inledande förutsättningarna som finns i ett sådant. Trots det finns det komponenter i LOB som skulle vara uppskattat av en verksamhet likt den informanterna sitter i. Det informanterna inser är att ytterligare anpassningar behöver göras om metoden skulle vara aktuell. Att göra en anpassning skulle medfölja omprioriteringar i form av tid framför behov vilket talar emot en arbetsform enligt Scrum och talar för ett steg tillbaka mot den mer sekventiella stilen att utveckla med en bestämd tidsram och budget som behoven måste prioriteras efter. 5.7 Metoddiskussion Enligt Baxter och Jack (2008) bör en fallstudie användas när frågeställningen är av hur- och varförtypen och när det inte går att påverka informanterna i studien. Antingen är det viktigt att beskriva fallets kontext för att det utgör relevant information för det undersökta fenomenet eller så är gränserna mellan fenomenet och verksamheten otydliga. 27

33 För det första så är frågorna av typen hur och varför för att på ett explorativt sätt undersöka informanternas upplevelse av fenomenet. För det andra går det inte att manipulera informanterna eftersom det inte finns någon speciella antaganden hos moderatorn och därför ingen ståndpunkt att försöka rikta informatörerna emot. Den tredje aspekten går att diskutera eftersom fallets kontext utgör relevant information om huruvida fenomenet passar in i den samtidigt som gränserna mellan fenomenet och verksamheten är otydliga eftersom fenomenet tidigare inte har försatts i dess kontext. Detta tycker jag redogör för att den valda metoden är relevant för ändamålet. Däremot går det att diskutera omfattningen av undersökningen med den valda metoden. Det skulle vara fördelaktigt att diskutera fenomenet i flera sammanhang med liknande kontext för att med jämförelser kunna få ett bredare perspektiv att grunda sina antaganden på. Eftersom nästan hela ledningen i den relevanta verksamheten deltog i denna undersökning så menar jag här en jämförelse med en ledning på ett annat företag med samma arbetsform. Huruvida en presentation kan vara en tillräcklig grund för att pröva en teori går även att diskutera. Inledningsvis presenterades, av dem, redan använda metoder för att sedan mer detaljerat beskriva den nya teorin. Detta för att kunna dra paralleller mellan dem och försätta den nya teorin i ett sammanhang. Under diskussionen var moderatorns roll att hela tiden tillhandahålla teori om fenomenet vid behov. Resultatet visade sedan att det fanns en förståelse för hur line of balance enligt teorin ska användas genom att informanterna kunde applicera fenomenet i sammanhang och resonera kring hur den skulle kunna användas i deras kontext. När man talar i termer som fenomen kan det lätt bildas en uppfattning om att undersökningen skulle kunna bedrivas med en fenomenologisk metod. Detta anser jag inte är fallet eftersom en fenomenologisk metod avser att undersöka människors upplevda erfarenheter av ett fenomen vilket skulle ge en felaktig bild av resultatet eftersom den enda erfarenheten av fenomenet är en presentation om den. Om man däremot skulle genomföra en förstudie med LOB som metod i ett projekt skulle en sådan undersökning i efterhand kunna bedrivas. 28

34 6. Avslutning Följande kapitel presenterar undersökningsstudiens slutsats baserat på analysavsnittet och syftar till att besvara de inledande undersökningsfrågorna. Vidare presentas förslag till fortsatt forskning. 6.1 Slutsats Kombinationen av empiri och bakomliggande teori om deras agila förhållningssätt med Scrum som arbetsform utgör mycket att säga om hur projektuppföljning sker eller inte sker i deras kontext. Man förespråkar en väldigt grov planering på förhand vilket inte blir något bra underlag för senare uppföljning under ett projekt. Det man vanligtvis går på är en illustration som visar mängd genomfört arbete kontra arbete kvar men eftersom förändring ligger i filosofins natur säger illustrationen inte så mycket om var man ligger i förhållande till de förväntningar som finns på projektet. Att jämföra ett uppskattat slutdatum på projektet med när det faktiskt kommer att avslutas blir ingen lätt uppgift och om man nu kan det finns det ingen data att gå på som indikerar vart det behöver ske förändringar för att man ska nå fram i tid. Fallföretaget prioriterar uppfyllda behov framför att projektet avslutas i tid som i sig skulle kunna vara en faktor till att projekten ofta överstiger det uppskattade slutdatumet men som nämnt ovan finns det många andra aspekter som kan leda till det. Det handlar om prioritet och per definition ska det enligt Scrum vara behov som prioriteras, detta medför att tiden inte blir lika viktig och tidöverträdelser anses vara ett nödvändigt ont. Angående hur LOB skulle kunna komplettera Scrum ur ett planeringsperspektiv så anses det vara ett krav att anpassa den ytterligare efter arbetsformen. Åtminstone leveransplanen och komponenten som motsvarar linjen för förväntan. Den fördefinierade planen talar emot de grundläggande principerna för ett agilt projekt och den upplevs även som en omöjlighet i det studerade fallet. Den skulle möjligtvis råda bot på problemet om tid-och budgetöverträdelser men då i samband med ett mer sekventiellt sätt att arbeta på, som i produktion. Ett mellanting med en fördefinierad plan med arbetsformen Scrum anses vara kontraproduktivt eftersom det i slutändan kommer att leda till merarbete och en strävan mot att prioritera tid och budget framför behov vilket talar emot syftet med den agila filosofin. I och med detta anses LOB inte kunna komplettera Scrum utifrån ett planeringsperspektiv. Användningen av LOB för uppföljning upplevs ändå kunna vara fördelaktig för verksamheten i förhållande till välgrundade diskussioner med företagsledning och andra intressenter. LOB kan användas till att identifiera flaskhalsar som kan vara orsaken till en låg utvecklingstakt. Den kan avgöra hur pass allvarligt det är när projektet inte motsvarar förväntningarna och fungera som bas för beslut om resursfördelningar. Dessutom är den en bra illustration för att tydligt illustrera projektets status, varför projektet har det tillståndet och utifrån det motivera varför projektet behöver mer tid eller resurser. Detta förutsätter dock att en fördefinierad plan finns vilket tidigare konstaterades som inkompatibelt med Scrum. Fördelarna som identifieras faller på att line of balance ursprungligen kommer ifrån produktion som är mer sekventiell och förutsägbar än agila projekt samt att den, trots vad teorin beskriver den som, inte är anpassad tillräckligt för agila projekt. Svaret på andra undersökningsfrågan blir därför att teori från line of balance inte kan komplettera Scrum utifrån aspekterna planering och uppföljning. Även om LOB inte kan appliceras i ett pågående projekt så finns det fördelar med att använda det på ett redan avslutat för att utvinna information om vilken felmarginaler informatörerna har vid uppskattning av tid och orsaker till varför ett projekt blev försenat. LOB som ett lärande system. Är det försenat på grund av nyinkomna krav är det ekonomiskt försvarbart gentemot företagsledningen medan om det är på grund av flaskhalsar så går det att motivera för företagsledningen varför ett nästkommande projekt behöver mer resurser. En kunskapsbank kan även bildas som förslagsvis används för att göra mer välgrundade och exakta estimat i tid. I längden kan det möjligtvis användas för att skapa ett mer välgrundat business case. Detta skulle kunna råda bot på problemet med tidsöverträdelser i viss mån eftersom aktuella personer får en grund att utgå ifrån vilket kan leda till mer medvetna beslut gällande estimering. 29

35 6.2 Förslag på fortsatt forskning För att spinna vidare på metoddiskussionen om omfattningen av denna undersökning så anser jag att det skulle vara relevant att bedriva vidare forskning som fokuserar på att jämföra olika fall för att reda ut hur agil projektuppföljning och planering ser ut i olika kontext. Kan denna konflikt relaterat till prioriteringar av budget och tid kontra behov identifieras i fler verksamheter? I samband med detta eller i en enskild undersökning skulle man kunna genomföra en pilotstudie med LOB som verktyg för projektuppföljning och avgöra hur den rent praktiskt kan appliceras i olika kontext. Till exempel i en verksamhet som arbetar mer sekventiellt eftersom denna fallstudie indikerar att den inte är applicerbar i en kontext som innebär agila arbetsformer. Dessutom skulle det vara intressant att veta hur värdefullt LOB är som ett lärande system enligt förslaget i slutsatsen. Det skulle möjligtvis kunna bedrivas en fenomenologisk studie mot informanter som har använt sig av den på detta sätt. 30

36 7. Referenser Baxter, P., Jack, J.(2008) Qualitative Case Study Methodology: Study Design and Implementation for Novice Researchers The Qualitative Report (2008) Vol. 13, Nr. 4 s Bloch, M., Blumberg, S., Laartz, J.(2012) Delivering large-scale IT projects on time, on budget, and on value. McKinsey & Company Cohn, M. (2006) Agile Estimating and Planning Pearson Education Inc. Creswell, J W.(2014) Research Design: Qualitative, Quantitative, and Mixed Methods Approaches. University of Nebraska, Lincoln: Sage publications, inc. Creswell J W. (2006) Qualitative Inquiry & Research Design: Choosing Among Five Approaches Sage publications Ltd Dinwiddie, G. (2009) Feel the burn getting the most out of burn charts StickyMinds.com: Better software Fortnox (2014) Delårsrapport januari- september Fortnox (2015) Om fortnox [ ] Fortnox(2015) Styrelse och ledning Hallin, A., Gustavsson Karrbom, T. (2012) Projektledning Malmö: Liber AB Harroff, N N.(2015) Line of Balance Hylander I. (1998) Fokusgrupper som kvalitativ datainsamlingsmetod (FOG-RAPPORT NUMMER 42) 1998; rev Linköping: Linköpings universitet Jacobsen, D I(2002) Vad, hur och varför? Om metodval i företagsekonomi och andra samhällsvetenskapliga ämnen Lund: Studentlitteratur AB Mahnic. V., Hovelja.T (2012) On using planning poker for estimating user stories. The Journal of Systems and Software(2012) Volym. 85, s Miranda, E., Borque, P. (2010) Agile monitoring using the line of balance. Journal of Systems & Software(2010), Vol. 83, s Miranda, E. (2006) Using Line of Balance to Track the Progress of Fixing Trouble Reports Cross Talk, STSC (2006) Vol. 19 s23-25 Miranda, M. (2005) Using Line of Balance To Track The Progress Of Fixing Trouble Reports Montreal, Quebec: Eduardo Miranda, September 21, 2005 Molokken-Ostvold, K., Haugen,N C., Benestad, H C.(2008) Using planning poker for combining expert estimates in software projects(2008) Vol. 81, s Palmquist S M., Lapham M A., Miller S., Chick, T., Ozkaya, I.(2013) Parallel Worlds: Agile and Waterfall Differences and Similarties Carnegie Mellon University 31

37 Petersen, K., Roos, P., Nyström, S., Runeson, P. (2014) Early identification of bottlenecks in very large scale system of systems software development Journal of software: Evolution and process(2014) Volym. 26, s Riege, A M. (2003) Validity and reliability tests in case study research: a literature review with hands-on applications for each research phase Qualitative Market Research: An International Journal (2003) Vol. 6 Nr. 2 s Sampaio T C., Pinheiro, P R., Tamanini, I. (2014) Project management aided by verbal decision analysis approaches: a case study for the selection of the best SCRUM practices International Transactions in Operational Research(2015) Vol. 22 Nr. 2 s Schwaber, K., Sutherland, J.(2014) The Scrum Guide. Scrum.Org and Scruminc. Wang, X., Conboy, K., Cawley, O. (2012) Leagile software development: An experience report analysis of the application of lean approaches in agile software development. The Journal of Systems & Software(2012) Vol. 85, s

38 8. Bilagor Bilaga 1: Presentation för fokusgrupp 33

39 Bilaga 1 Bilaga 1 Presentation av fokusgrupp (antal sidor: 5) Genomförd :30-14:37 Moderator: Martin Mattsson Åhörare och informatörer: A: Jesper Svensson Projektledare B: Olof Hiller Produktägare C: Victor Grevik Produktägare D: Martin Runosson Produktägare E: Anna-Lena Skeppstedt Produktägare F: Joakim Henrixon Projektledare och projektkoordinator Figur A. Presentation av moderator och ämne 1

40 Bilaga 1 Figur B. Kort beskrivning om milstolpeplaner, enligt teorin för löpande projektuppföljning Figur C. Kort beskrivning av burn down chart, enligt teorin för Scrum 2

41 Bilaga 1 Figur D. Kort beskrivning av en burn up chart, inkluderas ej i teorin om Scrum men användes för att identifiera vilken av varianterna som informatörerna relaterade till i sin kontext vilket var varianten enligt Figur C. Figur E. Beskrivning av en leveransplan enligt LOB, enligt teorin för Applicering av LOB i agila projekt. 3

42 Bilaga 1 Figur F. Beskrivning om kalkylering av ledtider i LOB, enligt teori om ledtider under Applicering av LOB i projekt med arbetsformen Scrum. Figur G. Fortsättning av beskrivning om kalkylering av ledtider i LOB, enligt teori om ledtider under Applicering av LOB med arbetsformen Scrum. 4

43 Bilaga 1 Figur H. Beskrivning om hur man konstruerar ett statusdiagram med LOB, enligt teori om statusdiagram under Applicering av LOB i projekt med arbetsformen Scrum. Figur I. Beskrivning av hur den slutgiltiga statusrapporten ser ut vid ett givet tillfälle och vad namnet line of balance kommer från, enligt teori om applicering av LOB i projekt med arbetsformen Scrum. 5