9789197621717 by Smakprov Media AB

Tomas Gustavsson

AGILE

- konsten att slutfรถra projekt

ร rets Projektledarbok 2008

Tidigare utgivna böcker av TUK Förlag AB: Ledarskapsdagbok – Boken för din utveckling (2006)

Kopieringsförbud Detta verk är skyddat av upphovsrättslagen. Kopiering är förbjuden utöver vad som anges i kopieringsavtal. Den som bryter mot lagen om upphovsrätt kan åtalas av allmän åklagare och dömas till böter eller fängelse i upp till två år samt bli skyldig att erlägga ersättning till upphovsman/rättsinnehavare.

Författare Tomas Gustavsson 2007 TUK Förlag AB Östra Kanalgatan 10 652 20 KARLSTAD www.tuk.se Tryckeri Scandbook AB Typsättning Advant Produktion AB Andra tryckningen ISBN 978-91-976217-1-7

kapitel 2. Vad är Agile?

2.5. Varför kort tid mellan leveranserna? Att arbeta i projekt och leverera resultat är svårt. En projektledare har en tuff uppgift att genomföra med en grupp av människor som kanske inte har samarbetat tidigare och har ont om tid för att bli en presterande arbetsenhet. Och ännu svårare blir det om projektmedlemmarna sitter på olika platser i världen. Projektledare klagar ofta över hur svårt det är att verkligen få en insikt i hur projektet ligger till. Att försöka detaljgranska allt som görs och kika över axeln på projektdeltagarna är inte särskilt givande för moralen eller projektledarens förtroende så vad kan projektledaren göra? Jo, projektledaren kan kräva täta leveranser istället. Vinsten med korta tidsrymder mellan varje leverans ligger i kontroll. Såväl projektledaren som gruppen kan hela tiden se resultatet av sitt arbete genom att ett resultat verkligen levereras. Det ger även kunden en chans att se hur det blir på ”riktigt” jämfört med att bara titta på en prototyp. Det ger dessutom en trygghet för hela projektgruppen då det innebär ett bevis för att den planerade designen, arkitekturen eller tänkta strukturen håller. Förändringar av planer kan enklare genomföras med ett konkret delresultat än med halvfärdiga aktiviteter då projektledaren inte lika tydligt kan se var projektet befinner sig. Om vi är mitt inne i en analysfas där vi detaljerar arbetet för samtliga aktiviteter i ett projekt och en beställare ställer frågan ”hur mycket tid missar vi om vi ändrar på det här kravet?” så blir det väldigt svårt att svara på. I röran av alla parallella krav som behöver redas ut blir svaret svårt att precisera. Om vi däremot levererar 10 procent av den slutgiltiga produkten varje månadsskifte och samma fråga ställs när vi detaljanalyserar ett av kraven så kan vi ställa förändringen i förhållande till kraven inom de 10 procenten istället för att försöka ställa den mot 100 procent, alltså hela projektet.

kapitel 2. Vad är Agile?

Som erfaren projektledare kan man självklart ställa sig frågan: ”Blir det inte mycket extra kostnader (så kallade overhead-kostnader) om projektgruppen måste produktionssätta sitt resultat flera gånger

kapitel 2. Vad är Agile?

jämfört med att bara göra det en gång, då?” Jo, tyvärr finns det risk att denna overhead-kostnad ökar men den risken måste ställas mot fördelen av att kunna styra om projektet i tid. Dessutom är det inte självklart att tiden för att färdigställa projektresultatet för leverans blir längre bara för att det görs fler gånger. För att exemplifiera vad jag menar vill jag lyfta fram däcksbyte på bilen. Jag vet inte vad du har för inställning till att byta från sommar- till vinterdäck och vice versa men jag gillar det inte. Att endast två gånger per år leta rätt på fälgkors, muttrar, smörjolja till bultarna och domkraft till bilen känns som ett jobbigt projekt varje gång det händer. Första halvtimman brukar gå åt till att bara hitta rätt saker. När jag sedan skall lossa på de halvt fastrostade bultarna behöver jag ofta leta vidare efter en järnstång för att förlänga armen och få mer kraft. Allt som allt brukar ett däcksbyte ta åtminstone en timma för mig. Varför tar det då sådan tid? Naturligtvis för att jag gör detta så sällan. Tänk om jag skulle behöva byta däck varje dag? Då skulle jag: Direkt veta var jag hittar rätt saker Effektivisera bort vissa moment (järnstången som jag använde för att bultarna rostat fast) Skaffa bättre utrustning eftersom jag vet att detta är något som behöver göras ofta (skruvdragare med lufttryck istället för fälgkorset, exempelvis) Exemplet visar på skillnaden mellan projekt och process. En kritik som projektarbetsformen ibland får av processorienterade individer är att allt utförs så ineffektivt i projekt just för att saker ofta utförs ”första gången”. De processorienterades karta består av att försöka ”processifiera” aktiviteter för att därigenom få ökad effektivitet.

kapitel 2. Vad är Agile?

Ett projekt som levererar sina resultat vid två eller tre tillfällen kommer att behöva lång tid för att slutföra varje leverans. Ett projekt som levererar varje månad eller varje vecka kommer att finna rätt rutiner för att snabbt och effektivt kunna leverera utan att uppleva operationen som särskilt betungande. Jag har själv upplevt, och varit delaktig i, att slopa delleveranser på grund av den extra arbetsbörda som leveransen kommer att innebära när antalet delleveranser varit få under projektet. Summa summarum: ett projekt som levererar tio gånger behöver inte ha högre kostnader för produktionssättning än ett projekt som levererar två gånger eftersom varje leverans är liten och inte särskilt betungande samt att rutinen av att leverera kommer att innebära att varje leverans sker snabbt, effektivt och med hög kvalitet.

2.5.1. Halvtidsteoremet – hur fem veckors ”Allt OK!” blir flera veckors försening Tidigare påpekade jag att ett grundläggande synsätt inom agila metoder är att etapper skall vara korta och leveranserna täta. En anledning till etappens korta längd baseras på det som kallas ”halvtidsteoremet” (en synnerligen kreativt påhittad term av Per-Eric Haraldsson, föreläsare på Projektledningsprogrammet på Karlstads universitet). Halvtidsteoremet är inte så konstigt att förstå om du funderar över hur människor fungerar i vanliga situationer. Låt oss säga att du får en deadline för att utföra någonting av din projektledare, exempelvis att skriva ihop en kort rapport. Du får denna uppgift på måndagen den första i månaden och rapporten förväntas vara klar den 30:e i nästa månad. (Det är alltså två månaders ledtid för den här aktiviteten.) Du uppskattar arbetsbördan till ungefär 50 timmar för att skriva och färdigställa

kapitel 2. Vad är Agile?

rapporten och du har därför gott om tid att bli klar. Eftersom du är en skötsam och strukturerad människa lägger du lite tid varje dag på att söka efter information, skriva stödnoteringar och strukturera rapporten. Men det är lång tid kvar till deadline så det finns ju ingen anledning att stressa. Du skriver då och då i din rapport under

kapitel 2. Vad är Agile?

de följande veckorna och tycker att arbetet flyter på bra. Men det är inte förrän under de två sista veckorna som du verkligen inser helheten i arbetet och det känns stressande! Du upptäcker att du arbetat för få timmar hittills och lägger därför all din tid under den sista tiden för att bli fullständigt klar med rapporten. I värsta fall kanske du jobbar över några dagar under den sista veckan för att verkligen få till alla detaljer. Det är här inget ovanligt scenario så låt oss belysa det ur en projektledares perspektiv. Säg att en projektledare har delat ut precis samma uppgift till tio personer och genomför en avstämning halvvägs. Om alla varit lika skötsamma som du kommer de efter den första månaden att rapportera att ”jo, jag har genomfört halva jobbet och kommer att leverera mitt arbete i tid”. När sedan samma projektledare gör samma avstämning när uppgifterna är levererade (efter ytterligare en månad) kommer projektet att skjutit en hel del över budget eftersom samtliga har jobbat övertid under sista veckan för att färdigställa sitt arbete. Projektledaren kliar sig i huvudet och tänker ”men, det var ju ingen som rapporterade några problem vid halvtidsavstämningen?” Problemet är följande: vi producerar och jobbar alltid mer under den andra halvan av en planerad tidsperiod för att färdigställa vårt arbete. Ken Schwaber, en av grundarna av den agila metoden Scrum (se referenslistan) lyfter fram flera exempel på hur detta halvtidsteorem gör att många projektledare och projektdeltagare känner frustration över att ”nu blev det försenat igen; att vi aldrig kan lära oss av vad som gick snett och lyckas bättre nästa gång”.

kapitel 2. Vad är Agile?

De flesta projekt har en lugn start och blir alltså stressigare för varje dag som projektet närmar sig leverans. Så hur får vi bukt med det problemet? Går det att få bukt med problemet? Svaret är ja, det går att lösa det här problemet. Genom att göra alla tidsuppskattningar kortare och avstämningar oftare så att vi inte behöver få en enda stor puckel av arbete i slutet av vårt projekt. Istället för att få en kultur av att ”det är inte leverans förrän om 6 månader så vi kan ta det lugnt än så länge” eller ”vi stämmer av halvvägs och ser vartåt det lutar” så kommer projektgruppen in i ett tankesätt av att det är uppföljning och leverans hela tiden och att leveransen inte är något som sker långt bort i fjärran. Genom att dela in vårt projekt i etapper kan vi dessutom få en jämnare arbetsfördelning mellan projektdeltagare (som skapar ett projektresultat) och kunden som skall acceptanstesta. Istället för att få ett jättejobb på slutet, då kunden förväntas testa av all funktionalitet, får kunden möjlighet att testa delfunktionalitet vid många tillfällen under hela projekt. Etapperna kommer därför att ske så ofta som med en månad eller några veckors mellanrum och mellan dessa etapper stämmer vi som projektledare av dagligen för att inte behöva få obehagliga överraskningar i slutet av vårt projekt.

kapitel 11. Referenser

Tomas Gustavsson driver företaget TUK Förlag AB och håller föreläsningar för projektledningsprogrammet vid Karlstads universitet. Tomas är certifierad ScrumMaster.

Agile är engelska och betyder smidig eller vig. I projektledningssammanhang har ordet översatts till ”lättrörlig” för att peka på förändringsmöjligheterna med detta synsätt. Men det finns andra fördelar med Agile. Den, i mitt tycke, största fördelen består i möjligheten i att kunna slutföra projekt. Att slutföra projekt är en konstart som många eftersträvar men få behärskar. De agila teknikernas lösning för att hantera denna konst är att delleverera små resultat ofta. Genom att planera, genomföra och leverera en mindre del av projektet får vi möjlighet att uppleva en del av slutresultatet tidigt och kan därefter ställa konkretare krav på resten av projektet. Vi kan dessutom stanna upp, utvärdera och enkelt förändra projektet under vägen. Metoderna (med namn såsom Scrum, XP, DSDM) härstammar från IT-projekt men går att appliceras på många projekt oavsett bransch eller miljö. Detta är en praktisk bok! Med praktisk bok menas att den innehåller de checklistor, mallar och verktyg som krävs för att med boken som stöd kunna börja arbeta agilt.

Förlag AB 2007