Karlstads universitet 651 88 Karlstad Tfn 054-700 10 00 Fax 054-700 14 60 Information@kau.se www.kau.se
Fakulteten för ekonomi, kommunikation och IT
Jenny Ericsson
Kanban
Går metoden att använda för att styra utvecklingsprojekt?
Informatik C-uppsats
Datum: VT 2011
Handledare: Lars-Erik Axelsson
Examinator: Remigijus Gustas
Sammanfattning
Kanban är en agil metod som härstammar från den japanska Lean-filosofin. Metoden
fokuserar på att få ett flöde med så kort ledtid som möjligt. Det ska vara lätt att se flaskhalsar som bildas. Problemen ska sedan lösas innan något nytt arbete påbörjas. Kanban-metoden ska vara enkel och lätt att använda.
Syftet med uppsatsen var att ta reda på om Kanban-metoden verkligen är en bra metod att använda sig av för att styra utvecklingsprojekt och om den bidrar till att stödja planering och information. Undersökningen syftade också till att se om det finns några problem och brister med metoden, samt om den behöver kompletteras med delar från andra metoder.
Undersökningen genomfördes genom att först samla in teori inom området för att få den kunskap om olika metoder som behövs för att kunna svara på de frågeställningar som
undersökningen syftar till att svara på. Empirin samlades in på ett företag som använder sig av Kanban genom intervjuer med tre av de anställda.
Kanban kan användas som en projektstyrningsmetod även om det blir en bättre metod om den kompletteras med delar från andra metoder utifrån vad företaget tycker är bra och vad de känner att de behöver. Metoden är ett bra stöd vad gäller planering och information då den visuella Kanban-tavlan gör den tydlig och lättillgänglig för alla på företaget. Det finns en del brister och problem med metoden, varav den största bristen är att det är svårt att ge en exakt leveranstid.
Innehåll
1. Inledning ... 1
1.1. Bakgrund och problemområde ... 1
1.2. Syfte och frågeställning ... 2
1.3. Målgrupp ... 2
1.4. Avgränsning ... 2
2. Metod ... 4
2.1. Val av metod ... 4
2.2. Datainsamling ... 5
2.3. Reliabilitet och validitet ... 5
3. Referensram ... 7
3.1. Projektformen ... 7
3.1.1. Vad är projekt? ... 7
3.1.2. Olika typer av projekt ... 7
3.1.3. Projektledningsmetodik ... 8
3.1.4. Projektmetoder ... 8
3.1.5. Problem vid projektstyrning ... 9
3.2. Agila metoder ... 9
3.2.1. Kanban ... 11
3.2.2. Extrem programmering ... 13
3.2.3. Scrum ... 14
3.2.4. DSDM – Dynamic Systems Development Method ... 16
4. Empiri ... 18
4.1. Presentation av medverkande verksamhet ... 18
4.2. Kanban som projektstyrningsmetod ... 18
4.3. Stöd för planering och information ... 20
4.4. Brister och problem med metoden ... 21
4.5. Komplettering med andra metoder ... 21
5. Analys ... 23
5.1. Kanban som projektstyrningsmetod ... 23
5.2. Stöd för planering och information ... 24
5.3. Brister och problem med metoden ... 25
5.4. Komplettering med andra metoder ... 26
6. Slutsatser ... 27
Referenser ... 29
Litteratur ... 29
Webbdokument ... 29
Muntliga källor ... 30 Bilaga 1 ... I Bilaga 2 ... I
1
1. Inledning
Valet av ämne uppstod då jag fick en fråga om det kunde vara av intresse att skriva om Kanban-metoden från det företag som empirin kommer att hämtas från. Då jag tycker att det är intressant att studera olika projektstyrningsmetoder passade det mig väldigt bra att skriva uppsatsen om det. Att få en bättre inblick i olika metoder och att utifrån det se om det finns en metod som är bättre än någon annan eller om en kombination av flera metoder kan vara det bästa intresserar mig mycket. Det som gör ämnet intressant är också att det är känt att det finns vissa problem med att lyckas med ett projekt. Att därför studera ämnet för att se om det finns någon metod som gör att det går att lösa i alla fall en del av problemen tycker jag är väldigt intressant. Att dessutom fördjupa sig i en relativt ny metod, i alla fall vad det gäller att styra projekt, ska bli väldigt kul.
1.1. Bakgrund och problemområde
”Kanban är ett allt mer populärt redskap i mjukvaruvärlden. Kanban kan användas i nästan alla typer av existerande organisationer för att synliggöra och kontinuerligt förbättra hela värdekedjan, från definierat kundbehov till lyckad leverans. Genom att införa Kanban blir organisationen mer lättrörlig och anammar flera kända principer inom Lean Software Development, vilket möjliggör:
Fokus på flöde med kort ledtid – ”att få saker klara snabbt”
Synliggörande av flaskhalsar
Hantering av löpande omprioriteringar
Just-in-time produktion (pull istället för push)”
Ovanstående är ett citat från hemsidan www.softhouse.se [2011-02-27], vilket visar att det börjar bli vanligare att Kanban används som en projektstyrningsmetod inom
mjukvaruutveckling.
Kanban är en agil metod, men som har sitt ursprung i Lean-filosofin och härstammar från Japan där metoden togs fram av Toyota för att användas vid produktionsstyrningen i deras fabriker. Det gick till så att om en del i produktionen höll på att ta slut skickades det ett visuellt kort, som ordet kanban också betyder, till orderavdelningen som kunde beställa nya delar och se till att produktionen fortsatte att rulla. De flaskhalsar som fanns i produktionen upptäcktes på ett tidigt stadium och produktionen stannade inte upp som den gjort tidigare (Andersson, 2010).
Enligt Gross och McInnis (2003) var det Taiichi Onho som på sent 40-tal och i början av 50- talet utvecklade Kanban för att kontrollera produktionen mellan olika processer och införa Just-In-Time i Toyotas fabriker i Japan. Det anammades dock inte i resten av världen förrän på 70-talet.
2 Kanban-metoden har på senare tid börjat användas som en projektstyrningsmetod och har funnits som sådan sedan år 2004. Personen som införde det här sättet att tänka på inom mjukvaruutveckling heter David Anderson (Crisp, 2011a).
Det verkar som att Kanban är en metod som är här för att stanna. Många som använder sig av Kanban som metod tycker om dess enkelhet och att den är lätt att använda sig av. De tycker också att det blir tydligt att se vilka flaskhalsar som finns och att se till att lösa dem innan något annat arbete påbörjas.
1.2. Syfte och frågeställning
Syftet med uppsatsen är att undersöka om Kanban är en god metod att använda sig av för att kunna få en bra överblick över vad som ska göras i olika projekt och vilka problem som finns.
Undersökningen syftar också till att se om det går att använda enbart Kanban eller om det krävs ytterligare en metod som kompletterar de eventuella brister som finns med Kanban- metoden, samt att då också ta reda på vilka de eventuella bristerna är.
De frågeställningar som kommer att undersökas är:
Går det verkligen att använda sig av Kanban som en metod för att driva projekt och samtidigt ge ett stöd för planering och information om olika utvecklingsprojekt?
Finns det några brister med metoden och vilka är de i sådana fall?
Behöver metoden kompletteras med andra metoder eller går den att användas enskilt?
1.3. Målgrupp
Jag hoppas att den här uppsatsen kan bidra till en bättre förståelse av vad Kanban är och vad metoden kan bidra med till företag som inte tillämpar den som en lagerstyrningsmetod. Den primära målgruppen är det företag som kommit med idén till ämnet, men jag hoppas även att andra företag som arbetar med Kanban eller som funderar på att börja arbeta med Kanban som projektstyrningsmetod ska tycka att uppsatsen är av intresse.
Uppsatsen vänder sig också till lärare, forskare och studenter som har en grundläggande kunskap inom ämnet Informatik i form av en eller två grundkurser då jag anser att det är tillräckligt för att känna till de termer som kommer att användas i uppsatsen.
1.4. Avgränsning
Det skulle gå att jämföra Kanban-metoden med alla projektstyrningsmetoder som finns. För att göra en avgränsning har jag valt ut tre metoder som jag kommer att jämföra den med.
Anledningen är att det ska bli lätt att se fel och brister, men också fördelar som finns med metoden i jämförelse med de andra metoder som finns tillgängliga. De metoder jag har valt att jämföra med är Scrum, Extrem programmering och DSDM. Anledningen till att jag valde just de här metoderna är för att de alla är agila metoder som kan användas vid projektstyrning av mjukvaruutvecklingsprojekt.
3 Undersökningen kommer att göras utifrån företaget PromoSoft, som använder sig av Kanban som en projektstyrningsmetod.
4
2. Metod
2.1. Val av metod
Jag har valt att göra en kvalitativ forskning då jag anser att jag behöver en djupare kunskap om ämnet för att kunna göra en bra analys. I och med att det är textmaterial och empiri i form av intervjuer som ska bearbetas lämpar det sig bäst med kvalitativ forskning enligt Patel och Davidson (2003), medan kvantitativ forskning är mer lämpad för bearbetning av statistiska metoder för analys av information i numerisk form.
Induktion och deduktion är två olika sätt för att relatera teori och empiri. Vid ett deduktivt arbetssätt dras slutsatser om enskilda företeelser utifrån allmänna principer och befintliga teorier. Genom det här arbetssättet anser Patel och Davidson (2003) att objektiviteten stärks i och med att utgångspunkten tas från den befintliga teorin. En fara med den här typen av arbetssätt kan vara att det blir för mycket fokus på den befintliga teorin så att inga nya intressanta rön framkommer.
Ett annat arbetssätt är att arbeta induktivt. Här utgås det från empirin. All information samlas in och utifrån den empiri som fåtts formuleras en teori. Faran med arbetssättet är att
räckvidden eller generaliseringen på teorin inte framkommer (Patel & Davidson, 2003).
Det arbetssätt jag kommer att tillämpa i den här uppsatsen är ett deduktivt arbetssätt då jag först kommer att samla information om olika teorier och därefter samla in empiri från det företag undersökningen kommer att utföras på. Därefter kommer jag att ställa empirin mot teorin i min analys för att få svar på mitt syfte och de frågeställningar jag har.
Jag kommer också att utföra kvalitativa intervjuer med utvecklingschefen på företaget PromoSoft, samt ställa några övergripande frågor till två av de anställda utvecklarna på företaget. De övergripande frågorna består av fyra av frågorna som jag också kommer att ställa till utvecklingschefen mest för att se om de uppfattar metoden på samma sätt. Frågorna kommer att väljas ut med avseende på syftet som finns med uppsatsen, men med mest fokus på de problem som kan finnas med metoden. De intervjuer som kommer att genomföras kommer att ske med hög strukturering, det vill säga att det finns en bestämd ordning på frågorna. Precis som Patel och Davidson (2003) hävdar, är syftet med de kvalitativa intervjuer jag kommer att utföra att upptäcka och identifiera de egenskaper och uppfattningar som finns hos någonting. Det kan vara den intervjuades uppfattningar om något fenomen, i det här fallet blir det då Kanban-metoden. För att kunna ta del av svaren på ett bra sätt kommer jag först att studera tidigare forskning inom området. Jag kommer också att studera de andra metoder som Kanban kommer att jämföras med för att kunna göra en trovärdig analys.
Enligt Patel och Davidsson (2003) dyker det säkerligen upp en hel del tankar som rör hela problemområdet och som de också hävdar är bra kommer jag att skriva ner mina tankar under arbetets gång då jag tror att de kan hjälpa mig i min analys.
5 Jag kommer också att göra löpande analyser, det vill säga att jag kommer att påbörja analysen så fort som möjligt efter den första intervjun för att få idéer om hur arbetet kan gå vidare.
Enligt Patel och Davidson (2003) kan eventuell ny och oväntad information berika
undersökningen. Det är också bra att påbörja analysen kort tid efter intervjun då svaren finns färskt i minnet. Om det visar sig vara behövligt kommer fler intervjuer göras för att få svar på de eventuella frågor som inte ställdes vid den första intervjun.
2.2. Datainsamling
Jag har utgått både från skriftliga och muntliga källor i min referensram, vilket är böcker, olika elektroniska dokument och artiklar hämtade från Internet. Jag har även gjort intervjuer med tre personer på företaget PromoSoft, där undersökningen utförs för att ta del av den kunskap som de har om Kanban. Den information som fås fram kommer sedan att vägas samman i analysen för att ge svar på de frågeställningar som undersökningen syftar att ge svar på.
2.3. Reliabilitet och validitet
Det är viktigt att säkerheten i den information som presenteras är hög, dvs. att ha god validitet och reliabilitet. Att ha god validitet innebär att det som ska undersökas verkligen undersöks och att ha god reliabilitet innebär att informationen presenteras på ett tillförlitligt sätt (Patel &
Davidson, 2003).
Reliabilitet vid en kvantitativ forskning används i stort sett inte då det är starkt kopplat till validiteten. Det anses t.ex. inte som låg reliabilitet, som det hade gjort om det gällt kvantitativ forskning, om den som intervjuas svarar olika vid olika tillfällen. Det beror på att den som intervjuas kan ha ändrat uppfattning om ämnet eller lärt sig något nytt, vilket kan vara av intresse för forskaren vid en kvalitativ forskning. Reliabiliteten bör därför ses utifrån den situation som finns vid undersökningen, vilket också kommer att göras vid de intervjuer jag kommer att genomföra vid min undersökning (Patel & Davidson, 2003).
Validitet vid en kvalitativ forskning gäller, enligt Patel och Davidson (2003), hela
forskningsprocessen då ambitionen är att tolka och förstå innebörden av olika saker, beskriva uppfattningar om något eller den kultur som finns. Validiteten vid datainsamlingen beror på om rätt information har samlats in för att tolkningen ska ses som trovärdig, om informationen visar mångtydighet och om den eventuellt är motsägelsefull. De tolkningar som formuleras måste tillföra kunskap om det som studeras för att det ska bli trovärdigt. Det är viktigt att tydligt visa kopplingen mellan problemet och resultatet. Eftersom varje kvalitativ
undersökning är unik finns det därmed inga speciella regler eller procedurer för att säkerställa validiteten.
Det finns en hel del material om Kanban och de andra projektstyrningsmetoderna som avser att undersökas. Det mesta materialet finns på webben, vilket också har använts i studien. För att säkerställa att materialet är äkta och trovärdigt har jag på ett grundligt sätt gått igenom det.
För att kunna göra en bedömning om de fakta som framkommer är sannolikt kommer jag att hålla mig kritisk till de dokument jag hämtar information ifrån. I enlighet med vad Patel och
6 Davidson (2003) säger om källkritik kommer jag att försöka ta reda på när och var
dokumenten tillkommit, vilket syfte den som skrev informationen hade, samt vem
upphovsmannen är och vilken relation han/hon har till ämnet. Jag tror att tillvägagångssättet ska kunna säkerställa ett äkta och trovärdigt material.
Jag anser att den information som framkommer i uppsatsen är av god validitet. De källor som informationen hämtats från är skriven av människor som har mycket kunskap om ämnet. Det har säkerställts genom den källkritik jag skriver om här ovan. Även empirin anser jag har god validitet då företaget där informationen hämtas arbetar dagligen med Kanban-metoden. Jag tycker dock att det skulle ha varit bra att kunna jämföra den med ett eller två företag till som håller på med mjukvaruutveckling för att få ett mer tillförlitligt svar på mina frågeställningar, speciellt vad det gäller vilka brister och problem som kan finnas med metoden.
7
3. Referensram 3.1. Projektformen
3.1.1. Vad är projekt?
Projektledningsläran och projektorganisationen härstammar från den amerikanska
försvarsmakten. Redan så tidigt som på 30-talet började de använda sig av projektformen för att styra utvecklingen av nya flygplanstyper (Bergman & Lindkvist, 2001).
Ett projekt är enligt Jansson och Ljung (2004) en avgränsad engångsuppgift som har ett specificerat slutresultat med tids- och kostnadsramar. Det är svårt att definiera exakt vad ett projekt är, däremot så finns det fem karaktärsdrag som kan användas för att bestämma om en uppgift skulle kunna utföras i projektform. Det handlar om att det är en temporär uppgift, att syftet är att skapa något nytt, att det är en engångsuppgift, att uppgiften är omfattande eller komplex och att den är viktig för verksamheten. Det som är viktigt att tänka på är att bedöma vilka risker och fördelar som finns med att utföra uppgiften i projektarbetsform.
Vid den traditionella projektledningsläran ligger fokus på synen på projekt som uppdrag. Ofta är det den så kallade projekttriangeln, se figur 1, som blir en utgångspunkt. Den säger att ett projekt är ett uppdrag som ska vara klart vid en viss tid, med ett visst innehåll och med en viss budget (Bergman & Lindkvist, 2001).
Figur 1: Projekttriangeln (Bergman & Lindkvist, 2001)
3.1.2. Olika typer av projekt
Det finns olika typer av projekt. Det är inte alla projekt som har samma likheter och krav på projektledningen. De projekt som kan finnas kan vara produktutvecklingsprojekt för att utveckla produkter, det vill säga varor och tjänster. Marknadsprojekt som handlar om att etablera en verksamhet på en ny marknad eller att bearbeta en ny kundgrupp. Interna förändringsprojekt vid omorganisation för att införa nya rutiner och satsningar på personal och utbildning. Kundorderprojekt där varor och tjänster levereras, samt evenemangsprojekt
Tid
Kostnad Funktionalitet
8 vid olika evenemang, t.ex. en teaterföreställning eller melodifestivalen (Ljung & Jansson, 2004).
3.1.3. Projektledningsmetodik
Det som projektledningsmetodik handlar om är att leda och styra arbetet i projektet. Under tiden som arbetet pågår görs en bedömning av risker och möjligheter, som planerna därefter anpassas utefter. Arbetet pågår under hela projektets gång till dess att det är färdigt att överlämnas till kunden och till de chefer som ska förvalta projektresultatet i den egna organisationen (Ljung & Jansson, 2004).
De verktyg som finns att tillgå vid projektledningsmetodiken är systematiska metoder för uppskattning av tidsåtgång, analyser av risker, tillvägagångssätt för att göra en tidsplan, räkna fram en budget, utformning av överlämningsprocedurer etc. Det kan också handla om
förståelse av vissa grundbegrepp som t.ex. en risks sannolikhet och konsekvens eller skillnaden på ledtid och resursåtgång (Ljung & Jansson, 2004).
Det är, enligt Becker et. Al. (2003), viktigt att förhindra att aktiviteter i projektet uppstår som inte har med målet för projektet att göra.
Förr fokuserades projektledarens roll väldigt mycket på planering, uppgiftsnedbrytning, uppföljning och kontroll. På senare tid har projektledarens ansvar också utökats till att leda och lösa de konflikter som uppstår i projektteamet för att skapa engagemang bland
projektdeltagarna (Bergman & Lindkvist, 2001).
Jansson och Ljung (2004) hävdar också att det är viktigt att skapa förutsättningar för deltagarna i teamet så att de kan utvecklas och nå ett bra arbetsresultat.
3.1.4. Projektmetoder
Projektmetoder hjälper till att arbeta mer effektivt genom att tala om vad som ska göras till en viss utsträckning. Det finns ingen metod som är bättre än en annan utan det beror mer på vad den ska användas till om den är bra. Det finns med andra ord ingen metod som är perfekt eller komplett. Metoderna kan heller inte visa exakt allt som ska göras utan det de gör är att ge vissa begränsningar och regler som ett företag kan arbeta utefter. Det är inte verktyget som gör att ett projekt lyckas, men det kan hjälpa till att få projektet att lyckas (Kniberg & Skarin, 2010).
Det finns olika projektmodeller som kan användas som ett stöd för kommunikationen om projektet med andra och som ökar möjligheten att ta ett bra ledningsbeslut (Jansson & Ljung, 2004).
Bell (2005) menar att det finns ett stort behov av organisation vid utvecklingsprojekt. Det som behövs är främst metoder och verktyg, samt en övergripande plan eller strategi. Det här finns i olika processmodeller, som är en plan där det finns olika steg som behöver gås igenom under utvecklingen. En modell är bara en bedömning av hur verkligheten ser ut, inte en exakt avbild. En processmodell har två användningsområden. Den kan användas som en bas för
9 projektplanering där det går att förutse vad som ska göras. Den kan också användas för att analysera vad som verkligen händer under ett projekt där det går att förbättra processerna för pågående och kommande projekt.
Det finns en mängd olika processmodeller som t.ex. vattenfall, prototyping, inkrementell, agil, rationell, open source och gör det själv (Bell, 2005).
3.1.5. Problem vid projektstyrning
De problem som funnits vid alla typer av projekt, främst vid stora projekt, är att de inte blir färdiga i tid och drar över budget eller så brister funktionaliteten i projektet. Det blir tydligt att det inte går att mäta framgången av projekt med hjälp av projekttriangeln då det är de sakerna som brister (Bergman & Lindkvist, 2001).
Enligt Bergman och Ljungkvist (2001) finns det fem punkter där IT-projekt ofta misslyckas:
Leverantörens åtagande – det är ofta inte tillräckligt definierat.
Beställarens åtagande – odefinierade förpliktelser för att kunna koordinera leverantörens arbete.
Leveranstidplanen – viktigt att veta exakt vad som ska levereras och när det ska ske.
Det är viktigt att ange tidpunkter för de olika parternas ansvar att tillsätta resurser, lämna information, säkerställa tekniska miljöer osv.
Det gemensamma projektet – de två helt olika projekten, leverantörens leveransprojekt och beställarens interna införandeprojekt, flyter lätt ihop till ett projekt.
Leveransgodkännande – alla projekt avslutas någon gång. Beställaren har oftast möjlighet att göra en leveranskontroll för att se till att leveransen uppfyller de avtalade kraven. Det skiljer sig dock mycket mellan vilka fel beställaren och leverantören anser vara så pass väsentliga att beställaren har rätt att inte godkänna resultatet.
Lösningen skulle vara en tydlig definition av leverantörens åtaganden, dvs. en bättre kravspecifikation, klarare ansvarsfördelning mellan parterna och en exakt leveranstidsplan.
Det är dock inte så lätt att göra som det låter då det är svårt att vid ett projekts början veta hur det kommer att se ut (Bergman & Ljungkvist, 2001).
3.2. Agila metoder
Agila metoder är principer som får projektarbetet att gå smidigare och består av ett antal metoder och synsätt. Genom att leverera delresultat under hela projektet blir det också ett avslut på projektet. En stor skillnad mellan agila metoder och andra metoder är att det är just resultatet och inte kostnaden eller tiden som justeras för att ett projekt ska lyckas (Gustavsson, 2007).
Det passar bra med att använda sig av agila metoder då ett användbart resultat av projektet behövs snabbt, om kravbilden i projektet är otydlig eller om kraven inte är specificerade. Det
10 passar också bra då projekt genomförs i en situation som kan förändras, vid komplexa projekt där det är svårt att se hur resultatet kommer att bli eller där ett projekt har övergått till
förvaltning och det kan ske små mini-projekt för vidareutvecklingen av resultatet (Gustavsson, 2007).
De principer som finns beskrivs enligt Gustavsson (2007) i det Agila Manifestet:
Individer och samspel framför metoder, processer och verktyg.
Körbar programvara framför omfattande dokumentation.
Kundsamarbete framför kontraktsförhandlingar.
Anpassning till förändring framför att följa en statisk plan.
Alla saker är viktiga, men de med fet stil värderas högre än de andra.
Enligt Gustavsson (2007) finns det ytterligare principer som ska bidra till att arbetet sker utefter det agila manifestet. Gustavsson har ändrat formuleringen på dem en aning så att de ska passa alla branscher. Nedanstående är ett citat:
”Viktigast är att göra kunden nöjd genom tidiga och regelbundna leveranser av värdeskapande projektresultat.
Anpassning till förändrade krav och förutsättningar är naturligt, även i ett sent skede.
Utnyttja förändring till kundens fördel.
Leverera ett för kunden användbart projektresultat ofta, helst med bara några veckors mellanrum.
Självgående och ansvarstagande individer är den främsta framgångsfaktorn. Med nödvändigt stöd och förtroende kommer de att lösa uppgiften.
Kommunikation ansikte mot ansikte är det bästa sättet att förmedla information både till och inom teamet.
Agile verkar för uthållighet: teamet skall kunna upprätthålla jämn arbetsbelastning så länge som möjligt.
Enkelhet – konsten att göra rätt saker, varken mer eller mindre – är grundläggande.
Team som organiserar sig och sitt arbete själva, får den bästa problemförståelsen och kan därför föreslå bäst lösningar på problem som uppkommer.
Gruppen utvärderar och anpassar regelbundet sitt arbetssätt för att förbättra sin effektivitet.”
11 3.2.1. Kanban
Kanban härstammar från Leanfilosofin. Lean Software Development kommer från Toyotas produktionssystem och är en ledarskapsfilosofi. Filosofin går ut på att vara snabb på att ta bort onödiga saker som görs. Då ett företag arbetar med Lean försöker de ta bort alla onödiga moment som skapar förseningar och som stör arbetsflödet för att tiden från beställning till leverans ska bli så kort som möjligt (Crisp, 2011b).
Sundkvist (2010) anser att Kanban är en metod som hjälper företag med att förstå varför projekt drar ut på tiden för att bli klara och som synliggör hela arbetsflödet. Metoden
begränsar antalet projekt, aktiviteter eller funktioner som är igång samtidigt. Det fungerar på så vis att ett visst antal projekt eller aktiviteter måste bli helt färdiga innan några nya kan påbörjas. Det vanligaste är att sätta upp post-it lappar på en White board för att sedan dela in den i olika kolumner, se figur 2, som kan vara inkommande, prioriterade, pågående och avslutade. I kolumnerna bestäms sedan hur många lappar som får sitta där samtidigt, i figur 2 finns det siffror vid varje kolumn som visar nivån, det vill säga hur många lappar som kan finnas i den kolumnen samtidigt. Det primära är sedan att kunna prioritera rätt saker och det bör göras av en utvald person. Gross och McInnis (2003) påpekar att vid ett
tillverkningsföretag som använder sig av Kanban ska operatörerna veta vad de ska göra om det uppstår problem och vem de ska vända sig till för att lösa problemet.
Figur 2: Exempel på en Kanban-tavla.
Källa: (Laribee, 2008)
12 Sundkvist (2010) menar vidare att metoden också gör att projekten verkligen avslutas innan några nya påbörjas, vilket gör att företagen inte har mängder av projekt igång samtidigt som de inte vet när och om de kan avsluta dem.
Andersson (2010) anser att Kanban-system för just mjukvaruutveckling används för att begränsa det arbete som pågår. Det finns ett antal kanban (ofta i form av post-its) som är likvärdigt med vilken kapacitet systemet ska ha. Ett kort tillhör en uppgift eller ett jobb. Varje kort agerar som en slags signal. En ny uppgift kan bara påbörjas om det finns ett kort ledigt.
Korten som tillhör en viss uppgift följer med när det går igenom hela flödet i systemet. Finns det inga lediga kort kan inga nya uppgifter påbörjas. Då en uppgift är helt klar tas den bort från kortet som återvinns och eftersom det nu är ledigt kan nästa uppgift i kön påbörjas. På det här sättet kan teamet ha en visuell överblick över vilka arbeten som är igång och de kan själva organisera och tilldela sig egna uppgifter, samt kunna flytta arbetet mellan de olika
kolumnerna. Det behövs med andra ord ingen projektledare för att godkänna det. För att ett visuellt system ska klassas som ett Kanban-system krävs det att det finns satta gränser för pågående arbete (Work-In-Progress) och att ett färdigt arbete signalerar till att ett nytt arbete kan påbörjas.
Den här sorten av system kallas för pull-system då ett nytt jobb dras in i ett system när det finns kapacitet att ta hand om det. Det trycks inte in i systemet baserat på efterfrågan som det gör vid push-system. Systemet visar också tydligt de flaskhalsar som finns och det blir en utmaning för teamet att verkligen ta tag i problemen och lösa dem för att få flödet att flyta i systemet (Andersson, 2010).
Det finns enligt Andersson (2010) fem egenskaper för Kanban; visualisera arbetsflödet, begränsa Work-In-Progress (WIP), mäta och hantera flödet, tydliggöra egenskaperna för processen, samt att använda modeller för att hitta möjligheter till förbättring.
Andersson (2010) tar också upp att det finns sex kriterier som leder till framgång med Kanban. De sex kriterierna följer här nedan:
Bristfällig kvalitet har varit ett stort problem vid mjukvaruutveckling, men det finns en del saker som kan göras för att säkerställa bra kvalitet. Att skriva enhetstester och att kontrollera koden kontinuerligt är en bra metod för att säkerställa kvaliteten på det data som ska
användas. Teamet bör helst analysera problem- och designlösningar tillsammans, samt använda sig av designmönster. Att använda sig av moderna utvecklingsverktyg är också en sak som kan bidra till ökad kvalitet.
Genom att reducera WIP förkortas också ledtiden, vilket gör det möjligt att släppa ifrån sig arbetskod oftare.
Att leverera ofta ökar trovärdigheten mot kunder. Små frekventa handlingar ger mer tillit än handlingar som är stora och som inträffar mer sällan. Att ha frekventa releaser visar kunden att företaget kan leverera och vill skapa ett värde för kunden.
13 Att balansera efterfrågan mot genomströmning, det vill säga att det sätts en nivå på hur nya krav ska accepteras som kan svara på den nivå koden kan levereras på är viktigt. Det måste finnas en bra balans här.
När alla föregående steg fungerar bra kommer det att levereras kod med hög kvalitet.
Ledtiden för utvecklingen kommer att vara relativt kort eftersom WIP är begränsad. Nytt arbete kan bara tas in om något annat är färdigt. Nu kan ledningen optimera det levererade värdet genom att förbättra möjligheten och förutsägbarheten av att leverera.
Att ändra existerande regler av processer kan drastiskt reducera källan till förändring som påverkar förutsägbarheten.
3.2.2. Extrem programmering
Extrem programmering baseras på fyra värden. Det är viktigt med kommunikation och det ses inte som ett problem. Enkel struktur i programmeringen eftersträvas även om det inte är lätt.
Frekvent information om hur utvecklingen löper så att problem kan lösas snabbt, kunden blir därmed mer medveten om vad konsekvenserna blir på deras krav. Utvecklarna måste ha mod till att slänga kod, eller att göra om delar av arkitekturen om det behövs (Bell, 2005).
Kraven förändras ständigt och med den här metoden tas förändringarna om hand istället för att de ses som ett avbrott i arbetet (Bell, 2005).
Vid Extrem programmering är alltid kunden, eller en representant för kunden, med som en medlem i utvecklingsteamet. Det som kunden gör är att ta fram användningsfall (user case), dvs. små individuella funktioner som krävs av mjukvaran som ska utvecklas. Ett
användningsfall är ett slags krav som kort beskrivs (ca tre meningar) på ett icke tekniskt språk. Det som beskrivs är alltså vad som ska implementeras. Därefter gör utvecklarna en tidsuppskattning för varje användningsfall som kan handla om några veckors mantimmar per användningsfall. När ett användningsfall sedan har fått ett pris måste ett beslut tas om det ska implementeras eller inte. Om det ska implementeras behöver kunden fylla på med mer detaljerad information om användningsfallet (Bell, 2005).
Kunden specificerar också acceptanstest för varje användningsfall, några så kallade black box tester som säkerställer att användningsfallen blivit implementerade på ett korrekt sätt, vilket det inte har blivit innan de gått igenom testet. Det är kundens ansvar att det görs. Extrem programmering använder sig av testdriven utveckling då det är acceptanstesten som styr utvecklingen. Testet skrivs innan implementeringen av användningsfallet börjar och körs sedan innan och under utvecklingen. Det leder till att de till en början misslyckas, men allt eftersom utvecklingen fortgår kommer testen till slut att lyckas (Bell, 2005).
Bell (2005) menar också att kunden har ytterligare en roll. Alla användningsfall kan inte utvecklas på samma gång utan ett fåtal väljs ut som ska göras i första hand. Det blir då kundens ansvar att välja ut vilka som är viktigast att göra först och vilka som kan vänta. Hela projektgruppen träffas dock för att diskutera vad som ska göras härnäst.
14 Extrem programmering använder sig enligt Bell (2005) av 12 tekniker som följer här nedan:
Det görs en frekvent omplanering där kunden bestämmer vilken funktion som är viktigast och vad som ska implementeras härnäst. Utvecklarna gör en tidsuppskattning och ger antingen klartecken eller säger nej till att fortsätta.
Små releaser där ett enkelt system sätts i produktion snabbt görs, sedan släpps nya versioner under en kort tid.
Metafor innebär att all utveckling görs utifrån en kort övergripande berättelse av hur hela systemet fungerar.
Utvecklarna försöker att designa systemet så enkelt som möjligt. Extra komplexitet tas bort när det upptäcks.
Utvecklarna skriver också hela tiden enhetstester, men även kunderna skriver tester som visar vilka funktioner som ska vara färdiga.
Refactoring är en viktig teknik som innebär att en omstrukturering av systemet görs, utan att ändra behovet, för att ta bort dubbletter, förbättra kommunikation och enkelhet eller för att lägga till flexibilitet.
All kod skrivs av två programmerare som samarbetar, vilket också kallas för par- programmering.
Kollektivt ägarskap innebär att alla kan ändra kod överallt i systemet när som helst.
Det används en upprepande integration, som innebär integration och byggande av systemet många gånger per dag och varje gång en uppgift är klar.
De anställda ska undvika övertid och bara arbeta 40 h/vecka.
Genom att inkludera en användare i teamet som finns tillgänglig på heltid för att svara på frågor involveras också kunden i arbetet.
En kodstandard används i och med att all kod skrivs i enlighet med regler för att få en kommunikation genom koden.
3.2.3. Scrum
Enligt Systemvaruhuset (2011a) är Scrum en metod som kännetecknas av att det ska vara roligt att arbeta. Det görs genom att ge projektgruppen både befogenhet och ansvar att lösa en uppgift. Metodens grundprinciper är att projektgruppen organiserar och planerar själv sitt arbete. Alla krav prioriteras utifrån verksamhetsnyttan. Det ska finnas en tillgänglig och beslutsför beställare, produktägaren, som också är en del av projektgruppen. Det sker en kontinuerlig prioritering genom att produktägaren hela tiden arbetar med kravbilden. Det finns också en gemensam arbetsyta, dvs. hela gruppen delar rum, samt att alla
projektmedlemmar är ansvarstagande.
15 Vid användning av Scrum utgår projektgruppen från en redan befintlig kravbild som tagits fram och där kraven är prioriterade och grovt tidsuppskattade. Därefter delas tillverkningen in i iterationer, som i Scrum kallas för sprintar. En sprint inleds med en planering och avslutas med en demo på 3-4 timmar, där datum och innehåll har bestämts i planeringen
(Systemvaruhuset, 2011a).
Sprintplaneringen tar 4-8 timmar och det är här kraven bryts ner i mindre aktiviteter och en tidsplanering görs. Ingen aktivitet får vara mer än 16 timmar. Visar det sig att det är
aktiviteter som inte hinns med att göra i den aktuella sprinten måste de krav som inte anses vara viktigast vänta till nästa sprint. Vid Scrum prioriteras tid och tillräcklig kvalitet istället för omfattning. Resultatet av planeringen utgör sprintens aktivitetsplan (sprint backlog). Det är inte så att gruppmedlemmarna blir tilldelade uppgifter utan de väljer det som de vill göra.
Under sprinten har gruppen dagliga stå-upp-möten då alla medlemmar ska besvara tre frågor:
1. Vad har jag gjort sedan igår?
2. Vad ska jag åstadkomma tills i morgon?
3. Vad hindrar mig?
Sista punkten i en sprint är en förbättringsaktivitet då gruppen diskuterar vad som gått bra och vad som kan göras bättre. Det är utifrån det här som gruppen bestämmer hur arbetet i nästa sprint ska utföras (Systemvaruhuset, 2011a).
Det finns tre olika roller vid metoden enligt Systemvaruhuset (2011a) och Koch (2005).
Produktägaren (Product Owner) ansvarar för kravbilden genom att ta emot, hantera och prioritera önskemål/krav på en produkt.
Processledaren (Scrum Master) säkerställer att processen följs, synkroniserar mellan aktörer och avlägsnar de hinder som finns för utvecklargruppen. Processledaren liknas ofta vid en projektledare, men eftersom projektgruppen är självstyrande stämmer inte det.
Den tredje rollen är projektgruppen (Team). Eftersom utvecklargruppen är självstyrande finns inga definierade roller utan det bestäms efterhand vem som ansvarar för vad. Gruppen bör bestå av 5-9 personer.
Enligt Systemvaruhuset (2011a) och Koch (2005) finns det tre dokument som alltid tas fram i Scrumprojekt. Kravbild (Product Backlog), där alla krav specificeras av produktägaren. Det finns ingen begränsning på hur många det får finnas, men alla krav prioriteras. Statusgraf (Burndown Chart) som är en grafisk representation av nuläget i projektet. Grafen visar hur mycket arbete som är kvar att göra med hänsyn till hur lång tid som finns tillgänglig. Grafen är till nytta för att förutse vid vilken tidpunkt allt arbete kommer att vara utfört. Uppgiftslistan (Sprint Backlog) där de aktiviteter som finns i projektets Product Backlog ska implementeras under den kommande sprinten.
16 Det finns viss kritik att läsa om Scrum där vissa tycker att metoden endast passar för små projekt då det finns en begränsning i maximal gruppstorlek, iterationslängd och samarbete i samma lokal. Det blir svårt att genomföra vid större projekt där det måste vara fler personer inblandade i projekten. Ett annat problem är stöd för återblickar. Det är lätt att se vad som har gjorts i varje sprint, men då det kommer till frågan om hur det gjorts blir det problem
(Larsson, 2008).
3.2.4. DSDM – Dynamic Systems Development Method
DSDM är en iterativ och inkrementell metod som fokuserar på att få ordning på helheten. Det görs genom en tydlig förklaring till de delar som måste finnas med och hur de hänger ihop, men det beskrivs inte exakt vad innehållet i delarna är. Metoden lämpar sig bäst vid små projekt där tiden är en kritisk framgångsfaktor och där det finns ett gränssnitt som tydligt visar användarna systemets funktionalitet (Systemvaruhuset 2011c).
DSDM består av fem faser. De två första faserna är sekventiella och de tre följande är iterativa. Koch (2005) har en förklaring till att det bestäms vid varje projekt vilka faser som ska vara iterativa för att kunna möta det behov som finns för olika projekt. Utöver de ovan nämnda faserna finns det två faser till som är förstudie och efterarbete (Systemvaruhuset, 2011c).
Vid den första fasen, feasibility study, verifieras det att DSDM är rätt arbetssätt för just det här projektet. Här kollas också att det faktiskt går att genomföra projektet till en rimlig kostnad. Vid verksamhetsanalysen skapas en förståelse för vilka systemets användare är och hur de vill att systemet ska fungera för att passa in i deras verksamhet. Vid den tredje fasen, som är functional model iteration, tas ett system fram utifrån det som framkommit under föregående fas, som kan användas för att verifiera och validera kraven. Det läggs stor tyngd på användbarhetsaspekter och endast funktionella tester genomförs. Därefter slutförs systemet så att det går att överlämna det till användarna. Det testade systemet är ett viktigt resultat av den här fasen som heter design and build iteration. Den femte och sista fasen heter
implementation iteration. Det är i den här fasen som arbetet görs från det att systemet är färdigt tills användarna kommit igång med arbetet. Här ingår också utbildning för de som inte varit med i projektet (Koch, 2005).
Det finns förutom de fem faserna enligt Systemvaruhuset (2011c) och Koch (2005) också nio grundprinciper med DSDM. Det är också de principerna som definierar vilken påverkan metoden har på företaget som använder sig av den.
Eftersom syftet med DSDM är att utveckla utefter vad kunden ska använda systemet till blir också involveringen med användarna viktig. Om användarna får vara med i utvecklingen redan från början kan de också komma med synpunkter på vad de tycker är viktigt med systemet för att det ska passa dem så bra som möjligt då det faktiskt är de som ska använda det i slutändan.
17 En beslutsmässig projektgrupp, projektteamet, har rätt att ta beslut om dagliga problem som uppkommer vad gäller utvecklingen för att få arbetet att flyta. Uppstår det större problem, som t.ex. att kostnaderna stiger, måste ledningen kontaktas.
Det måste levereras produkter som visar att arbetet går framåt genom täta leveranser.
Produkterna kan vara i form av specifikationer, prototyper, designdokument, etc.
Det huvudsakliga kriteriet för acceptans är affärsnytta som fås genom att sätta uppgiftens lämplighet före kravens belåtenhet och genom att konstant involvera användarna är det bara slutanvändarna som kan säga om systemet utvecklas som önskat.
Vid inkrementell utveckling tillfrågas användarna vid varje del som görs om de godkänner det som gjorts. Eftersom det inte finns en exakt utstakad väg för att nå resultatet på måste
utvecklarna hela tiden testa och göra om för att få projektet att bli lyckat, det blir på så sätt en iterativ process.
Förändringar under utvecklingen skall vara vändbara. Det kommer att uppstå fel då och då under utvecklingen och den här principen gör att det går att ta bort felaktigt arbete om det behövs för att göra om en uppgift helt.
Principen med att övergripande krav fryses gör att DSDM skiljer sig från andra agila metoder.
Genom att frysa kraven vid en viss nivå, skapas en stabil bas för arbetet av intressenterna.
Kraven kan ändras även om det är viktigt att se till att alla intressenter förstår och godkänner dem.
Testning är en integrerad del i livscykeln och inte ett eget steg då det görs under hela utvecklingen. Liksom vid andra agila metoder har teamets alla medlemmar en stark medvetenhet om kvalitet. Varje uppgift ska innehålla verifikation och validitet i form av återkoppling eller test av en annan teammedlem eller användare.
En samarbetsvillig och positiv attityd från alla inblandade är nödvändig eftersom alla
intressenter måste acceptera DSDM och deras roller så som de är definierade för att metoden ska kunna användas. Om någon intressent inte håller med fungerar det inte att använda metoden.
Det finns tre grundläggande saker som projektledaren kan påverka projektet med. Det är systemets funktionalitet, tiden och de resurser som tilldelats projektet. Vid DSDM fryses tiden och resurserna för att istället justera funktionaliteten, vilket gör att projektet kommer att levereras på det utlovade datumet och till den kostnad som bestämts, men med ett annorlunda innehåll än vad som bestämts från början. Benämningen på det här arbetssättet är time-
boxing. En time-box är ofta väldigt kort och genomgår under den här tiden fem olika faser;
kick-off, planering och kravanalys, utveckling, konsolidering och avslutning. Ungefär 70 % av den här tiden går till utveckling och resterande 30 % fördelas mellan planeringsarbetet och förbättringen av resultatet (Systemvaruhuset 2011c).
18
4. Empiri
Jag har utfört intervjuer med tre av de anställda på företaget PromoSoft. Jag har valt att göra en sammanfattning på svaren jag fått på de frågor jag ställt. Anledningen till att jag valt att redovisa svaren på det här sättet är för att jag hittat en röd tråd i svaren. För att det ska bli lättare för läsaren att följa den röda tråden från empiri till analys har jag sammanfattat svaren utefter de frågeställningar och det syfte jag har med uppsatsen.
Alla frågor som utvecklingschefen svarade på har tagits med i sammanfattningen, bilaga 1, då jag genom dem dels fick en bra beskrivning av företagets arbetssätt med Kanban och dels fick bra svar på de frågeställningar jag hade. Jag har däremot valt att inte redovisa vissa svar på frågorna i bilaga 2 om de stämde överens med vad som framkommit i den första intervjun. Jag har heller inte redovisat vissa av svaren om jag funnit dem irrelevanta för syftet med
rapporten.
4.1. Presentation av medverkande verksamhet
PromoSoft är ett mjukvaruutvecklingsföretag med fem anställda som finns beläget i Partille.
Deras verksamhet inriktar sig mot IT-baserade affärsprocesser för affärskedjor och grossister.
Företaget har tidigare använt sig av en egen variant av metoden Scrum som projektmetod, men kände att den här metoden inte riktigt passade in så bra på sin verksamhet då de inte arbetade iterativt. När några av utvecklarna var på en föreläsning om Kanban tyckte de att den här metoden skulle passa in mer på företagets verksamhet än vad den befintliga metoden gjorde. PromoSoft har använt sig av Kanban sedan sommaren 2010.
Tillvägagångssättet vid ett projekt börjar med att kunden skriver beskrivningar där de förklarar vad de vill att systemet ska göra och varför. Det görs med korta meningar, user story, som ser ut på följande sätt: Jag vill att… för att …
Utvecklarna på PromoSoft gör sedan en tidsbedömning på hur lång tid arbetet kommer att ta.
Om kunden accepterar det och vill fortsätta samarbetet med PromoSoft görs en analys, det vill säga att ett lösningsförslag tas fram där kunden är involverad och bestämmer vad som ska vara med. De funktioner som ska finnas i systemet ska vara satta under analysen.
När det här arbetet är helt klart tar PromoSoft över och utvecklingen påbörjas. Det ska nu vara helt klart vad som ska finnas med och hur det ska göras. Det kan dock vara småsaker som utvecklarna kan behöva få svar på i efterhand. PromoSoft är även flexibla om det är så att en kund vill ändra något eller göra om något på ett annat sätt. Kunden bör då vara medveten om att tiden på projektet förlängs.
4.2. Kanban som projektstyrningsmetod
Tanken med att arbeta med Kanban är att bli effektivare genom att fokusera på att avsluta påbörjat arbete. Kanban, som ju betyder ”visuellt kort”, har implementerats hos PromoSoft i form av Post-it lappar som sätts upp på en White board och som beskriver det arbete som ska utföras. Ett exempel på vad som kan stå på korten kan vara en utvecklingspunkt. Att en White
19 board har valts till ändamålet är för att processen ska vara lätt att förändra. Det ska vara lätt att bara gå till tavlan och flytta på lapparna eller skriva ny information på dem.
Kortet flyttas från vänster till höger mellan olika steg i utvecklingsprocessen. Stegen är;
Analys, Utveckling, Systemtest, Acceptanstest och Driftsättning. I varje kolumn får det max sitta ett visst antal lappar, den här begränsningen, som kallas Work-in-Progress limit (WIP- limit), gör så att det inte påbörjas ett nytt arbete utan att något annat har avslutats. För att komma fram till rätt gräns för just PromoSoft har de testat sig fram och tycker att de nu har funnit en bra sådan.
Det går att växla mellan punkter och arbeta med olika saker. Det är högre prioritet på vissa uppgifter och ringer det en kund som måste ha något gjort med en gång ber de inte denne att vänta utan löser problemet åt kunden direkt för att sedan gå tillbaka till att arbeta med den uppgift som hade påbörjats innan. Det går att göra två saker parallellt bara båda sakerna blir färdiga. Det här görs dock bara vid specialfall. Oftast gör de färdigt det de håller på med, men om det är så att det behövs ett svar från kunden för att komma vidare sätts det upp en röd punkt, i form av en magnet, på post-it lappen som betyder att utvecklaren väntar på svar. När svaret sedan kommer prioriteras den här punkten. Det skrivs också datum på lappen för att det ska vara möjligt att se hur mycket tid som går till att vänta. Om ett arbete är beroende av ett annat sätts det också upp en röd punkt, eftersom det också innebär en väntan. Genom att flytta lappen från en kolumn till en annan syns det att problemet är löst.
Om de själva skulle upptäcka buggar i systemet är det inte säkert att de rättas. Det är bara om kunden upptäcker en bugg eller om de ser att det kommer att bli problem för kunden som de rättas. Anledningen till att de arbetar på det här sättet är för att inte lägga ner onödig tid på sådant som inte stör själva användandet av systemet. Innan de släpper nya versioner görs ett systemtest där eventuella buggar hittas. Om buggarna anses vara allvarliga fel rättas de. En bugg sitter också på tavlan som en uppgift. Så var det inte innan när de använde sig av Scrum.
Då lades buggen in i deras ärendehanteringssystem och kollades det inte regelbundet kunde det vara så att uppgifterna försvann och buggen aldrig blev rättad. Genom att den nu sitter på tavlan måste ett val göras. Ska den inte rättas blir det en aktiv handling då lappen måste tas bort och kastas. Genom att göra på det här sättet säkerställs att det som måste rättas också kommer att rättas.
Kanban används inte bara till att effektivisera arbetet utan även till att öka kvaliteten. För varje kolumn finns vissa klarkriterier som måste uppnås innan ärendet får flyttas vidare.
Kriterierna gäller oavsett storlek på uppgift. Små uppgifter är minst lika viktiga som stora uppgifter. Klarkriterierna bidrar till att kodgranskning alltid blir gjort, men de kan också bidra till att enhetstester skrivs i de fall där det är möjligt. Alla tester som någonsin gjorts körs varje natt för alla versioner som finns i drift för att säkerställa kvaliteten på koden.
20
4.3. Stöd för planering och information
Vid planeringen av ett projekt görs en stor projektplan i Excel. I Exceldokumentet går det att göra en uträkning på hur lång tid projektet kommer att ta utifrån de resurser som finns tillgängliga.
En av fördelarna med Kanban är att det ger en bra visuell överblick över vad som ska göras.
Det gäller speciellt utvecklingsprojekten. Det är svårare att få in andra typer av projekt i Kanban-flödet, som t.ex. supportprojekt och inplanerade tider för vissa delprojekt/personer.
Det går att snabbt gå in och titta på detaljer i ett visst projekt, vilket gör att det blir till ett stöd då en prioritering av uppgifterna ska göras. De prioriterade uppgifterna väljs ut av alla
utvecklarna tillsammans. Ett krav är att kunden ska prioritera allt som de vill ha gjort för att det sedan ska bli lättare att själva göra en prioritering.
Vid de implementationsprojekt där kunden väljer en befintlig version av det
lagerstyrningssystem som PromoSoft säljer till sina kunder går det att ge en exakt leveranstid på då de ser likadana ut. Det är svårare med utvecklingsprojekten där kunden vill ha fler funktioner än vad som redan finns i systemet.
Alla utvecklare på företaget hjälps åt mer nu än tidigare när de arbetade med Scrum. Nu kan de också få med alla kunder i ett flöde eftersom de hjälps åt att avsluta saker om WIP- nivåerna är uppnådda. Även om det är ett arbete som en viss person är ansvarig för, kan en annan ta den här punkten om det är den som är nästa punkt i kön. Att hjälpas åt är speciellt viktigt när det uppstår flaskhalsar, vilket syns tydligt med Kanban då alla lappar samlas på ett ställe. Leveranstiden utjämnas i och med att de arbetar på det här sättet. Tidigare kunde ett projekt ta lång tid på grund av att den som arbetade med det hade mycket att göra eller kanske jobbade 50 %, men ett annat under samma tidsperiod kunde gå fort då den här personen inte hade så mycket att göra. Nu kan den som har lite att göra hjälpa den som har mycket att göra för att uppnå WIP-nivån. Alla projekt finns nu i samma flöde och det är lätt att hitta
problemen.
Den återkoppling som fås från kunderna är mestadels att de ringer och frågar när det är färdigt. Det är senare under själva förvaltningen som det kan komma feedback från kunderna på vad som skulle kunna förbättras i systemet eller om det är något som saknas. Vissa ger mycket och andra mindre. Alla synpunkter skrivs upp i en lista som gås igenom med jämna mellanrum för att se om det är något av det som är aktuellt att utveckla till nästa version.
Det går nu att mäta antalet avslutade projekt och det blir en klar bild över vad alla gjort.
Tidigare hade företaget ingen uppföljning på avslutade projekt. I och med Kanban-metoden är det nu mer fokus på att avsluta saker, vilket de också anser att de gör. I och med att
flaskhalsar blir mer uppenbara och att utvecklarna själva blivit bättre på att avgränsa uppgifterna bidrar det till att vissa saker avslutas snabbare.
Metoden bidrar också till att inget arbete lämnas halvfärdigt. Om en utvecklare börjar arbeta på en punkt som inte är så viktig, högprioriterad, så riskerar det arbetet att hamna på is för att
21 sedan glömmas bort. Med Kanban måste lappen fysiskt plockas bort, vilket oftast leder till att arbetet fortsätter med den här punkten tills den blir färdig.
4.4. Brister och problem med metoden
En nackdel som PromoSoft ser med Kanban är att metoden inte visar generella delar. Det går inte att se vad som hör till vilket projekt, inte heller hur hela projektet går. Den övergripande projektplaneringen måste de ha bredvid. Det hade varit bra om den här planeringen också kunde ha varit visuell på samma sätt som Kanban är. Det skulle då ha varit lättare att se hur de olika projekten går i jämförelse till varandra.
Det är svårt att ge kunden en ungefärlig leveranstid. Det beror på om det är ett stort utvecklingsprojekt eller ett avgränsat projekt som kanske bara tar en dag. Vid de större projekten hjälper inte Kanban till med att kunna bestämma en ungefärlig leveranstid, men vid ett litet projekt kan en ungefärlig leveranstid ges genom att titta på historik från andra
liknande projekt. Det är dock svårt att ge en exakt leveranstid eftersom det bland annat beror på kö-tider och nuvarande beläggning hur lång tid det kommer ta att färdigställa projektet.
Problem som kan finnas visas genom att någon sitter länge på en punkt, men det är också upp till de anställda att berätta om de har några problem. Det är lätt att se flaskhalsar genom att se om något samlas på kanban-tavlan. Fokus blir då att lösa det och arbeta med de punkter som finns i just den här kolumnen. Förr upptäcktes flaskhalsarna om det tog lång tid för någon.
Det var tiden som gjorde att problemet upptäcktes och på så sätt kunde flaskhalsarna upptäckas. Med Kanban blir det ett tydligare sätt att se vart problemen är och att de får en lösning genom att flytta uppgiften till nästa kolumn.
Ett problem är de röda punkterna, som ju betyder att ett svar från kunden behövs eller att uppgiften är beroende av en annan som måste bli klar först. Då en uppgift fått en röd punkt räknas de inte med i kolumnerna. Utvecklarna arbetar då med annat och kan ta in nya punkter i kolumnen trots att den röda punkten finns där. Det här blir till ett problem då den röda punkten tas bort och uppgiften nu blir prioriterad. Eftersom nya uppgifter tagits in i kolumnen blir det lätt fler uppgifter än vad den satta gränsen för kolumnen är. Det gör att det bildas en flaskhals som ju måste arbetas bort.
Det kan också finnas problem om det finns inplanerade mötestider för vissa personer på vissa tider, som inte kan göras av någon annan person. Det kan vara så att den här personen håller på att arbeta med en utvecklingspunkt, men måste avbryta arbetet för ett möte eller ibland en aktivitet som kan ta flera dagar. Det här gör att utvecklingspunkten blir hängande i luften och blir till en flaskhals i Kanban-flödet. Utvecklarna tycker att de kan hantera det här, men det beror snarare på interna rutiner än genom strikt Kanbanprocess.
4.5. Komplettering med andra metoder
PromoSoft har valt att komplettera Kanban med det som de anser är det bästa för dem från Scrum, vilket är morgonmöten, Burndown-grafer och prioriteringslistor.
22 På morgonmötena samlas alla utvecklarna vid White board-tavlan för att gå igenom vad som ska göras och vilka problem som stötts på. De behöver inte längre berätta om vad de gjort sedan igår eller vad de ska göra tills i morgon då det syns tydligt på tavlan. Eftersom allt som ska göras redan finns tillgängligt visuellt blir det nästan bara att nöta problem på mötena vilket de tycker är lite trist.
Burndown-grafen från Scrum används för att se grafiskt hur projektet löper i nuläget.
Par-programmering har utvecklarna provat på och gör också ibland när de hjälper varandra.
De har dock inte provat att arbeta på det här sättet fullt ut. Om det skulle löna sig att arbeta med par-programmering hela tiden beror på hur mycket effektivare det skulle bli. En
svårighet med par-programmering är hur debiteringen till kunden skulle bli eftersom de anser att det skulle vara svårt att motivera att ta betalt för två personer som i kundens ögon gör samma sak. Kodgranskningen sker däremot tillsammans på PromoSoft.
Om det blir fler anställda på PromoSoft tror Fredrik att det skulle fungera med att fortfarande använda sig av Kanban-metoden. Det skulle troligtvis gå att använda samma nivåer som används idag upp till 10 personer. Par-programmering skulle då bli möjligt vilket ses som en positiv sak. Blir det fler än tio anställda skulle antagligen de olika områdena delas upp. Några kanske skulle arbeta med analys, några med test, osv. Nivåerna på de olika kolumnerna skulle då kanske komma att ändras.
