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

Storlek: px
Starta visningen från sidan:

Download "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 https://www.fortnox.se/delarsrapport-januariseptember-2014/[ ] Fortnox (2015) Om fortnox https://www.fortnox.se/om-fortnox/ [ ] Fortnox(2015) Styrelse och ledning https://www.fortnox.se/om-fortnox/styrelseoledning/[ ] 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

Anvisningar till rapporter i psykologi på B-nivå

Anvisningar till rapporter i psykologi på B-nivå Anvisningar till rapporter i psykologi på B-nivå En rapport i psykologi är det enklaste formatet för att rapportera en vetenskaplig undersökning inom psykologins forskningsfält. Något som kännetecknar

Läs mer

729G27. Pilot, skrivande och avslutning. Johan Blomkvist IDA-HCS-IxS Twitter: @hellibop

729G27. Pilot, skrivande och avslutning. Johan Blomkvist IDA-HCS-IxS Twitter: @hellibop 729G27 Pilot, skrivande och avslutning Johan Blomkvist IDA-HCS-IxS Twitter: @hellibop Dagens Skrivande Piloten Rester från förra gången validering Någon slags sammanfattning 2 Jag är på semester till 16

Läs mer

Collaborative Product Development:

Collaborative Product Development: Collaborative Product Development: a Purchasing Strategy for Small Industrialized House-building Companies Opponent: Erik Sandberg, LiU Institutionen för ekonomisk och industriell utveckling Vad är egentligen

Läs mer

BESKRIVNING AV PROCESSMETODEN SCRUM

BESKRIVNING AV PROCESSMETODEN SCRUM NORDSCRUM BESKRIVNING AV PROCESSMETODEN SCRUM NORDSCRUM BESKRIVNING AV PROCESSMETODEN SCRUM INNEHÅLLSFÖRTECKNING inledning... 3 SCRUM... 3 Bakgrund... 3 Faser... 3 Ramverket... 3 Nordscrum... 4 StudentProjekt...

Läs mer

Automation Region. Affärsdriven systemutveckling genom agila metoder. Stefan Paulsson Thomas Öberg

Automation Region. Affärsdriven systemutveckling genom agila metoder. Stefan Paulsson Thomas Öberg Automation Region Affärsdriven systemutveckling genom agila metoder Stefan Paulsson Thomas Öberg Frontit Frontit är ett svenskt konsultföretag i gränslandet mellan Management & IT, som stärker sina kunders

Läs mer

Teknikprogrammet Klass TE14A, Norrköping. Jacob Almrot. Självstyrda bilar. Datum: 2015-03-09

Teknikprogrammet Klass TE14A, Norrköping. Jacob Almrot. Självstyrda bilar. Datum: 2015-03-09 Teknikprogrammet Klass TE14A, Norrköping. Jacob Almrot Självstyrda bilar Datum: 2015-03-09 Abstract This report is about when you could buy a self-driving car and what they would look like. I also mention

Läs mer

Utveckla samarbete inom avdelningen. Utveckla samarbetet. mini workshop! i butikens ledningsgrupp. Grid International AB. Grid International AB

Utveckla samarbete inom avdelningen. Utveckla samarbetet. mini workshop! i butikens ledningsgrupp. Grid International AB. Grid International AB Utveckla samarbete inom avdelningen Utveckla samarbetet mini workshop! i butikens ledningsgrupp Grid International AB Grid International AB Om ledarskap och samarbete som ger både ökat resultat och bättre

Läs mer

Användningscentrering i agila utvecklingsprojekt. johanna.sarna@valtech.com Valtech

Användningscentrering i agila utvecklingsprojekt. johanna.sarna@valtech.com Valtech Användningscentrering i agila utvecklingsprojekt johanna.sarna@valtech.com Valtech Vem är jag? Johanna Särnå Jobbar på Valtech sedan 3 år tillbaka Jobbar där med användbarhet och projektledning Certifierad

Läs mer

UTBILDNINGSPLAN Magisterprogram i pedagogiskt arbete 60 högskolepoäng. Master Program in Educational Work 60 credits 1

UTBILDNINGSPLAN Magisterprogram i pedagogiskt arbete 60 högskolepoäng. Master Program in Educational Work 60 credits 1 UTBILDNINGSPLAN Magisterprogram i pedagogiskt arbete 60 högskolepoäng Master Program in Educational Work 60 credits 1 Fastställd i Områdesnämnden 2015-XX-XX Gäller fr.o.m. HT 2015 1. PROGRAMMETS MÅL 1.1.

Läs mer

TDP023 Projekt: Agil systemutveckling

TDP023 Projekt: Agil systemutveckling TDP023 Projekt: Agil systemutveckling Johan Åberg johan.aberg@liu.se Tre moment Projekt 8hp Marknadsföring av produkt 2hp Kopplat till projektarbetet Individuell rapport 2hp Kopplat till projektarbetet

Läs mer

Förändrade förväntningar

Förändrade förväntningar Förändrade förväntningar Deloitte Ca 200 000 medarbetare 150 länder 700 kontor Omsättning cirka 31,3 Mdr USD Spetskompetens av världsklass och djup lokal expertis för att hjälpa klienter med de insikter

Läs mer

Kursöversikt Certifierad Mjukvarutestare

Kursöversikt Certifierad Mjukvarutestare Kursöversikt Certifierad Mjukvarutestare Kurs Poäng (5 yh poäng/vecka) Examensarbete 20 Grunderna inom test 20 Kommunikation i arbetslivet 15 Lärande i arbete 1 60 Lärande i arbete 2 60 Projektarbete 15

Läs mer

2010-12-27 SCRUM. Vattenfallsmodellen. Analys. Design. Kod. Test. Rational Unified Process Agile. Kallas också linjär sekventiell modell.

2010-12-27 SCRUM. Vattenfallsmodellen. Analys. Design. Kod. Test. Rational Unified Process Agile. Kallas också linjär sekventiell modell. Vattenfallsmodellen SCRUM Analys Kallas också linjär sekventiell modell Introduktion Design Kod Test Rational Unified Process Agile DSDM Adaptive Software Development Crystal Feature-Driven Development

Läs mer

Metoder för Interaktionsdesign

Metoder för Interaktionsdesign Metoder för Interaktionsdesign Föreläsning 4 Projektmetodik och Scrum Kapitel 9-12 + 14, Scrumbok Det högra spåret Vi lämnar nu det vänstra spåret de mjukare delarna och går in på det högra spåret som

Läs mer

KOMMUNIKATIVT LEDARSKAP

KOMMUNIKATIVT LEDARSKAP KOMMUNIKATIVT LEDARSKAP 7, 100, 85, 7 EN ANALYS AV INTERVJUER MED CHEFER OCH MEDARBETARE I FEM FÖRETAG NORRMEJERIER SAAB SANDVIK SPENDRUPS VOLVO Mittuniversitetet Avdelningen för medieoch kommunikationsvetenskap

Läs mer

KOMMUNIKATIVT LEDARSKAP

KOMMUNIKATIVT LEDARSKAP KOMMUNIKATIVT LEDARSKAP 7, 100, 85, 7 EN ANALYS AV INTERVJUER MED CHEFER OCH MEDARBETARE I FEM FÖRETAG NORRMEJERIER SAAB SANDVIK SPENDRUPS VOLVO Mittuniversitetet Avdelningen för medieoch kommunikationsvetenskap

Läs mer

Kanban. Marcus Hammarberg. torsdag den 15 september 2011 (v.)

Kanban. Marcus Hammarberg. torsdag den 15 september 2011 (v.) Kanban Marcus Hammarberg Kanban? Vad sjutton är Kanban för något? Jag brukar beställa yakiniku... http://blog.huddle.net/wp-content/uploads/2009/08/team-building-exercises-improving-teamwork.jpg Kanban

Läs mer

FÖRBERED UNDERLAG FÖR BEDÖMNING SÅ HÄR

FÖRBERED UNDERLAG FÖR BEDÖMNING SÅ HÄR FÖRBERED UNDERLAG FÖR BEDÖMNING SÅ HÄR Kontrollera vilka kurser du vill söka under utbytet. Fyll i Basis for nomination for exchange studies i samråd med din lärare. För att läraren ska kunna göra en korrekt

Läs mer

- A Scrum Planning Tool Case Study to Evaluate the The Rich AJAX Platform

- A Scrum Planning Tool Case Study to Evaluate the The Rich AJAX Platform Datavetenskap Opponent(er): Jhonny Carvajal Johan Bjärneryd Respondent(er): Fredrik Häggbom Erik Olsson Haglund Scrumptious - A Scrum Planning Tool Case Study to Evaluate the The Rich AJAX Platform Oppositionsrapport,

Läs mer

Scaled Agile Framework

Scaled Agile Framework Scaled Agile Framework Grunder för självorganisation Vad är det och är det bra? @svante_lidman svante.lidman@coreboost.se 1 Vem är Svante? Senaste 6-7 åren Konsultat inom Large-Scale Lean/Agile De +20

Läs mer

Studenter utan gränser Strengthening Students International Education

Studenter utan gränser Strengthening Students International Education Studenter utan gränser Strengthening Students International Education Catherine Gillo Nilsson Göteborgs universitet Del I INLEDNING Syfte och Fokus Workshopens Lärandemål What to expect Efter workshopen

Läs mer

Rapport elbilar Framtidens fordon

Rapport elbilar Framtidens fordon Teknikprogrammet Klass TE14. Rapport elbilar Framtidens fordon Namn: Joel Evertsson Datum: 2015-03-09 Abstract This report is about electric car. We have worked with future vehicles and with this report

Läs mer

Testning som beslutsstöd

Testning som beslutsstöd Testning som beslutsstöd Vilken typ av information kan testning ge? Vilken typ av testning kan ge rätt information i rätt tid? Hur kan testning hjälpa din organisation med beslutsstöd? Hur kan produktiviteten

Läs mer

SCRUM och agil utveckling

SCRUM och agil utveckling SCRUM och agil utveckling Johan Åberg johan.aberg@liu.se Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Läs mer

Förändringsledning. Stöd & behandling. 2015-09-15 Anette Cederberg

Förändringsledning. Stöd & behandling. 2015-09-15 Anette Cederberg Förändringsledning Stöd & behandling Förändring It is not the strongest of the species that survives, nor the most intelligent, but the ones most responsive to change Charles Darwin, The Origin of Species,

Läs mer

Agenda. Plats och magkänsla. Presentation. - en pedagogisk fråga?

Agenda. Plats och magkänsla. Presentation. - en pedagogisk fråga? Plats och magkänsla - en pedagogisk fråga? Göran Lindahl Chalmers tekniska högskola 2011-09-28 Agenda Introduktion Helhet Användbarhet och effekter Cost and benefit Realitet, abstrakt, realitet Så här

Läs mer

Enterprise App Store. Sammi Khayer. Igor Stevstedt. Konsultchef mobila lösningar. Teknisk Lead mobila lösningar

Enterprise App Store. Sammi Khayer. Igor Stevstedt. Konsultchef mobila lösningar. Teknisk Lead mobila lösningar Enterprise App Store KC TL Sammi Khayer Konsultchef mobila lösningar Familjen håller mig jordnära. Arbetar med ledarskap, mobila strategier och kreativitet. Fotbollen ger energi och fokus. Apple fanboy

Läs mer

Implementering - teori och tillämpning inom hälso- och sjukvård

Implementering - teori och tillämpning inom hälso- och sjukvård Implementering - teori och tillämpning inom hälso- och sjukvård Siw Carlfjord Leg sjukgymnast, Med dr IMH, Linköpings universitet There are not two sciences There is only one science and the application

Läs mer

Titel: Undertitel: Författarens namn och e-postadress. Framsidans utseende kan variera mellan olika institutioner

Titel: Undertitel: Författarens namn och e-postadress. Framsidans utseende kan variera mellan olika institutioner Linköping Universitet, Campus Norrköping Inst/ Kurs Termin/år Titel: Undertitel: Författarens namn och e-postadress Framsidans utseende kan variera mellan olika institutioner Handledares namn Sammanfattning

Läs mer

Här kan du checka in. Check in here with a good conscience

Här kan du checka in. Check in here with a good conscience Här kan du checka in med rent samvete Check in here with a good conscience MÅNGA FRÅGAR SIG hur man kan göra en miljöinsats. Det är egentligen väldigt enkelt. Du som har checkat in på det här hotellet

Läs mer

Särskild avgift enligt lagen (1991:980) om handel med finansiella instrument

Särskild avgift enligt lagen (1991:980) om handel med finansiella instrument 2014-05-20 BESLUT Ilmarinen Mutual Pension Insurance Company FI Dnr 14-1343 Porkkalankatu 1 FI-000 18 Helsinki Finland Finansinspektionen Box 7821 SE-103 97 Stockholm [Brunnsgatan 3] Tel +46 8 787 80 00

Läs mer

William J. Clinton Foundation Insamlingsstiftelse REDOGÖRELSE FÖR EFTERLEVNAD STATEMENT OF COMPLIANCE

William J. Clinton Foundation Insamlingsstiftelse REDOGÖRELSE FÖR EFTERLEVNAD STATEMENT OF COMPLIANCE N.B. The English text is an in-house translation. William J. Clinton Foundation Insamlingsstiftelse (organisationsnummer 802426-5756) (Registration Number 802426-5756) lämnar härmed följande hereby submits

Läs mer

Metodologier Forskningsdesign

Metodologier Forskningsdesign Metodologier Forskningsdesign 1 Vetenskapsideal Paradigm Ansats Forskningsperspek6v Metodologi Metodik, även metod används Creswell Worldviews Postposi'vist Construc'vist Transforma've Pragma'c Research

Läs mer

EFFEKTIVA PROJEKT MED WEBBASERAD PROJEKTLEDNING

EFFEKTIVA PROJEKT MED WEBBASERAD PROJEKTLEDNING EFFEKTIVA PROJEKT MED WEBBASERAD PROJEKTLEDNING Skapa initiativ för din projektgrupp för att lyckas Webinar 2012-03-08 VAD ÄR PROJECTPLACE? SAMARBETSTJÄNST ONLINE PROJECTPLACE I SIFFROR Grundades 1998

Läs mer

ADDING VALUE CONSULTING AB PRINCE2 PRACTITIONER KURS

ADDING VALUE CONSULTING AB PRINCE2 PRACTITIONER KURS ADDING VALUE CONSULTING AB PRINCE2 PRACTITIONER KURS Innehållsförteckning 1. PRINCE2... 3 1.1. PRINCE2 Practitioner... 4 1. PRINCE2 PRINCE2 (Projects IN a Controlled Environment) är en strukturerad metod

Läs mer

Identifiera kundbehov KPP306, Produkt och processutveckling, 15hp

Identifiera kundbehov KPP306, Produkt och processutveckling, 15hp 2008 02 21 Identifiera kundbehov KPP306, Produkt och processutveckling, 15hp PM, Seminarie SEM1, 3hp Kapitel 4 Seminariegrupp 7 Författare: Robin Hellsing Robin Jarl Handledare: Rolf Lövgren Sammanfattning

Läs mer

Identifiera kundbehov En sammanfattning och analys av kapitel 4 i boken Product Design and Development

Identifiera kundbehov En sammanfattning och analys av kapitel 4 i boken Product Design and Development Identifiera kundbehov En sammanfattning och analys av kapitel 4 i boken Product Design and Development Grupp 6 Ali Abid Kjell Nilsson Patrick Larsson Mälardalens högskola KN3060, Produktutveckling med

Läs mer

Undervisning och lärande med case: en guide för läraren

Undervisning och lärande med case: en guide för läraren Undervisning och lärande med case: en guide för läraren Version 1.0, oktober 2013 Inledning Denna lärarhandledning syftar till att ge en kortfattad introduktion till casemetodiken och de olika stegen i

Läs mer

Vi omsätter kunskap till hållbar lönsamhet

Vi omsätter kunskap till hållbar lönsamhet Vi omsätter kunskap till hållbar lönsamhet Silf Competence.ppt 1 K229 Supply Chain och Lean Six Sigma+LEAN Silf Competence.ppt 2 K229 Vad är Supply Chain? Innehåll Vad är Lean, Six Sigma och Six Sigma+Lean

Läs mer

ALM Live: Scrum + VSTS

ALM Live: Scrum + VSTS ALM Live: Scrum + VSTS Explained and distilled for Everyone! Micael Herkommer micael.herkommer@inexor.se Introduktion Micael Herkommer Developer Coach & Solutions Architect INEXOR EPiServer Professional

Läs mer

Slutrapport. Innovativt utbildnings- och forskningsmaterial användning av 3D visualisering och animering för att bemöta pedagogiska utmaningar

Slutrapport. Innovativt utbildnings- och forskningsmaterial användning av 3D visualisering och animering för att bemöta pedagogiska utmaningar Innehåll Slutrapport Innovativt utbildnings- och forskningsmaterial användning av 3D visualisering och animering för att bemöta pedagogiska utmaningar Emin Halilovic, projektledare 1 Basfakta... 3 1.1

Läs mer

CUSTOMER VALUE PROPOSITION ð

CUSTOMER VALUE PROPOSITION ð CUSTOMER VALUE PROPOSITION ð IN BUSINESS MARKETS JAMES C. ANDERSSON, JAMES A. NARUS, & WOUTER VAN ROSSUMIN PERNILLA KLIPPBERG, REBECCA HELANDER, ELINA ANDERSSON, JASMINE EL-NAWAJHAH Inledning Företag påstår

Läs mer

Agila Avtal. avtalsformer som kan fungera. Carina Meurlinger carina.meurlinger@agero.se

Agila Avtal. avtalsformer som kan fungera. Carina Meurlinger carina.meurlinger@agero.se Agila Avtal Hur man säljer in agila projekt olika avtalsformer som kan fungera Carina Meurlinger carina.meurlinger@agero.se Min syn på saken och kundens Detta är vad vi alla önskar Lite om mig själv Carina

Läs mer

Riktlinjer Projektmodell fo r Kungä lvs kommun

Riktlinjer Projektmodell fo r Kungä lvs kommun Riktlinjer Projektmodell fo r Kungä lvs kommun Riktlinjerna är antagna av förvaltningsledningen 2013-01-28 och gäller tillsvidare. (Dnr KS2012/1542) Ansvarig för dokumentet är chefen för enheten Utveckling,

Läs mer

Här kan du sova. Sleep here with a good conscience

Här kan du sova. Sleep here with a good conscience Här kan du sova med rent samvete Sleep here with a good conscience MÅNGA FRÅGAR SIG hur man kan göra en miljöinsats. Det är egentligen väldigt enkelt. Du som har checkat in på det här hotellet har gjort

Läs mer

Riktlinjer för bedömning av examensarbeten

Riktlinjer för bedömning av examensarbeten Fastställda av Styrelsen för utbildning 2010-09-10 Dnr: 4603/10-300 Senast reviderade 2012-08-17 Riktlinjer för bedömning av Sedan 1 juli 2007 ska enligt högskoleförordningen samtliga yrkesutbildningar

Läs mer

Senaste trenderna inom redovisning, rapportering och bolagsstyrning Lars-Olle Larsson, Swedfund International AB

Senaste trenderna inom redovisning, rapportering och bolagsstyrning Lars-Olle Larsson, Swedfund International AB 1 Senaste trenderna inom redovisning, rapportering och bolagsstyrning Lars-Olle Larsson, Swedfund International AB 2 PwC undersökning av börsföretag & statligt ägda företag Årlig undersökning av års- &

Läs mer

Webbsystems inverkan på innehåll och användbarhet på webbplatser - oppositionsrapport

Webbsystems inverkan på innehåll och användbarhet på webbplatser - oppositionsrapport Webbsystems inverkan på innehåll och användbarhet på webbplatser - oppositionsrapport Respondenter: Emma Henriksson och Ola Ekelund Opponenter: Eva Pettersson och Johan Westerdahl Sammanfattande omdöme

Läs mer

Projecticon. Grafisk Standard. Projecticon AB Box 2131 103 14 Stockholm, Sweden. www.projecticon.se

Projecticon. Grafisk Standard. Projecticon AB Box 2131 103 14 Stockholm, Sweden. www.projecticon.se Projecticon Grafisk Standard Logotype Logotype Typsnitt: Palatino Färg: RGB, R46, G98, B174 C87M65 Typsnitt Dokument Rubriker Brödtext Fotnoter Verdana Garmond Arial Webb Rubriker Brödtext Länkar Verdana

Läs mer

Scrum Scrum. en beskrivning. a description. V 2012.12.13 2012 Scrum Alliance,Inc 1

Scrum Scrum. en beskrivning. a description. V 2012.12.13 2012 Scrum Alliance,Inc 1 " Scrum Scrum en beskrivning a description 1" 1 Scrums principer Värderingar från Agile Manifesto Scrum är mest känt av de agila arbetssätten. Agile Manifesto utgör en gemensam bas för att arbeta agilt

Läs mer

Unit testing methodology

Unit testing methodology Department of Computer Science Per Hurtig Stefan Lindberg & Fredrik Strandberg Unit testing methodology Opposition Report, C/D-level 2005:xx 1 Övergripande utvärdering Helhetsintrycket av uppsatsen är

Läs mer

Människa- datorinteraktion, MDI, vt 2012, Anvisningar för projekt- /grupparbete

Människa- datorinteraktion, MDI, vt 2012, Anvisningar för projekt- /grupparbete Människa- datorinteraktion, MDI, vt 2012 Anvisningar för projekt- /grupparbete Kursens projektuppgift består av att genomföra ett projektarbete i grupper om 3-4 personer. Uppgiften ska sedan presenteras

Läs mer

AGIL KRAVHANTERING. Hitta behoven bakom kraven!! Thomas Nilsson! Agile Coach & Mentor! CTO, Responsive

AGIL KRAVHANTERING. Hitta behoven bakom kraven!! Thomas Nilsson! Agile Coach & Mentor! CTO, Responsive AGIL KRAVHANTERING Hitta behoven bakom kraven!!! Thomas Nilsson! Agile Coach & Mentor! CTO, Responsive KRAVSTÄLL EN PRODUKT! Skriv ner tre krav som ni ställer på produkten INNOVATIONSDRIVNA PRODUKTER...

Läs mer

Exportmentorserbjudandet!

Exportmentorserbjudandet! Exportmentor - din personliga Mentor i utlandet Handelskamrarnas erbjudande till små och medelstora företag som vill utöka sin export Exportmentorserbjudandet! Du som företagare som redan har erfarenhet

Läs mer

PROJEKTLEDNING inom produktutveckling. Individuell inlämningsuppgift KPP039 Produktutvekling 3 Boris Mrden 2010-01-10

PROJEKTLEDNING inom produktutveckling. Individuell inlämningsuppgift KPP039 Produktutvekling 3 Boris Mrden 2010-01-10 PROJEKTLEDNING inom produktutveckling Individuell inlämningsuppgift KPP039 Produktutvekling 3 Boris Mrden 2010-01-10 Innehållsförteckning Inledning... 3 Projektarbete... 4 Projektledning & Ledarskap...

Läs mer

Användbarhet i sitt sammanhang

Användbarhet i sitt sammanhang Användbarhet i sitt sammanhang Världsanvändbarhetsdagen 2009-11-12 Anders Hedberg, Guide Konsult Stockholm Innehåll En helikoptertur över ett projekts olika faser med belysning på användbarhet i förhållande

Läs mer

Mathematical Cryptology (6hp)

Mathematical Cryptology (6hp) Time to sign up for the continuation course Mathematical Cryptology (6hp) 12 lectures (2 hours) + 2 small projects Exercises are done on your own and discussed in class (6*2 hours). Contents: Elliptic

Läs mer

Masterprogram i socialt arbete med inriktning mot verksamhetsanalys och utveckling i civilsamhället, 120 hp UTBILDNINGSPLAN

Masterprogram i socialt arbete med inriktning mot verksamhetsanalys och utveckling i civilsamhället, 120 hp UTBILDNINGSPLAN 1 (7) Institutionen för socialvetenskap Masterprogram i socialt arbete med inriktning mot verksamhetsanalys och utveckling i civilsamhället, 120 hp UTBILDNINGSPLAN Master Programme in Social Work Research

Läs mer

STORSEMINARIET 3. Amplitud. frekvens. frekvens uppgift 9.4 (cylindriskt rör)

STORSEMINARIET 3. Amplitud. frekvens. frekvens uppgift 9.4 (cylindriskt rör) STORSEMINARIET 1 uppgift SS1.1 A 320 g block oscillates with an amplitude of 15 cm at the end of a spring, k =6Nm -1.Attimet = 0, the displacement x = 7.5 cm and the velocity is positive, v > 0. Write

Läs mer

Graärgning och kromatiska formler

Graärgning och kromatiska formler Graärgning och kromatiska formler Henrik Bäärnhielm, d98-hba 2 mars 2000 Sammanfattning I denna uppsats beskrivs, för en ickematematiker, färgning av grafer samt kromatiska formler för grafer. Det hela

Läs mer

SAMMANFATTNING AV SUMMARY OF

SAMMANFATTNING AV SUMMARY OF Detta dokument är en enkel sammanfattning i syfte att ge en första orientering av investeringsvillkoren. Fullständiga villkor erhålles genom att registera sin e- postadress på ansökningssidan för FastForward

Läs mer

SAPSA 12 NOVEMBER 2014

SAPSA 12 NOVEMBER 2014 SAPSA 12 NOVEMBER 2014 Change Management - Förändringsledning Arla Foods implementering av SAP inom Supply Chain Sverige fokus på förändringsledning Summering och frågor Presenteras av: Lena Selander,

Läs mer

De tre första månaderna på ett nytt jobb

De tre första månaderna på ett nytt jobb De tre första månaderna på ett nytt jobb När du börjar på ett nytt jobb är den första tiden viktig. Vad du gör och vem du är under dina första tre månader lägger grunden till om fortsättningen ska bli

Läs mer

EXAMENSARBETE CIVILEKONOM

EXAMENSARBETE CIVILEKONOM EXAMENSARBETE CIVILEKONOM Sven-Olof Collin E-mail: masterdissertation@yahoo.se Hemsida: http://www.svencollin.se/method.htm Kris: sms till 0708 204 777 VARFÖR SKRIVA EN UPPSATS? För den formella utbildningen:

Läs mer

Text och språkanalys. Klassisk retorik och massmedieretorik. två ingångar till textanalys

Text och språkanalys. Klassisk retorik och massmedieretorik. två ingångar till textanalys Text och språkanalys Klassisk retorik och massmedieretorik två ingångar till textanalys Kurs: Medie- och kommunikationsvetenskap A, nät VT12 Kursledare: Jonas Ström och Hans Wiechel Institutionen för kultur-

Läs mer

Perspektiv på kunskap

Perspektiv på kunskap Perspektiv på kunskap Alt. 1. Kunskap är något objektivt, som kan fastställas oberoende av den som söker. Alt. 2. Kunskap är relativ och subjektiv. Vad som betraktas som kunskap är beroende av sammanhanget

Läs mer

HÖSTTERMINEN. Scrum STF INGENJÖRSUTBILDNING AB. Vi vidareutbildar ingenjörer och tekniker. Din partner för livslångt lärande

HÖSTTERMINEN. Scrum STF INGENJÖRSUTBILDNING AB. Vi vidareutbildar ingenjörer och tekniker. Din partner för livslångt lärande STF INGENJÖRSUTBILDNING Vi vidareutbildar ingenjörer och tekniker Scrum STF KOMPETENSINFO NR 63/2011 HÖSTTERMINEN STF INGENJÖRSUTBILDNING AB Din partner för livslångt lärande WWW.STF.SE Scrum i praktiken

Läs mer

QC i en organisation SAST 2008-09-16

QC i en organisation SAST 2008-09-16 QC i en organisation SAST 2008-09-16 1 Agenda Hur är vi organiserade inom test på SEB? Hur är QC uppsatt på SEB? Hur arbetar vi med QC i en stor organisation? Uppfyllde QC våra förväntningar och hur har

Läs mer

PDP som redskap för karriärutveckling i utbildning. Ola Tostrup

PDP som redskap för karriärutveckling i utbildning. Ola Tostrup PDP som redskap för karriärutveckling i utbildning Ola Tostrup - 16, 4, 47, 3 Dagens föreställning Vad innebär PDP och varför PDP Hur vi designat det inom utbildningen Kompetensbegreppet och vilka kompetenser

Läs mer

KONCEPTUALISERING. Copyright Dansk & Partners

KONCEPTUALISERING. Copyright Dansk & Partners KONCEPTUALISERING Concept begins to 80 % in content, 20 % in process and 20 % in presentation. The conceptualization work always starts in process because if you cannot communicate what you want to say

Läs mer

Kanban är inte din process. (låt mig berätta varför) #DevLin2012 15 Mars 2012

Kanban är inte din process. (låt mig berätta varför) #DevLin2012 15 Mars 2012 Kanban är inte din process (låt mig berätta varför) #DevLin2012 15 Mars 2012 Torbjörn Tobbe Gyllebring @drunkcod tobbe@cint.com Är du eller känner du en Kanban hipster? Förut körde vi X nu kör vi Kanban

Läs mer

Statligt stöd för miljö- och sociala frågor till små och medelstora företag - en jämförande studie mellan Sverige och Storbritannien

Statligt stöd för miljö- och sociala frågor till små och medelstora företag - en jämförande studie mellan Sverige och Storbritannien I ett examensarbete från Sveriges Lantbruksuniversitet (SLU) av Katarina Buhr och Anna Hermansson i samverkan med Nutek, jämförs det statliga stödet till små och medelstora företags arbete med miljöoch

Läs mer

Design och krav. Design Definition. enkelt Det ska vara möjligt att. Henrik Artman

Design och krav. Design Definition. enkelt Det ska vara möjligt att. Henrik Artman Design och krav Henrik Artman >>Ett av skälen till att projektet inte höll tidplan och budget var [beställarens] höga ambitionsnivå. Dessutom skulle man gjort en stordel av arbetet självt, men en del av

Läs mer

Insikt. kräver kunskap, erfarenhet och förståelse

Insikt. kräver kunskap, erfarenhet och förståelse Insikt kräver kunskap, erfarenhet och förståelse Målet är utveckling... håller inte måttet Företag med teknologibaserad utveckling står idag inför många utmaningar. Den viktigaste är utan tvekan förmågan

Läs mer

Det är skillnaden som gör skillnaden

Det är skillnaden som gör skillnaden GÖTEBORGS UNIVERSITET INSTITUTIONEN FÖR SOCIALT ARBETE Det är skillnaden som gör skillnaden En kvalitativ studie om motivationen bakom det frivilliga arbetet på BRIS SQ1562, Vetenskapligt arbete i socialt

Läs mer

Måldriven, informationscentrerad webbdesign

Måldriven, informationscentrerad webbdesign Måldriven, informationscentrerad webbdesign Linus Forsell Digitala Distributionsformer vid Högskolan Väst, Trollhättan, Sverige linus.forsell@student.hv.se 1 Abstrakt I den här essän kommer måldriven och

Läs mer

Amir Rostami 2012-09-16 1

Amir Rostami 2012-09-16 1 Amir Rostami 2012-09-16 1 Översikt Begreppsförvirring Den svenska gängutvecklingen Stockholm Gang Intervention and Prevention Project Sveriges största polisiära EU projekt Alternativt brottsbekämpning

Läs mer

Sammanställning av kursvärdering

Sammanställning av kursvärdering Dnr HS 214/42 Sammanställning av kursvärdering (blanketten används inte för lärarutbildningskurser) Fakulteten för humaniora och samhällsvetenskap Sammanställning av vårterminens kurser ska vara underskriven,

Läs mer

Kvalitetsstandarder inom statistikproduktionen. 2011-10-19 Lilli Japec, Dr Utvecklingschef SCB lilli.japec@scb.se

Kvalitetsstandarder inom statistikproduktionen. 2011-10-19 Lilli Japec, Dr Utvecklingschef SCB lilli.japec@scb.se Kvalitetsstandarder inom statistikproduktionen 2011-10-19 Lilli Japec, Dr Utvecklingschef SCB lilli.japec@scb.se 1 Inledning Vad är kvalitet? Vilka ramverk finns? Några exempel från SCB:s kvalitetsarbete

Läs mer

Operatörer och användargränssnitt vid processtyrning

Operatörer och användargränssnitt vid processtyrning Operatörer och användargränssnitt vid processtyrning Normativa och beskrivande analyser Uppsala universitet @ 2003 Anders Jansson Sammanfattning kap. 1 Sociotekniska system Många olika grupper av användare

Läs mer

KVALITATIV DESIGN C A R I T A H Å K A N S S O N

KVALITATIV DESIGN C A R I T A H Å K A N S S O N KVALITATIV DESIGN C A R I T A H Å K A N S S O N KVALITATIV DESIGN Svarar på frågor som börjar med Hur? Vad? Syftet är att Identifiera Beskriva Karaktärisera Förstå EXEMPEL 1. Beskriva hälsofrämjande faktorer

Läs mer

LARS. Ett e-bokningssystem för skoldatorer.

LARS. Ett e-bokningssystem för skoldatorer. LARS Ett e-bokningssystem för skoldatorer. Därför behöver vi LARS Boka dator i förväg. Underlätta för studenter att hitta ledig dator. Rapportera datorer som är sönder. Samordna med schemaläggarnas system,

Läs mer

Utveckling av ett grafiskt användargränssnitt

Utveckling av ett grafiskt användargränssnitt Datavetenskap Opponenter: Daniel Melani och Therese Axelsson Respondenter: Christoffer Karlsson och Jonas Östlund Utveckling av ett grafiskt användargränssnitt Oppositionsrapport, C-nivå 2010-06-08 1 Sammanfattat

Läs mer

Platina och kvalité. Rasmus Staberg, Teknisk direktör, 2014-04-08

Platina och kvalité. Rasmus Staberg, Teknisk direktör, 2014-04-08 Formpipe Platina och kvalité Rasmus Staberg, Teknisk direktör, 2014-04-08 04 08 1 Formpipe Presentation Bakgrund Platina släpptes som första release år 2000. Fick pris för Best in show från Bill Gates

Läs mer

Förbud av offentligt uppköpserbjudande enligt lagen (1991:980) om handel med finansiella instrument

Förbud av offentligt uppköpserbjudande enligt lagen (1991:980) om handel med finansiella instrument BESLUT Gravity4 Inc. FI Dnr 15-7614 Att. Gurbaksh Chahal One Market Street Steuart Tower 27th Floor San Francisco CA 94105 415-795-7902 USA Finansinspektionen P.O. Box 7821 SE-103 97 Stockholm [Brunnsgatan

Läs mer

- den bredaste guiden om Mallorca på svenska! -

- den bredaste guiden om Mallorca på svenska! - - den bredaste guiden om Mallorca på svenska! - Driver du företag, har en affärsrörelse på Mallorca eller relaterad till Mallorca och vill nå ut till våra läsare? Då har du möjlighet att annonsera på Mallorcaguide.se

Läs mer

P-piller till 14-åringar?

P-piller till 14-åringar? P-piller till 14-åringar? Ämne: SO/Svenska Namn: Hanna Olsson Handledare: Anna Eriksson Klass: 9 9 Årtal: 2009 SAMMANFATTNING/ABSTRACT...3 INLEDNING...4 Bakgrund...4 Syfte & frågeställning,metod...4 AVHANDLING...5

Läs mer

Lars Lindmark 28 juni 2015. Designstuga. ett designlabb för hållbar utveckling. Beskrivning designstuga, sida 1

Lars Lindmark 28 juni 2015. Designstuga. ett designlabb för hållbar utveckling. Beskrivning designstuga, sida 1 Designstuga ett designlabb för hållbar utveckling Beskrivning designstuga, sida 1 Design Förmåga att lösa komplexa problem Designprocessen är en förmåga att samla och involvera aktörer för att tillsammans

Läs mer

FÖRETAGSEKONOMI. Ämnets syfte

FÖRETAGSEKONOMI. Ämnets syfte FÖRETAGSEKONOMI Ämnet företagsekonomi behandlar företagande i vid bemärkelse och belyser såväl ekonomiska som sociala och miljömässiga aspekter. I ämnet ingår marknadsföring, ledarskap och organisation,

Läs mer

Förändringsstrategi anpassad till just din organisations förutsättningar och förmåga

Förändringsstrategi anpassad till just din organisations förutsättningar och förmåga Förändringsstrategi anpassad till just din organisations förutsättningar och förmåga Att bedriva effektiv framgångsrik förändring har varit i fokus under lång tid. Förändringstrycket är idag högre än någonsin

Läs mer

Utbildningsplan Benämning Benämning på engelska Poäng Programkod Gäller från Fastställd Programansvar Beslut Utbildningens nivå Inriktningar

Utbildningsplan Benämning Benämning på engelska Poäng Programkod Gäller från Fastställd Programansvar Beslut Utbildningens nivå Inriktningar Utbildningsplan 1 (6) Benämning Magisterprogrammet i politik och krig Benämning på engelska Masters Programme in Politics and War Poäng: 60 hp Programkod: 2PK15 Gäller från: Höstterminen 2015 Fastställd:

Läs mer

Mål inom forskarutbildning hur gör vi?

Mål inom forskarutbildning hur gör vi? Mål inom forskarutbildning hur gör vi? Ingeborg van der Ploeg, Central studierektor / koordinator för utbildning på forskarnivå Karolinska Institutet, Stockholm Ingeborg.Van.Der.Ploeg@ki.se November 25,

Läs mer

Ingenjörsinriktad yrkesträning - Softhouse Crossmedia Avenue. Ronny Roos, 85-02-27 4098 d04rr

Ingenjörsinriktad yrkesträning - Softhouse Crossmedia Avenue. Ronny Roos, 85-02-27 4098 d04rr Ingenjörsinriktad yrkesträning - Softhouse Crossmedia Avenue Ronny Roos, 85-02-27 4098 d04rr Inlämnad: 16 januari 2008 1 Softhouse - Crossmedia Avenue Crossmedia Avenue, är ett svenskt företag som ingår

Läs mer

Stiftelsen Allmänna Barnhuset KARLSTADS UNIVERSITET

Stiftelsen Allmänna Barnhuset KARLSTADS UNIVERSITET Stiftelsen Allmänna Barnhuset KARLSTADS UNIVERSITET National Swedish parental studies using the same methodology have been performed in 1980, 2000, 2006 and 2011 (current study). In 1980 and 2000 the studies

Läs mer

Systemutveckling. Historiskt grundad introduktion

Systemutveckling. Historiskt grundad introduktion Systemutveckling Historiskt grundad introduktion Kvalitet som tema Dataområdet kännetecknas av ständig förändring - utveckling - expansion Varje "nyhet" en förbättring Anta att förbättringarna är, eller

Läs mer

Allmän studieplan för utbildning på forskarnivå i Signal- och systemteknik

Allmän studieplan för utbildning på forskarnivå i Signal- och systemteknik Dnr: L 2015/93 Fastställd av FUN: 2015-06-04 Versionsnr: 3 Allmän studieplan för utbildning på forskarnivå i Signal- och systemteknik Området och ämnet Området Examensområdet informationsteknologi definieras

Läs mer

Utbildningsplan för Kandidatprogram i modevetenskap. 1. Identifikation Programmets namn Programmets engelska namn Omfattning i högskolepoäng

Utbildningsplan för Kandidatprogram i modevetenskap. 1. Identifikation Programmets namn Programmets engelska namn Omfattning i högskolepoäng Utbildningsplan för Kandidatprogram i modevetenskap 1. Identifikation Programmets namn Programmets engelska namn Omfattning i Nivå Programkod Kod på inriktning Beslutsuppgifter Ändringsuppgifter Kandidatprogram

Läs mer

NYCKELAKTÖRSPROGRAMMET VAD HAR VI LÄRT OSS?

NYCKELAKTÖRSPROGRAMMET VAD HAR VI LÄRT OSS? NYCKELAKTÖRSPROGRAMMET VAD HAR VI LÄRT OSS? Jan Axelsson Samverkansdirektör Projektledare NAP/LiU LESSON NR 1 ÖRAT MOT MARKEN Du måste förstå kärnverksamhetens villkor! Sätt alltid kärnverksamheten i centrum

Läs mer