Slöseri inom mjukvaruutveckling
LUDWIG SMEDBERG OSCAR MO
MG100X Examensarbete inom Industriell Produktion Stockholm, Sverige 2014
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
Sammanfattning
Begreppet slöseri, av engelskans waste, är en term som i dagsläget saknar en klar och enty- dig 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 skul- le 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.
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 kandidat- arbete inom industriell produktion för att kunna läsa vidare på vår önskade Master. Årets te- ma 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 de- finitionen för avfall inom mjukvaruutveckling var dåligt definierad eller helt saknade defini- tion 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
Innehåll
1 Inledning 7
1.1 Mål och syfte . . . . 7
1.2 Att definiera . . . . 7
1.3 Avgränsningar . . . . 7
1.4 Övriga aspekter . . . . 7
1.5 Nomenklatur . . . . 7
2 Frågeställning 9 2.1 Huvudfråga . . . . 9
2.2 Underfråga . . . . 9
3 Metod 10 3.1 Val av metod . . . . 10
3.2 Metodreflektion . . . . 10
3.2.1 Intervjuteknik . . . . 10
3.2.2 Validitet . . . . 10
3.2.3 Reabilitet . . . . 10
3.2.4 Generaliserbarhet . . . . 11
4 Litteraturstudie 12 4.1 Projektledningsmetoder . . . . 12
4.1.1 Lean mjukvaruutveckling . . . . 12
4.1.2 Projektledning 2.0 . . . . 14
4.1.3 Manifestet för Agil systemutveckling . . . . 15
4.1.4 Scrum . . . . 17
4.1.5 Testdriven Utveckling . . . . 17
4.1.6 Kanban . . . . 17
4.1.7 Extrem Programmering . . . . 18
4.1.8 Vattenfallsmodellen . . . . 19
4.2 Definitioner . . . . 19
4.2.1 Teknisk skuld . . . . 19
4.2.2 Littles lag - köteori . . . . 19
5 Intervjuer 21 5.1 Intervju med Betric During . . . . 21
5.2 Intervju med Henrik Kniberg . . . . 23
5.3 Intervju med Emil Larsson och Johan Möller . . . . 26
6 Diskussion 28 6.1 Svenska och Engelska terminologier . . . . 28
6.2 Blanding av metoder . . . . 28
6.3 Slöseri / Avfall / Hinder / Impediments / Waste . . . . 28
6.4 All mjukvara är slöseri . . . . 29
6.5 Mimimera slöseri . . . . 29
6.6 Effektivitet . . . . 29
6.7 Köer - Resurseffektiv i motsats till Flödeseffektiv . . . . 29
7 Slutsatser 30 7.1 Vad är slöseri ? . . . . 30
7.2 Finns det ett behov av en definition för slöseri ? . . . . 30
7.3 Medvetenhet kring val av verktyg och modeller . . . . 30
7.4 Fokus på rätt slöseri . . . . 31
7.5 En potentiell definition av slöseri . . . . 31
Figurer 1 Kanbantavla . . . . 18
2 Vattenfallsmodellen . . . . 22
3 En uppdelad resurs . . . . 23
4 Kartläggning av värdeflöde . . . . 24
5 Resurseffektiv i motsats till Flödeseffektiv . . . . 25
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 kom- mer 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. Stu- diens 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 kom- mer 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 upp- stått när det sakanas svenska översättningar av termer som tas upp. Nedan följer förklaring- ar 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.
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 integra- tion
Kontinuerlig testning Continous testing Koordineringsslöseri Coordination waste Kunden på samma plats On-site customer Lean Lean
Lean mjukvaruutveckling Lean Software De- velopment
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 Develop- ment
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
2 Frågeställning
2.1 Huvudfråga
Vad är slöseri inom agil IT-produktion, med fokus på mjukvaruutveckling, ur en projekt- ledares eller produktägares perspektiv?
2.2 Underfråga
Vad finns det för metoder och verktyg för att identifiera och minimera slöseri ?
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 verklighets- anknuten 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 mel- lan 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.
3.2.1 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].
3.2.2 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 in- samlingen av material inte skall påverka forskarens tolkning av data eller andra typer av förutsättningar [7].
3.2.3 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].
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.
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 4.1.1 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 mjukvaru- utveckling 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 mjukvaruutveck- ling förklaras mer ingående i bokserien “Lean Software Development” av Mary och Tom Poppendieck och är sammanfattade i Tabell 1 [1][2].
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 tillverk- ning, 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 mjukvaruutveck- ling. 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äm- ningar 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
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 program- merare 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 det- ta 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 anledning- ar 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 bero- ende 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 eli- minera 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].
4.1.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 orga- nisation. Alla beslut tas med konsensus och alla i teamet ska ha kunskap om alla delar av
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].
4.1.3 Manifestet för Agil systemutveckling
Det som kallas manifestet för agil systemutveckling sammanställdes 2001 och har fyra vär- den 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 resursef- fektivisera. 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 interac- tions 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].
De tolv agila principerna:
1. Vår högsta prioritet är att tillfredsställa kunden genom tidig och kontinuer- lig 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åna- der, 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än- dare 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].
4.1.4 Scrum
Scrum är deffinierat som "ett ramverk inom vilket människor kan hantera komplexa adap- tiva 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örs- ta uppgiften för produktägaren är att bevaka alla intressenters intressen. Det är även pro- duktä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. Scrum- ledaren ä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].
4.1.5 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].
4.1.6 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 arbets- flödet genom att dela upp arbetet i små delar, skriva varje uppgift på ett kort och sätta
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].
4.1.7 Extrem Programmering
Extrem Programmering, ofta kallat XP, är inte i ordets rätta bemärkelse en projektled- ningsmetod 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].
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]
4.1.8 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.
4.2.1 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].
4.2.2 Littles lag - köteori
Littles lag, som beskriver köteori, förklarar att med ökade köer fås ett minskat flöde, dess- utom ä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)
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].
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 2014. 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.
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 projekt- ledningsmodellerna 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 2014-04-02.
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 2014-04-02.
Kombineras dessutom vattenfallsmodel- len med en resursmodell som går ut på att optimera sina resurser bilr det determinis- tiskt. Personerna/resurserna blir osthyvla- de med begreppet heltidsanställd där re- sursen skall vara 100 % belagd med rele- vanta uppgifter. Detta kan vanligen resul- tera i att en resurs kan arbeta med flerta- let projekt samtidigt vilket illustreras i fi- gur 3 som summerar upp en anställds enga- gemang till en heltidstjänst. Vanligtvis har dessutom resursen långa listor med projekt som väntar på att bli gjorda vilket med- för att resursen alltid är fullbelagd. Detta är exempel på uppgiftsväxling och miljöväx- ling 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 lik- nelsen till mjukvaruutveckling är inte själv- klar 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 funktio- nell 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 2014. Intervjun varade 59 minuter.
Begreppetslöseri Mary Poppendieck argumenterar för att allt som kostar tid och peng- ar 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. Exem- pelvis 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-
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 identi- fieras 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 2014-04-03.
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
precis som innan. Detta visualiseras i figur 5. Men även om antalet levererade spel hade sjunkit med 10-20 % 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
10-20 % 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 2014-04-03.
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
slöseri hos många av hans kunder. Anledningen till att det ändå används är ofta att den som är chef känner sig trygg i att veta att alla resureser är 100 % sysselsatta och hela tiden gör det de är bäst på. Vid arbete i funktionsgrupper krävs kommunikation mellan de olika funktionsgrupperna och det leder ofta till missförstånd och förseningar. Det är även vanligt att all kommunikation går genom e-post eller andra skrivna dokument och då tas möjligheten till snabba frågor och andra intryck bort. Detta är en anledning till missförstånd och förseningar.
Vid arbete utanför sitt eget expertisområde, till exempel en programmerare som måste testa sin egen kod, ökar förståelsen för andra delar av processen och en lärdom fås om hur enkla misstag kan undvikas. Andra sätt att lösa problemen, som gör att det blir enklare för andra att utföra sitt arbete, kommer även det som en lärdom. Det är ett exempel på att ständigt arbeta med förbättringar. Detta medför givetvis att personalen lokalt blir mindre effektiv, men det är ett lågt pris att betala i det stora hela. Henrik Kniberg förklarar att på kort sikt kan det tolkas som minskad effektivitet men på lång sikt fås en ökad effektivitet.
Henrik Kniberg beskriver även att mellan två projekt kan det vara värdefullt att ha en labb-dag där de som arbetar får jobba med egna projekt och läsa på om nya metoder och hålla hungern uppe för att bli mer effektiva i det dagliga arbetet. I ledarskapsteori tar det ett tag för en grupp att bli ett team och jobba effektivt ocg efter alla inledande faser blir gruppen till slut ett högpresterande team. I ett högpresterande team är kommunikationen tydligare och mindre missar görs på grund av kommunikationsmissar [19].
Avslutningsvis kommenterar Henrik Kniberg med att något som ständigt är närvarande är att ständigt arbeta med förbättring då lean går ut på att ständigt förbättra. Vatten- fallsmodellen är 40 år gammal och används fortfarande trotts att de agila metoderna är effektivare. De agila metoderna är dessutom äldre än vattenfallsmodellen men tycks byta namn var tionde år för att vinna mer popularitet. Varför finns då vattenfallsmodellen kvar trotts att de agila metoderna är bättre? Den är enklare att förstå, den ger en illusion av säkerhet och dessutom tolkas de agila metoderna som svårare eftersom ett kontinuerligt förbättringsarbete måste ske där processer hela tiden måste bli bättre och det kräver både tid och engagemang.
5.3 Intervju med Emil Larsson och Johan Möller
Intervjun med Svenska Dagbladets kommersiella IT-chef Emil Larsson och utvecklingschef Johan Möller genomfördes 7 april i Svenska Dagbladets lokaler i Schibstedthuset på Västra Järnvägsgatan 21 i Stockholm. Intevjuen varade i 60 minuter.
Hur arbetar Svenska Dagbladet (SvD) SvD har historiskt sett arbetat mycket med outsourcing av det som inte är deras kärnverksamhet. Idag har de utvecklare som sitter i Stockholm, därtill har Schibstedt ett eget tjänsteföretag, kallat Centralen, som de hyr in extra resurser från på långtidskontrakt. De har även inhyrda konsulter från olika företag, både i Sverige och utomlands. Alla dessa tre resurser benämns som deras egna i projekt även fast de inte är anställda av SvD. Från ägarna Schibstedt finns det önskemål om hur arbetet med IT-säkerhet sker och vilka krav som skall uppfyllas inom det området men
bortsett från det finns inga direktiv om hur IT-projekt ska drivas, varken från ägarna eller ledningen på SvD.
Johan Möller beskriver att det inte finns några direktiv från ledningen gällande vilka projekt- och utvecklingsmodeller de skall använda och vad det leder till. Eftersom det saknas direktiv kan olika projekt ha olika arbetsformer och projektformer, detta är både på gott och ont. Det har en stor fördel, projektledningsmodellen går att anpassa för varje individuellt projekt. Det finns även nackdelar, till exempel att det ej finns klara riktlinjer för vad som gäller vilket kan skapa förvirring. I projektledning är det vanligt att prata om ett triangelförhållande mellan tid, pengar och kvalitet, för SvD är det ofta pengar som är den begränsande resursen berättar Johan Möller.
Emil Larsson förklarar att de engelska begreppen “effective” och “efficient” inte är samma sak, men i det svenska språket är det svårt att skilja dessa åt. Emil Larsson berättar att vid outsourcing behövs en mellanhand, någon som har kontakt och leder de som utför arbetet.
Detta kommer leda till att effektiviteten (efficient) går ner samtidigt som effektiviteten (effective) går upp och priset på mantimmar är mindre.
Inom Svenska Dagbladet arbetas det både med resurseffektivitet och flödeseffektivitet.
Inom förvaltning är det viktigare att vara resurseffektiv samtidigt som i produktutvecklingen är det viktigare att vara flödeseffektiv och ha kort tid till marknaden enligt Emil Larsson.
Båda två är eniga om att SvD har ett agilt utvecklingssätt med veckomöten varje vecka där det bestäms vad som skall prioriteras för kommande veckan. På SvD är projekt inte mindre än en månad och det är inte ovanligt att projekt är två år, så långa projekt kallas för program istället. Det är vanligt att en medarbetare arbetar i flera projekt samtidigt, speciellt om projekten är mindre, dock förklarar Johan Möller att en medarbetare inte skall vara delaktig i för många projekt samtidigt med hänsyn till slöseri .
I dagsläget finns inget aktivt arbete med att öka sin resurseffektivitet eller flödesef- fektivitet i sin produktion. När de arbetar med nya idéer placeras dessa i deras idélista tillsammans med alla andra idéer. Här görs då prioriteringen mellan bra och mindre bra idéer samt en tidsestimering. Bra idéer som beräknas ta lite tid går direkt till ett utveck- lingsteam, samtidigt som större projekt prioriteras mot andra och planeras in när tid finns.
En idé kan fastna i denna idélista och avskrivas efter en tid då den blivit inaktuell. Dessa prioriteringsmöten hålls varannan vecka.
Slöseri Det händer att ideér som realiseras till projekt läggs ner. Detta är oftast på grund av att kvaliteten bedöms vara undermålig eller att det tar produkten i fel rikting. Ibland tar det lång tid innan dessa projekt stoppas, Johan Möller berättar att han varit med i ett projekt som pågått i två år som var färdigt för att släppas till produktion men det lades ner för att det inte mötte kvalitetskraven. Detta är uppenbart slöseri kommenterar både Emil Larsson och Johan Möller, dock lär sig både personalen och organisationen mycket på ett sådant projekt. Även funktioner och finesser som är beställda och levererade, men inte används, är också slöseri.
6 Diskussion
6.1 Svenska och Engelska terminologier
En upptäckt som gjordes tidigt var att det finns väldigt begränsat med information på svenska om mjukvaruutveckling och projektledning inom IT-branchen. Nästan all literatur är på engelska och i de få svenska källorna används samma engelska begrepp, det vill säga att de ej översätts. Termer som “waste”, “lean software development” och “time to market”
används även i de svenska källorna. Under intervjuerna som gjordes till denna rapport söktes definitionen för det svenska begreppet slöseri inom mjukvaruutveckling men det diskuterades nästan enbart om “waste” då det är ett starkt förankrat ord inom IT-branchen även i Sverige.
I den agila gemenskapen talas det nästan uteslutande engelska, men då det talas andra språk används fortfarande samma engelska termer, inga begrepp översätts och detta är förmodligen för att minska risken för missförstånd som leder till slöseri. I den svenska agila gemenskapen pratas en härlig blandning av svenska och engelska, ofta kallad “swenglish”
eller “svengelska”. Ett bra exempel är just hur den agila gemenskapen benämns, som brukar benämnas “den agila communityn”.
6.2 Blanding av metoder
Något som tog lite tid att förstå var att en metod sällan används rakt av till fullo. I början hittades endast litteratur som beskriver enskilda metoder och dess verktyg men när kontakt upprättades med personer inom IT-branchen kunde ingen svara enkelt på frågan:
vilken projektledningsmetod använder ni er av? När ingen kunde svara på den frågan kom en följdfråga: varför kan ingen svara på denna fråga? Slutligen hittades litteratur som beskriver kombinationer av olika metoder och vilka verktyg som då tas från respektive metoder [Bok 4]. Den upptäckten gav en större förståelse för IT-branchen och dess olika projektmetoder. Eftersom olika metoder har olika huvudfokus går det att få fram en mer heltäckande projektmetod genom att blanda olika metoder. Dock är det vanligt att företag blandar olika metoder och modeller på grund av kunskapsbrist, det är då enklare att plocka de verktyg som förstås och kan användas istället för att skaffa komplett kunnskap om en metod. Det betyder inte att det är fel att blanda metoder, snarare tvärt om, men det krävs god kunnskap och förståelse för att kunna uppnå en bra blandning av olika metoder och verktyg.
6.3 Slöseri / Avfall / Hinder / Impediments / Waste
I scrum användes begreppet hinder och i lean mjukvaruutveckling användes begreppet slö- seri men de syftar i grund och botten till samma sak men benämner det med två olika ord.
Direktöversättningen av “waste” till avfall är inte optimal, slöseri är en mer passande term i IT-branchen. Oavsett vilket ord som används menas mer eller mindre samma sak i den agila gemenskapen, det är som en kollektiv kunskap där alla förstår vad som menas utan att det finns en klart definition och huvudsakligen används ordet “waste” på alla språk.
