Slöseri inom mjukvaruutveckling

Transkript

1 Slöseri inom mjukvaruutveckling LUDWIG SMEDBERG OSCAR MO MG100X Examensarbete inom Industriell Produktion Stockholm, Sverige 2014

2 Projektledningsmetoders syn på slöseri inom mjukvaruutveckling Vad är slöseri inom mjukvaruutveckling och hur kan det minimeras? av Ludwig Smedberg Oscar Mo MG100X Examensarbete inom Industriell Produktion KTH Industriell teknik och management Industriell produktion SE STOCKHOLM

3 Sammanfattning Begreppet slöseri, av engelskans waste, är en term som i dagsläget saknar en klar och entydig definition inom mjukvaruutveckling. Denna rapport har skrivits vid Kungliga Teniska Högskolan i Stockholm och syftar att klargöra termen slöseri och vad den innebär men hjälp av olika projektledningsverktyg från IT-branchen. Det har framkommit att förtag sällan jobbar med en och endast en projektledningsmetod inom mjukvaruutveckling utan det blandas verktyg från olika metoder. Det är ofta brist på kunskap om valda verktyg och hur de ska användas samt vilka olika verktyg som kompletterar varandra eller ej är kompatibla med varandra. En ökad medvetenhet kring valda modeller och verktyg skulle leda till ökad effektivitet och minskat slöseri. Något som är gemensamt för samtliga agila projektledningsmetoder är en strävan efter att minska mängden slöseri på ett eller annat sätt och öka flödeseffektiviteten. Det är av stor vikt att lägga fokus på rätt slöseri för att åstadkomma största effektivisering då olika slöserier påverkar olika mycket. Det finns ingen uttalad efterfrågan från näringslivet på en definition av termen slöseri utan den engelska termen waste används, även på svenska. En potentiell definition för termen slöseri skulle kunna vara - något som är i vägen eller hindrar effektivt arbete med pågående projekt. Denna rapport behandlar endast slöseri ur en projektledares eller produktägares perspektiv inom mjukvaruutveckling, ej drift av IT-system. Abstract The concept of slöseri, from the English word waste, is a term that lacks a clear and unambiguous definition. This report has been written at the Royal Institute of Technology in Stockholm and aims to clarify the term slöseri and what it means by using various project management tools from the IT-industry. It has emerged that companies rarely work with one and only one project management method in software development, they rather mix tools from different methods. There is often a lack of knowledge about the selected tools and how to use them and which tools that complement each other and which are not compatible with each other. An increased awareness on selected models and tools would lead to increased efficiency and reduced slöseri. Something that is common to all agile project management methodologies is a desire to reduce the amount of waste in one way or another and increase flow efficiency. It is very important to focus on the right waste to achieve maximum efficiency du to that different types of waste affects to varying degrees. There is no explicit demand from the business community on a definition of slöseri because the term waste is used, even in Swedish. A potential definition for the term waste could be - something that s in the way or hinder effective work on current projects. This report deals only with waste from a project manager or product owner s perspective in software development, not the operation of IT-systems. 3

4 Förord Vi läser båda två på Kungliga Tekniska Högskolan i Stockholm på Maskintekniklinjen och har valt att läsa en Master inom Industriell Ekonomi. Således behövde vi göra vårt kandidatarbete inom industriell produktion för att kunna läsa vidare på vår önskade Master. Årets tema för kandidatarbetena på industriell produktion är Resurseffektiv produktion. Eftersom båda vi två är intresserade av IT-branchen, och i synnerhet projektledningen där, valde vi att skriva arbeteet om resurseffektiv produktion inom mjukvaruutveckling med fokus på projektledningsmodeller. För att kunna definiera resurseffektiv produktion ansåg vi att det behövdes några nyckeltermer och deras definitioner. Dessa var: resurser, resprodukter och avfall. När vi väl började titta närmare på artiklar och böcker inom området fann vi att definitionen för avfall inom mjukvaruutveckling var dåligt definierad eller helt saknade definition inom viss litteratur. Inom mjukvaruutveckling benämns detta begrepp mer vanligt som slöseri, således valde vi att fokusera vårt arbete helt kring denna term och dess definition. Vi skulle vilja tacka Tomas Österlind för all hjälp och vägledning som handledare samt Henrik Kniberg, Beatric Düring, Emil Larsson och Johan Möller för deras medverkan i denna rapport. /Ludwig och Oscar 4

5 Innehåll 1 Inledning Mål och syfte Att definiera Avgränsningar Övriga aspekter Nomenklatur Frågeställning Huvudfråga Underfråga Metod Val av metod Metodreflektion Intervjuteknik Validitet Reabilitet Generaliserbarhet Litteraturstudie Projektledningsmetoder Lean mjukvaruutveckling Projektledning Manifestet för Agil systemutveckling Scrum Testdriven Utveckling Kanban Extrem Programmering Vattenfallsmodellen Definitioner Teknisk skuld Littles lag - köteori Intervjuer Intervju med Betric During Intervju med Henrik Kniberg

6 5.3 Intervju med Emil Larsson och Johan Möller Diskussion Svenska och Engelska terminologier Blanding av metoder Slöseri / Avfall / Hinder / Impediments / Waste All mjukvara är slöseri Mimimera slöseri Effektivitet Köer - Resurseffektiv i motsats till Flödeseffektiv Slutsatser Vad är slöseri? Finns det ett behov av en definition för slöseri? Medvetenhet kring val av verktyg och modeller Fokus på rätt slöseri En potentiell definition av slöseri Figurer 1 Kanbantavla Vattenfallsmodellen En uppdelad resurs Kartläggning av värdeflöde Resurseffektiv i motsats till Flödeseffektiv

7 1 Inledning 1.1 Mål och syfte Målet med denna rapport är att kartlägga och undersöka olika projektledningsmetoder och verktyg inom IT-produktion med fokus på mjukvaruutveckling. Syftet är att skapa en förståelse för och reda ut begreppet slöseri inom mjukvaruutveckling ur ett projekledarperspektiv samt hur mjukvaruutvecklare arbetar med detta begrepp för att öka lönsamheten. 1.2 Att definiera För att kunna svara på huvudfrågan behöver vissa termer definieras. Huvudsakligen kommer fokus ligga på hur olika projektledningsmetoder är uppbyggda och strukturerade samt vilka olika verktyg som finns att använda inom de olika metoderna och hur dessa går att kombinera. Det kommer även undersökas om det är skillnad mellan hur teorierna kring olika metoder och verktyg ser ut och hur teorierna praktiseras i verkligheten. 1.3 Avgränsningar Denna studien behandlar slöseri inom mjukvaruutveckling och hur begreppet används. Studiens fokus ligger på projektledarens och produktägarens perspektiv och således behandlas inte hur enskilda utvecklare eller programmerare ser på termen slöseri. I detta arbete kommer endast slöseri inom IT-produktion ur ett utvecklingsperspektiv behandlas, det vill säga mjukvaruutveckling. Slöseri inom drift av system kommer inte behandlas. 1.4 Övriga aspekter Studien behandlar olika projektmodeller och dess olika verktyg. Dessa projektmodeller tar inte hänsyn till miljöaspekter och diskuterar inte etik eller moral. Projektmodeller behandlar heller inte jämställdhet men i alla grupper är det alltid viktigt att ha en mångfald av bland annat olika bakgrunder, typ av personer eller exempelvis kön. Detta ökar möjligheten till att lösa olika uppgifter på ett effektivt sätt men detta behandlas heller inte i denna studie då fokus är på projektmodellerna och dess verktyg. 1.5 Nomenklatur Inom mjukvaruutveckling är fackspråket engelska. I denna studie har därför problem uppstått när det sakanas svenska översättningar av termer som tas upp. Nedan följer förklaringar för de vanliga översättningar som studien hanterar. I de fall som en term bara används en gång står den svenska översättningen i kursiv stil följt av den engelska termen i parentes. I studien används kursiv text för att indikera en översättning. Begrepp med utvecklad förklaring Slöseri - Waste, en direktöversättning är avfall men en mer passande översättning är slöseri i detta sammanhang. 7

8 Agil - Agile, en mer korrekt översättning är följsam men praxis inom IT-branchen är att använda det engelska ordet agile, på svenska agil, och således används det begreppt i denna studie. Ordlista Agil coach Agile coach Agila gemenskapen Agile community Aktiv tid Touch time Användarupplevelser User stories Arbeta agilt Do agile Artifakter Artifacts Begränsat pågående arbete WIP (work in progress) Limit De sju slöserierna The seven wastes Defekter Defects Delvis utfört arbete Partially Done Work Enkelhet Simplicity Estimera tid Timeboxes Extra frunktioner Extra Features Extrem programering Extreme Programming Förseningar Delays Gemenskap Community Grupp/team Team Hinder Impediments Hållbart tempo Sustainable pace Händelser Event Idélista Backlog Kanban Kanban Kanbantavla Kanban board Kartläggning av värdeflöden Mapping the value stream Kodstandard Coding standards Kollektivt ägande av koden Collective code ownership Kontinuerlig intergration Contious integration Kontinuerlig testning Continous testing Koordineringsslöseri Coordination waste Kunden på samma plats On-site customer Lean Lean Lean mjukvaruutveckling Lean Software Development Lean tillverkning Lean manufacturing Manifestet för agil systemutveckling The Agile manifesto Miljöväxling Content switching Parprogrammering Pair Programming Processeffektivitet Process code efficiency Produktlista Product backlog Produktslöseri Product waste Produktägare Product owner Projektledning 2.0 Project Management 2.0 Refaktorisering Refactoring Samarbetsslöseri Collaboration waste Scrum Scrum Scrumledare Scrum master Skriv mindre kod Write less code Små utgåvor Small releases Ständigt arbeta med förbättring Continous improvment Taktiskt kunskap Tactical knowledge Team Team Teknisk skuld Technical debt Tekniskt slöseri Technical waste Testdriven Utveckling Test Driven Development Tiden till marknaden Time to market Tidsplanering Planning game Uppgiftsväxling Task Switching Vara agil Be agile Vattenfallsmodellen The waterfall model Väntan Waiting Återkopplingsslinga Feedback loop Återinlärning Relearning Överarbete Extra processing Överlämningar Handoffs Överproduktion Over production 8

9 2 Frågeställning 2.1 Huvudfråga Vad är slöseri inom agil IT-produktion, med fokus på mjukvaruutveckling, ur en projektledares eller produktägares perspektiv? 2.2 Underfråga Vad finns det för metoder och verktyg för att identifiera och minimera slöseri? 9

10 3 Metod 3.1 Val av metod Rapporten bygger på en undersökande studie samt intervjuer. Intervjuerna används främst för att stödja definitioner och för att koppla teori mot praktik. Största delen av rapporten består av en litteraturstudie som baseras på tidigare publicerade artiklar och böcker för att definiera teorier kring olika projektledningsmetoder och verktyg för att styra projekt. Således bygger denna rapport på tidigare forskning och sammanställer och reflekterar över redan vedertagen fakta inom projektstyrning i IT-branchen. För att få en mer verklighetsanknuten rapport görs en intervjustudie med personer inom IT-branchen för att bilda en uppfattning om vad slöseri anses vara i IT-branchen snarare än att bara basera vår rapport på forskningsresultat och teoretiska resonemang. Detta för att undersöka kopplingen mellan forskningens teoretiska begrepp, metoder och verktyg med industrins implementering. Intervjuerna ämnar öka förståelsen för olika metoder och verktyg samt ge en bild av hur teorierna används i praktiken och hurvida teorierna följs eller ej. 3.2 Metodreflektion Eftersom rapporten grundas på en litteraturstudie medföljer nackdelen att revolutionerande slutsatser är svåra att ta fram. Intervjustudiens ringa storlek bidrar till att slutsatserna från denna kommer att vara starkt påverkad av de intervjuades personliga åsikter och tankar Intervjuteknik Under de intervjuer som genomförts i denna studie har de intervjuade blivit informerade innan mötet om syftet med intervjun och i vilket sammanhang materialet skall användas. De tillfrågade har därmed gjort ett aktivt val att medverka i studien. Vid inledningen av varje intervju har även den eller de intervjuade blivit tillfrågade om intervjun kunde spelas in. Detta har skett enligt de moraliska kvaliteter en intervju bör innehålla med fokus på informerat samtycke, konsekvenser och konfidentialitet [6] Validitet I studien har validiteten behandlats genom att inte sammanfatta och dra slutsatser av insamlat material innan all datainsamling är avslutad. Detta är av stor vikt för att insamlingen av material inte skall påverka forskarens tolkning av data eller andra typer av förutsättningar [7] Reabilitet Begreppet reabilitet innebär hur tillförlitligt det insamlade materialet är. För att undvika oklarheter och missvisande resultat bör ledande frågor undvikas för att personliga åsikter inte ska spegla resultaten av intervjustudien. Detta är något som studien tagit hänsyn till genom att i stor utsträckning låta den intervjuade föra sina egna resonemang kring de ämnen som på förhand var förbestämda [7]. 10

11 3.2.4 Generaliserbarhet Generaliserbarhet handlar om att resultatet för studien skall kunna appliceras för andra som är i liknande positioner eller situationer som beskrivs i studien. I denna studien togs detta i beaktning genom att noggrant välja vilka olika roller som skulle intervjuas. Detta gav tre olika typer av intervjuer där representerades ett produktionsföretag, en konsult med bred erfarenhet och en som lärare inom agil projektledning. 11

12 4 Litteraturstudie För att klargöra ifall termen slöseri inom mjukvaruutveckling är definierad sammanställs de olika projektmetoderna som används idag och hur de olika metoderna ser ut. Fokus har därefter lagts på lean mjukvaruutveckling eftersom det är den enda metoden som aktivt jobbar med termen slöseri [9]. 4.1 Projektledningsmetoder Lean mjukvaruutveckling Lean mjukvaruutveckling växte fram inom IT-industrin under 90-talet. Det fanns ingen publicerad information till en början trotts att tankesättet applicerades och utformades inom mjukvaruutveckling. I och med publiceringen av Mary och Tom Poppendiecs bokserie Lean Software Development, anses de vara föregångare inom lean mjukvaruutveckling. I denna bokserie omvandlar Mary och Tom begreppen och tankesättet inom lean tillverkning från Toyota-modellen till IT-branschen. Merparten av de studerade artiklar som behandlar lean mjukvaruutveckling hänvisar till just Mary och Tom Poppendiecks arbete och böcker [8][10][11][12]. Skriv mindre kod Om man skulle leta efter en grundorsak till slöseri inom mjukvaruutveckling skulle komplexitet vara en god kandidat ("If we were to look for the root cause of waste in software development, a really good candidate would be complexity ) inleds kapitlet om slöseri i boken Implementing Lean Software Development: From Concept to Cash [2]. Med ökad komplexitet fås en större mängd kod som kan falera vilket leder till slutsatsen att det enklaste sättet att behålla mjukvaran effektiv är att hålla den enkel och okomplicerad [2]. De sju slöserierna De sju slöserierna kommer ursprungligen från Toyota och deras syn på lean tillverkning och hur de icke värdeskapande processerna kan minimeraras [5][20]. Dessa begrepp är alla utformade av och för en tillverkningsindustri men kan appliceras på mjukvaruutveckling med hjälp av omformulering. Dessa sju slöserier inom mjukvaruutveckling förklaras mer ingående i bokserien Lean Software Development av Mary och Tom Poppendieck och är sammanfattade i Tabell 1 [1][2]. 12

13 Tabell 1: De sju slöserierna[2] De sju slöserierna i De sju slöserierna i tillverkning mjukvaruutveckling Lager Delvis utfört arbete Överproduktion Extra funktioner Överarbete Återinlärning Transporter Överlämningar Rörelse Uppgiftsväxling Väntan Förseningar Omarbete Defekter Delvis utfört arbete Delvis utfört arbete har flera nackdelar. Det uppenbara är att produkten inte är implementerad hos kunden och således inte heller skapar värde men ett av de största problemen är osäkerheten i hurvida koden kommer att fungera eller ej. Ända fram tills dess att programvaran är integrerad med resterande omgivning finne en osäkerhet i vilka problem som kan komma att uppstå. Hurvida programvaran kommer lösa kundens problem innan den är aktiv i kundens produktion kan inte heller garanteras. Dessutom finns risken att arbetet inte kommer slutföras och således kasta bort investeringen, dels ifall kravspecifikationer ändras eller att programvaran blir föråldrad och andra lösningar behövs. Genom att minimera delvis utfört arbete minskar både risker och slöseri kan snabbare eliminera [1][2]. Extra funktioner Överproduktion är den värsta av de sju slöserierna inom tillverkning, och på samma sätt är extra funktioner värst även inom mjukvaruutveckling. Det tar mer tid att utveckla program med fler funktioner vilket leder till högre kostnader. Dessa funktioner är ej beställda och kommer därför inte att betalas av kunden och är därav slöseri för producenten. Det värsta med extra funktioner är dock inte utvecklingskostnaden utan att sedan underhålla programvaran och alla funktioner som inte används. Om det inte föreligger en aktuell ekonomisk anledning för en funktion skall den inte utvecklas [2]. Återinlärning Överarbete är omformulerat till återinlärning i lean mjukvaruutveckling. Detta beskriver hur glömska av bestämda funktioner och genomförda tester leder till att processen görs en gång till, därav återinlärning. Det beskrivs även hur organisationer, genom att misslyckas med att engagera personal, går miste om kunskap och således måste lära sig den kunskapen på nytt. Det är enligt Mary och Tom Poppendieck mycket värre att inte dra nytta av befintlig kunskap, än att glömma införskaffad kunskap [2]. Överlämningar Överlämningar beskriver det slöseri som uppstår under överlämningar mellan olika personer. Taktiskt kunskap kan inte överföras till andra personer genom en överlämning utan måste läras på nytt av den nya personen. Således går den taktiska kunskapen till spillo vid överlämningar, det vill säga att det blir slöseri. Dessutom tar det 13

14 tid att överlämna arbete till någon annan och för den nya personen att sätta sig in i arbetet [2]. Uppgiftsväxling Begreppet uppgiftsväxling handlar om hur ineffektivt det är för en programmerare att kontinuerligt växla mellan olika arbetsuppgifter. Varje gång en programmerare växlar mellan uppgifter måste denne på nytt sätta sig in i det logiska resonemanget och kodens struktur och det tar tid. Istället för att sätta sig in i arbetet en gång behöver detta göras varje gång växling mellan olika uppgifter sker och det blir slöseri. Det är frestande att påbörja flera projekt samtidigt men om det görs kommer arbetet att gå långsammare [2]. Förseningar Förseningar är resultatet av onödig väntan. Det finns olika anledningar till hur förseningar uppkommer, delvis på grund av väntan av olika anledningar. En programmera tar viktiga beslut var 15:e minut och finns då inte nödvändig information till hands kommer programmeraren att antingen gissa sig till en lösning eller vänta på rätt information, inget tillvägagångssätt är bra och båda skapar förseningar [2]. Defekter Begreppet defekter är kvar från de sju slöserierna i lean tillverkning. Det syftar på fel i koden och hur det skapar slöseri. Desto längre defekter ligger kvar i koden, desto mer slöseri kommer det att generera då det blir svårare att hitta och åtgärda felet. Ett stort fel som upptäcks direkt och kan åtgärdas på några minuter genererar lite slöseri medan ett litet fel som ligger obemärkt i ett program flera månader kan skapa ett stort slöseri, eftersom det kan vara svårt att hitta när programmeraren inte har koden färsk i minnet. Det är viktigt att testa tidigt och ofta för att eliminera alla defekter tidigt. Att skriva testprogramet innan koden kan leda till en låg förekomst av defekter i producerad kod eftersom programmeraren vet vad koden ska klara. Resonemanget byggs kring ett citat från Shigeo Shingo; inspektion för att förebygga defekter ( Inspection to prevent defects ) är ett krav för alla processer, men inspektion för att hitta defekter ( inspektion to find defects ) är slöseri [1][2][5]. Kartläggning av värdeflöden Kartläggning av värdeflöden går ut på att tidslinjen för ett projekt studeras. Starten är när kunden lägger en beställning, innebörden varierar beroende på vilken typ av projekt det är. Slutet på tidslinjen är då lösningen är implementerad och löser kundens problem. På tidslinjen markeras stora händelser inom projektet och sedan analyseras projektets omfattning av faktisk arbetstid, även kallat aktiv tid. Målet är att eliminera icke värdeskapande tid, vilket klassificeras som slöseri. Kartläggning av värdeflöden har visat sig vara ett mycket effektivt verktyg för att identifiera slöseri, huvudsakligen för att förseningar är en av de största slöserierna i ineffektiva projekt [2] Projektledning 2.0 Projektledning 2.0 är i grund och botten väldigt fokuserat på sociala aspekter. Deltagande och samarbete är huvudfokus och samt aktivt arbete för decentralisering och en platt organisation. Alla beslut tas med konsensus och alla i teamet ska ha kunskap om alla delar av 14

15 koden. Tack vare att alla är delaktiga inom alla delar av projektet hittas defekter snabbt vilket leder till en reducerad tid för identifiering av defekter. Således blir den kollektiva kunskapen den huvudsakliga källan till kunskap vilket är en av Projektledning 2.0 största styrkor [9] Manifestet för Agil systemutveckling Det som kallas manifestet för agil systemutveckling sammanställdes 2001 och har fyra värden och tolv principer. Alla andra agila projektmetoder är baserade på dessa principer och värden. Hela den agila metoden fokuserar på att flödeseffektivisera istället för att resurseffektivisera. Alla projekt bryts ner till mindre delprojekt med korta måltider och vid slutet av varje period leveras användbar kod, det vill säga värde för kunden [13]. De fyra agila värdena: 1. Individer och interaktion över processer och verktyg (Individuals and interactions over processes and tools). 2. Fungerande mjukvara över omfattande dokumentering (Working software over comprehensive documentation). 3. Kundsamarbete över kontraktsförhandlingar (Customer collaboration over contract negotiation). 4. Reagera på förändring över att följa en plan (Responding to change over following a plan) [13]. 15

16 De tolv agila principerna: 1. Vår högsta prioritet är att tillfredsställa kunden genom tidig och kontinuerlig leverans av värdefull programvara (Our highest priority is to satisfy the customer through early and continuous delivery of valuable software). 2. Välkomna förändrade krav, även sent i utvecklingen. Agila processer utnyttjar förändringar till kundens konkurrensfördel (Welcome changing requirements, even late in development. Agile processes harness change for the customer s competitive advantage). 3. Leverera fungerande programvara ofta, från ett par veckor till ett par månader, med en förkärlek för den kortare tidsskalan (Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale). 4. Affärsfolk och utvecklare arbetar tillsammans dagligen under hela projektet (Business people and developers work together daily throughout the project). 5. Bygga projekt runt motiverade individer, ge dem den miljö och det stöd de behöver och lita på dem för att få jobbet gjort (Build projects around motivated individuals, give them the environment and support they need and trust them to get the job done). 6. Den mest effektiva metoden för att överföra information med och inom ett utvecklingsteam är ansikte-mot-ansikte -konversation (The most efficient and effective method of conveying information with and within a development team is face-to-face conversation). 7. Fungerande programvara är det primära måttet på framsteg (Working software is the primary measure of progress). 8. Agila processer främjar en hållbar utveckling. Sponsorer, utvecklare och användare ska kunna hålla ett konstant arbetstempo på obestämd tid (Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely). 9. Kontinuerligt fokus på teknisk kvalitet och bra design förbättrar möjligheten till anpassing (Continuous attention to technical excellence and good design enhances agility). 10. Enkelhet - konsten att maximera mängden arbete som inte är gjort - är avgörande (Simplicity - the art of maximizing the amount of work not done - is essential). 11. De bästa arkitekturer, krav och designer växer fram ur självorganiserande team (The best architectures, requirements and designs emerge from self-organizing teams). 12. Med jämna mellanrum reflekterar teamet över hur man kan bli mer effektiv, för att sen anpassa och justerar sitt beteende därefter (At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly) [13]. 16

17 4.1.4 Scrum Scrum är deffinierat som "ett ramverk inom vilket människor kan hantera komplexa adaptiva problem, samtidigt som de produktivt och kreativt levererar produkter av högsta möjliga värde"(" a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value ") [17]. Scrum är ett processramverk som har använts för att hantera komplex produktutveckling sedan början av 1990-talet. Scrum är inte ett förfarande eller en teknik för att bygga produkter; snarare är det ett ramverk för användandet av olika processer och tekniker. Scrum ser till att beslut är faktabaserade och att beslut sker för omedelbar behov och består av tre roller [3][9][17]. De tre rollerna i Scrum: 1. Produktägare 2. Team 3. Scrumledare Produktägare: Produktägaren representerar alla intressenter till projektet, och den största uppgiften för produktägaren är att bevaka alla intressenters intressen. Det är även produktägaren som finansierar, står för kraven och godkänner projektet [17]. Team: Utvecklingsteamet kallas kort och gott för team, ibland grupp, och de är ansvariga för att utveckla och testa produkten [17]. Scrumledare: Scrumledaren är scrummetodens projektledare enkelt förklarat. Scrumledaren är ansvarig för scrumprocessen och för att anpassa processen till projektet och organisationen på bästa sätt. Denna jobbar även för att undanröja alla hinder för att få sitt team att jobba effektivt. [17] Testdriven Utveckling Testdriven utveckling är baserad på automatiserad testningen av koden. Stor vikt läggs på att inte skriva någon kod som ej kommer att testas, och testerna skrivs utefter det som ska levereras. Den kod som inte testas klassificeras innom lean mjukvaruutveckling som slöseri. Korta iterationer eftersträvas där koden kontinuerligt testas. Först efter godkänt test adderas ny kod, vartefter en ny testomgång körs [9] Kanban Kanban är japanska och betyder synliga kort. Toyota använder denna term för det visuella och fysiska signalsystem som knyter ihop hela deras lean produktionssystem. Kanban är även en lean metod för agil mjukvaruutveckling. Kärnan i kanban är att visualisera arbetsflödet genom att dela upp arbetet i små delar, skriva varje uppgift på ett kort och sätta 17

18 upp det på en tavla, en så kallad kanbantavla som kan ses i figur 1. Viktigt är även att ha ett begränsat pågående arbete, som i figur 1 visas i rött i varje arbetskolumn. Slutligen är det även en del av kärnan i kanban att mäta ledtiden för att slutföra ett kort/uppgift, även kallat cykeltid. I kanban arbetas det med att optimera processen för att göra ledtiden liten och förutsägba. Ytterliggare en av fördelarna med kanban är att det tydliggör flaskhalsar i realtid. Metoden hanterar dock inte någon term som påminner om slöseri [4]. Figur 1: Kanbantavla Figuren visar hur en kanbantavla kan se ut. Man kan tydligt följa arbetsflödet, se pågående projekt och tydligt se hur många projekt som får vara i varje kolumn genom begränsat pågående arbete som markeras i rött [4] Extrem Programmering Extrem Programmering, ofta kallat XP, är inte i ordets rätta bemärkelse en projektledningsmetod utan en metod för hur själva kodningen ska genomföras. XP består av tolv koncept som beskriver hur programmeringen bör genomföras. XP kombinerars ofta med andra metoder för att effektivisera både projektstyrningen och programmeringen [3]. 18

19 De tolv koncepten i XP: 1. Testdriven utveckling 2. Parprogrammering 3. Refaktorisering 4. Enkelhet 5. Tidsplanering 6. Små utgåvor 7. Kontinuerlig intergration 8. Kontinuerlig testning 9. Kollektivt ägande av koden 10. Hållbart tempo 11. Kodstandard 12. Kunden på samma plats [3] Vattenfallsmodellen Vattenfallsmetoden är en av de äldre projektledningsmetoderna. Den fokuserar på att vara resurseffektiv och arbeta metodiskt med en sak i taget. Dr. Winston Royce beskriver att oavsett storlek eller komplexitet finns det två viktiga steg för ett projekt. Första steget är analys och det andra är att utveckla. Givetvis kan de två stegen analysera och utveckla bli mer omfattande. De kan utvecklas i flera olika delsteg och deluppgifter men modellen syftar i huvudsak till att färdigställa det pågående arbetet innan nästa del i projektet påbörjas. [18]. 4.2 Definitioner Det finns en del termer som är generella inom mjukvaruutveckling, här förklaras några av dessa begreppen närmre Teknisk skuld Teknisk skuld är ett bregrepp som myntades i början av 1990-talet för att beskriva behovet av refaktorisering för icke tekniska intressenter. Den ursprungliga definitionen beskrivs som: inte helt rätt kod som vi skjuter upp att göra rätt (not quite right code which we postpone making it right) [14] Littles lag - köteori Littles lag, som beskriver köteori, förklarar att med ökade köer fås ett minskat flöde, dessutom är detta förhållande inte bara linjärt utan exponentiellt. Vid resurseffektivisering behövs en buffert för att se till att resursen aldrig får slut på arbetsuppgifter. Detta är dock kontraproduktivt enligt Littles lag. Lagen lyder: L = λw (1) 19

20 Där L är genomsnittligt antal enheter i kön, λ är genomsnittligt antal nya tillförda enheter per tidsenhet och W är genomsnittligt väntetid i systemet för varje enhet. Således fås mer väntetid med en ökande kö, och väntan är slöseri [15]. 20

21 5 Intervjuer Syftet med detta kapitel är att presentera insamlad empiri från intervjuer med personer inom IT-branchen. Syftet har även varit att få en spridning på de intervjuade personernas bakgrund för att täcka ett större område. Samtalens fokus har varit att resonera kring begreppet slöseri och i vilken utsträckning begreppet används. Varje intervju spelades in och stödord antecknades under intervjuerna. Under intervjuerna fanns även tillgång till papper där den intervjuade kunde rita modeller och förklara resonemang, vissa av de ritade bilderna bifogas i denna rapport, dock i digitaliserat och omritat format. I rapporten presenteras endast en sammanfattning av intervjuerna. 5.1 Intervju med Betric During Betric Düring är senior agil konsult på Softehouse Consulting AB, stationerad i Göteborg. Hon är väldigt engagerad i agil utbildning och undervisar bland annat på Agile academy i Stockholm. Denna intervju genomfördes på Sas Radisson Royal Viking på Vasagatan 1 i Stockholm den 2:a april Intervjuen varade i 65 min. Olika arbetsmetoder I samtalet med Betric Düring beskriver hon inledningsvis ett par olika projektledningsmodeller och hur implementering av dessa fungerar i näringslivet. Hon nämner att scrum är en modell som ger verktyg i former av tydliga roller, estimera tid och tydliga händelser. Det scrum verkligen bidragit med är framförallt rollen produktägare och produktlista. Extrem programmering är en annan metod som ger oss användarupplevelser och tydliga verktyg för effektivisering av sin programmering. I näringslivet är det enligt Beatric Düring alldeles för få som använder sig av XP vilket ofta är ett problem. XP använder sig inte av begreppet slöseri, däremot används begreppet enkelthet vilket går att koppla till slöseri enligt lean mjukvaruutveckling. Vidare beskriver Betric Düring även att kanban identifierar flaskhalsar i mjukvaruutveckling. Lean mjukvaruutveckling är en metod som hjälper till att identifiera slöseri i produktionen. Dock är inte lean mjukvaruutveckling en lika tydlig metod som exempelvis scrum då den saknar tydliga roller och händelser och används därför med fördel tillsammans med någon annan metod. En bra implementation av lean mjukvaruutveckling använder sig även av XP för att öka effektiviteten och minska slöseri. I näringslivet är det vanligt att metoder anpassas och blandas efter aktuellt behov, ofta används vektyg som organisationen gillar och förstår. Exempelvis är det vanligt att implementera en kanbantavla utan att även begränsa pågående arbete vilket är en av de centrala verktygen inom kanban. I detta exempel tappar kanbanmetoden sin styrka eftersom endast vissa verktyg, tagna ur sitt sammanhang, används. Betric Düring förklarar även att det är vanligt att metoder och verktyg blandas utan kunskap om vad som är essentiellt för varje modell och dess verktyg. I värsta fall leder det till att olika metoders mindre bra egenskaper blandas och förstärker varandra negativt och genererar slöseri. Resultatet blir en egenkomponerad metod som är sämre än ursprungsmetoderna. Detta medför också att företag påstår sig arbeta agilt, men Betric Düring lyfter fram skillnaden mellan att arbeta agilt och vara agil. 21

22 Begreppet slöseri Inom branchen är det naturligt att använda en engelsk terminologi. Det finns en gemenskap där erfarenheter och lärdomar delas kring de olika metoderna. Det är därför inom mjukvaruutveckling inte vanligt att använda svensk terminlologi och termen slöseri är inget undantag. Om en svensk översättning skulle användas är slöseri närmast en korrekt översättning men i dagligt tal används waste som ett begrepp då nästintill all kommunikation sker på engelska. Agila metoder är skapade för komplexa system och projekt. Vid enklare slutna system, likt ekosystemet där allt går att förutse, passar inte en agil metod för att lösa problem. Däremot vid komplexa öppna system och projekt som påverkas av sin omgivning och inte går att förutse, exempelvis börsen eller sociala medier, passar en agil metod för att lösa problem. Slöseri skulle kunna kategoriseras för att enklare kunna identifieras. Några förslag som kom upp under intervjun var; samarbetsslöseri, koordineringsslöseri, tekniskt slöseri och produktslöseri, men dessa termer existerar inte i dagsläget. Exempel på slöseri Vattenfallsmodellen är en av de vanligast förekommande projektledningsmodellerna bland företag enligt Beatric Düring. Den är lätt att förstå och skapar tydliga faser i ett projekt. Ericsson är ett exempel på företag som med sina beslutspunkter (toll gates) och Telia ett annat med sina beslutpunker (decisions points) där de möten som är kopplade till dessa beslutspunkter bara är till för att besluta om projektet skall gå vidare till nästa fas [16]. Vid varje överlämning blir det viss fördröjning och artifakter produceras som bara är till för att förenkla överlämningarna. Detta skapar slöseri i form av förseningar och överlämningar, och illustreras tydligare i ett exempel i figur 2. Betric Düring beskriver det här som en icke optimal miljö för att producera. Hon drar även kopplingen till att det är ett sätt att se på människor och produktion som närmast liknar Taylorism. Figur 2: Vattenfallsmodellen Figuren visar ett projekt drivet enligt vattenfallsmodellen där varje pil motsvarar en överlämning av arbetet. Bild uppritad av Beatric Düring under intervjun

23 Figur 3: En uppdelad resurs Figuren illustrerar hur en resurs utnyttjas i en resurseffektiv modell. Resursen arbetar på flera projekt samtidigt och har en längre lista med arbete som väntar att påbörjas. Bild uppritad av Beatric Düring under intervjun Kombineras dessutom vattenfallsmodellen med en resursmodell som går ut på att optimera sina resurser bilr det deterministiskt. Personerna/resurserna blir osthyvlade med begreppet heltidsanställd där resursen skall vara 100 % belagd med relevanta uppgifter. Detta kan vanligen resultera i att en resurs kan arbeta med flertalet projekt samtidigt vilket illustreras i figur 3 som summerar upp en anställds engagemang till en heltidstjänst. Vanligtvis har dessutom resursen långa listor med projekt som väntar på att bli gjorda vilket medför att resursen alltid är fullbelagd. Detta är exempel på uppgiftsväxling och miljöväxling vilket är slöseri. Betric Düring talar om Frederick Brooks och tar ett exempel från boken The mythical man-month. Om det tar en kvinna 9 månader att bli gravid och föda barn, kan då 9 kvinnor göra samma sak på 1 månad? Svaret är givetvis nej och liknelsen till mjukvaruutveckling är inte självklar men det är ändå enklare att förstå vad som menas med komplexa projekt med detta exempel, ibland finns det inga genvägar. Samspelet mellan en fasbaserad projektmodell i kombination med en matris eller funktionell resursmodell och avsaknad av en kapacitetsstyrning är inte bara dålig utan usel med hänsyn till slöseri. 5.2 Intervju med Henrik Kniberg Henrik Kniberg är agil coach och jobbar på Crisp. Henrik Kniberg har skrivit ett antal böcker om olika modeller och framförallt om användning av flera modeller samtidigt och hur dessa implementeras. Vid intervjutillfället var Henrik Kniberg inhyrd konsult på Spotify och intervjun gjordes på Spotifys huvudkontor i Stockholm på Birger Jarlsgatan 61 torsdagen 3:e april Intervjun varade 59 minuter. Begreppet slöseri Mary Poppendieck argumenterar för att allt som kostar tid och pengar för kunden och som inte är direkt värdeskapande är slöseri. Om kunden kontrollerade allt arbete som görs, skulle kunden kunna argumentera för att all mjukvara är slöseri. Kunden har beskrivit ett problem som skall lösas, men har inte bett om mjukvara. Exempelvis på Spotify, kundens behov är att få sin musik tillgänglig överallt, när som helst. I kundens behov finns inte mjukvara specificerat. Detta resonemang har Henrik Kniberg fört tillsammans med David Anderson som skrivit en bok om mjukvaruutveckling med fokus på kanban metoden. David Anderson hade, innan diskussionen med Henrik Kniberg, skri- 23

24 vit om begreppet slöseri i sin bok, men strök det helt efter att ha resonerat med Henrik Kniberg om det. Det kanske är bättre att använda en mer informell definition av begreppet slöseri? Henrik pratar om att det som är i vägen eller hindrar arbetet från att genomföras fortare kan ses som slöseri. Några exempel är långsamma datorer, kommunikationsmissar och lång återkopplingsslinga från beställaren. För Henrik Kniberg är det värdefullt att se på slöseri genom att låta gruppen han arbetar med beskriva vilka hinder de har för att lösa deras problem nu. Vad finns det att göra som kan få arbetet att går snabbare? Detta kan teamet ofta svara på själva och sedan får teamet prioritera dessa hinder för att se vad som är viktigast att eliminera. Kartläggning av värdeflöde Henrik berättar om ett exempel på hur slöseri kan identifieras med hjälp av kartläggning av värdeflöden. Om en idé följs från idéstadie tills den är i produktion med hjälp av en tidslinje, där händelser är utmarkerade, kan icke värdeskapande tid, det vill säga slöseri, identifieras. Exempelvis; en idé föds i ett idéstadie och innan första mötet blir av hinner det gå ett par dagar, vid första mötet tas en aktivitetslista fram som levereras till en grupp som producerar en första version. Efter att gruppen utvecklat klart programmet lämnas detta över till ett annan grupp som testar, identifierar buggar som de rapporterar tillbaka till utvecklarna som i sin tur rättar till och levererar till testarna igen. Detta pågår tills kvalitén på produkten är god och då släpps den till produktion, det vill säga att den levereras till kunden. Om det i detta exempel tog 90 dagar för projektet från start till mål, men bara aktivt arbete med projektet i 12 dagar, då fås en processeffektivitet som är låg och i detta fall är 78 dagar slöseri. Detta exempel illustreras i figur 4. Figur 4: Kartläggning av värdeflöde Figuren illustrerar hur en arbetsprocess går till från idéstadie till leverans. Henrik Kniberg beskriver att all tid som inte är aktiv tid i projektet skulle kunna vara slöseri. Bilden uppritad av Henrik Kniberg under intervjun Henrik Kniberg berättar vidare att detta funkar i verkligheten. Ett spelföretag han jobbade med producerade tio spel om året, men ett spel tog två år från start till mål. För att effektivisera flödet togs en person från varje funktion och sattes i en grupp med blandade egenskaper, varje grupp fick arbeta på egen hand med ett spel från idé till lansering. Där hade varje grupp i uppgift att tillsammans skapa ett spel i taget. Resurseffektivitet är inte i fokus utan flödeseffektivitet är det centrala och arbetet har hela tiden fokus på det som är mest angeläget för gruppen att lösa vid den tidpunkten. Varannan vecka demonstrerade gruppen hur långt de kommit. Detta resulterade i att en grupp blev klar med ett spel var tredje månad och totalt påverkades inte antalet släppta spel per år, det var fortfarande tio 24

25 precis som innan. Detta visualiseras i figur 5. Men även om antalet levererade spel hade sjunkit med % per år hade det varit acceptabelt då tiden till marknaden blev oerhört mycket kortare och det ledde till mindre delvis utfört arbete. Det resulterade i snabbare avkastning på investering och de investerade pengarna kom tillbaka snabbare och företaget behövde således inte ligga ute med lika mycket kapital. En grupp som arbetar på detta sättet kommer dessutom att identifiera defekter i ett tidigare skede och minska slöseriet. Tack vare denna omorganisation minskade flera olika typer av slöseri och företaget ökade sin lönsamhet. Detta arbetssätt har också givetvis slöseri men inte alls lika mycket. Ur en konkurenssynpunkt blir det ledtiden som är den konkurerande faktorn och med kort ledtid blir det enklare att få nöjda kunder, eftersom kunder snabbare får produkten levererad. Figur 5: Resurseffektiv i motsats till Flödeseffektiv Figuren illustrerar skillnaden mellan att arbeta resurseffektivt och flödeseffektivt. Henrik beskriver att det är värt att arbeta flödeseffektivt även om det i teorin borde resultera i % reducerat levererat arbete. Detta eftersom tiden till marknaden reduceras avsevärt. I de praktiska exempel som Henrik Kniberg beskriver påverkades inte produktiviteten. Bilden uppritad av Henrik Kniberg under intervjun Flödeseffektivt vs. resurseffektivt Henrik Kniberg pratade även om skillnaden mellan olika sätt att vara effektiv på. Ett företag som arbetar resurseffektivt låter alla sina anställda arbeta inom sitt expertisområde. Där arbetar personalen med de projekten som är i deras fas just då. Används dessutom en liten buffert mellan faserna kommer det medföra att alla hela tiden är 100 % sysselsatta inom sitt expertisområde och då har en resurseffektiv organisation uppnåtts. Att skapa köer inom organisationen är kontraproduktivt. Således är en resurseffektiv organisation långt ifrån att vara flödeseffektiv. Flödeseffektivitet står i motsats till resurseffektivitet, detta beskriver Henrik Kniberg som den största källan till 25