Måste det bli dygnet-runt-arbete i slutet av projekt, och måste man som projektledare helt enkelt räkna med att uppfattas som en slavdrivare? Går det att lägga upp ett projekt så att det ger nytta omgående, och så att kunden kan ändra sina krav utan att det innebär bortslösat arbete och irritation? AGIL betyder smidig och är benämningen på ett arbetssätt som vuxit
fram i it-branschen och på senare år fått fäste i allt fler branscher. Många företag vittnar om större engagemang och effektivare projekt sedan man infört en agil syn på planering, förändring, ledarskap och kommunikation. AGIL PROJEKTLEDNING ger både den teoretiska stommen och praktiska
tillämpningen av de agila metoderna. Kärnvärden och tankesätt som ligger till grund för det agila projektarbetet beskrivs utförligt och varvas med konkreta exempel, tillvägagångssätt och verktyg.
Tomas Gustavsson undervisar i projektledning vid Karlstads universitet, är certifierad scrum master och har arbetat med agila metoder sedan 2002. Hans förra bok utsågs till Årets projektledarbok av Svenskt Projektforum.
Agil projektledning Tomas Gustavsson
VARFÖR blir så många projekt både längre och dyrare än planerat?
Agil projektledning
ISBN 978-91-523-0936-0
www.sanomautbildning.se
Tomas Gustavsson
Agil projektledning Tomas Gustavsson Sanoma Utbildning
Det är inte den här boken som kommer göra dig till en agil projektledare.
Sanoma Utbildning Postadress: Box 3159, 103 63 Stockholm Besöksadress: Sveavägen 56, Stockholm. Hemsida: www.sanomautbildning.se, www.ekonomionline.se E-post: info@sanomautbildning.se
Du läste rätt. Att vara agil innebär nämligen att varje dag prova, utvärdera och förbättra sitt arbetssätt – och endast det egna genomförandet kan få dig att bli en lyckad agil projektledare. Däremot lovar jag att den här boken, genom tips, råd och övningar, kan bli ett bra stöd om du har modet och viljan att förändra de projekt du leder eller den verksamhet du ansvarar för. Här kommer du kunna få såväl inspiration som praktisk vägledning på resan mot att bli en projektledare för mer effektiva, stressfria och flexibla projekt. För dig som är nyfiken på filosofin och tankegångarna bakom det agila arbetssättet hoppas jag också att boken skall vara en gedigen grund. Tack alla ni som stött och blött, diskuterat och filosoferat kring innehållet i den här boken med mig! Ett särskilt tack till min kompanjon John Johansson som alltid har förmågan att vända på perspektiven och ifrågasätta det självklara. Kollegorna på huvudområdet Projektledning på Karlstads universitet är också värda ett extra stort tack. Naturligtvis vill jag också tacka dig, kära läsare, för att du vill fördjupa dig inom detta område som ligger mig så nära. Jag önskar dig trevlig läsning och ber dig att kontakta mig om du vill diskutera vad jag har skrivit.
Order/Läromedelsinformation Telefon 08-696 86 00, telefax 08-696 86 10 Redaktör/Projektledare: Agnes Junker Grafisk form: Anna-Karin Nilsson och Filip Rensfelt Agil projektledning ISBN 978-91-523-0936-0 ©2011 Tomas Gustavsson och Sanoma Utbildning AB, Stockholm Första upplagan. Första tryckningen Kopieringsförbud! Detta verk är skyddat av lagen om upphovsrätt. Kopiering utöver lärares rätt att kopiera för undervisningsbruk enligt Bonus-Presskopias avtal, är förbjuden. Sådant avtal tecknas mellan upphovsrättsorganisationer och huvudman för utbildningsanordnare, t.ex. kommuner/universitet. För information om avtalet hänvisas till utbildningsanordnares huvudman eller Bonus-Presskopia. 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. Printed in Latvia by Livonia Print Riga 2011
Tomas Gustavsson, september 2011
Innehåll Kapitel 1. Vad är agil projektledning? 7 Vad ger agil projektledning? 9 Den agila synen på tid och resultat 13 Faser i agila projekt 17 Sammanfattning 21 Kapitel 2. Det agila manifestet och metodernas historia 23 Projektledningens historia 25 Lean 26 De agila metoderna växer fram 29 Det agila manifestet 32 De 12 agila principerna 36 Sammanfattning 39 Kapitel 3. Roller 41 Gruppen 43 Projektledare och scrum master 47 Produktägaren 56 Styrgruppen 62 Referensgruppen 66 Leverantörer 66 Sammanfattning 68 Övningar 69 Kapitel 4. Förstudien 71 Ofta förbisedd, ej försumbar 73 Förstudiens frågor 75 Intressentanalys 76 Visionen 81 Planera kommunikationen 84 Workshop 88 Sammanfattning 90 Övningar 91
4
Kapitel 1
Kapitel 5. Planering 93 Planering på kort eller lång sikt 95 Färdplan 97 Leveransplan 102 Etapplan 103 Produktlogg 106 Etapplogg 110 Tidsuppskattning 115 Sammanfattning 124 Övningar 125
Kapitel 9. Mallar och checklistor 191 Dokument till stöd 193 Checklista – Passar agil projektledning? 194 Checklista – Frågor att ställa sig 195 Checklista – Produktägare 196 Checklista – Komma igång med agil projektledning 197 Mall – Färdplan 198 Mall – Leveransplan 199 Mall – Etapplan 200 Mall – Produktlog 201
Kapitel 6. Genomförande 127 Projekttavla 129 Stå-upp-möte 134 Presentation vid etappslut 141 Erfarenhetsmöte 143 Löpande riskhantering 145 Praktikaliteter 148 Sammanfattning 155 Övningar 156
Kapitel 10. Projektledare berättar 203 Sven på ett it-konsultföretag 205 Elin som driver evenemangsprojekt 208 Peter som jobbar på ett call center 212 Sammanfattning 215 Litteraturförteckning 217 Bildförteckning 219 Sakregister 220
Kapitel 7. Avsluta projekt 159 Att avsluta agila projekt 161 Att överlämna eller inte – det är frågan 164 Projektavslut 167 Sammanfattning 169 Övningar 169 Kapitel 8. När passar agila metoder? 171 Goda förutsättningar för agila projekt 173 Sämre förutsättningar för agila metoder 175 Agila metoder i stora projekt 178 Kulturen krossar 180 Lämpliga projekttyper 184 Arbete på distans 186 Sammanfattning 189
www.sanomautbildning.se/agil Agil projektledning har en hemsida med presentationsmaterial, mallar och checklistor som stöd till lärare, studenter, projektledare och projektgrupper.
5
Innehåll Kapitel 1. Vad är agil projektledning? 7 Vad ger agil projektledning? 9 Den agila synen på tid och resultat 13 Faser i agila projekt 17 Sammanfattning 21 Kapitel 2. Det agila manifestet och metodernas historia 23 Projektledningens historia 25 Lean 26 De agila metoderna växer fram 29 Det agila manifestet 32 De 12 agila principerna 36 Sammanfattning 39 Kapitel 3. Roller 41 Gruppen 43 Projektledare och scrum master 47 Produktägaren 56 Styrgruppen 62 Referensgruppen 66 Leverantörer 66 Sammanfattning 68 Övningar 69 Kapitel 4. Förstudien 71 Ofta förbisedd, ej försumbar 73 Förstudiens frågor 75 Intressentanalys 76 Visionen 81 Planera kommunikationen 84 Workshop 88 Sammanfattning 90 Övningar 91
4
Kapitel 1
Kapitel 5. Planering 93 Planering på kort eller lång sikt 95 Färdplan 97 Leveransplan 102 Etapplan 103 Produktlogg 106 Etapplogg 110 Tidsuppskattning 115 Sammanfattning 124 Övningar 125
Kapitel 9. Mallar och checklistor 191 Dokument till stöd 193 Checklista – Passar agil projektledning? 194 Checklista – Frågor att ställa sig 195 Checklista – Produktägare 196 Checklista – Komma igång med agil projektledning 197 Mall – Färdplan 198 Mall – Leveransplan 199 Mall – Etapplan 200 Mall – Produktlog 201
Kapitel 6. Genomförande 127 Projekttavla 129 Stå-upp-möte 134 Presentation vid etappslut 141 Erfarenhetsmöte 143 Löpande riskhantering 145 Praktikaliteter 148 Sammanfattning 155 Övningar 156
Kapitel 10. Projektledare berättar 203 Sven på ett it-konsultföretag 205 Elin som driver evenemangsprojekt 208 Peter som jobbar på ett call center 212 Sammanfattning 215 Litteraturförteckning 217 Bildförteckning 219 Sakregister 220
Kapitel 7. Avsluta projekt 159 Att avsluta agila projekt 161 Att överlämna eller inte – det är frågan 164 Projektavslut 167 Sammanfattning 169 Övningar 169 Kapitel 8. När passar agila metoder? 171 Goda förutsättningar för agila projekt 173 Sämre förutsättningar för agila metoder 175 Agila metoder i stora projekt 178 Kulturen krossar 180 Lämpliga projekttyper 184 Arbete på distans 186 Sammanfattning 189
www.sanomautbildning.se/agil Agil projektledning har en hemsida med presentationsmaterial, mallar och checklistor som stöd till lärare, studenter, projektledare och projektgrupper.
5
Processen för genomförande i agila projekt innebär en transparent, ständigt föränderlig verksamhet. Med transparent menas här att man hela tiden visar var projektet befinner sig i förhållande till planen. Verktygen som används kan liknas vid de mätare och monitorer som finns i en flygplanscockpit – de finns till för att hela tiden visa exakt hur projektet går. Processen fokuserar dessutom på slutförande. Varje kort etapp handlar om att detaljplanera, genomföra och ibland överlämna en del av projektet till en mottagande part, för att sedan reflektera över möjligheter till förbättring.
Projekttavla Dagligt stå-upp-möte 24 timmar
Produktlogg
Etapplogg
Erfarenhetsmöte och demonstration av etappresultat
Genomförandeprocessen i agila projekt.
Agila metoder lyfter fram två områden avseende genomförande av projekt. Det ena området är processen som beskriver hur vi ska arbeta dag för dag. Det andra området rör praktiska frågor för effektivare projektarbete, här benämnAlltför mycket stabilitet da praktikaliteter, som berörs i kapitlets förhindrar framsteg. senare del. (Harold Wilkinsson) Det viktigaste och tydligaste verktyget för den dagliga arbetsprocessen i projektet är projekttavlan. Den kan utgöras av en stor whiteboard, en tygtavla att sätta nålar i eller en vanlig vägg som tapetserats med blädderblocksblad eller plast. Projekttavlan ger en bild av projektets status och den brukar innehålla följande tre kolumner: Ej påbörjat Påbörjat Klart
128
Kapitel 6
Genomförande
129
Processen för genomförande i agila projekt innebär en transparent, ständigt föränderlig verksamhet. Med transparent menas här att man hela tiden visar var projektet befinner sig i förhållande till planen. Verktygen som används kan liknas vid de mätare och monitorer som finns i en flygplanscockpit – de finns till för att hela tiden visa exakt hur projektet går. Processen fokuserar dessutom på slutförande. Varje kort etapp handlar om att detaljplanera, genomföra och ibland överlämna en del av projektet till en mottagande part, för att sedan reflektera över möjligheter till förbättring.
Projekttavla Dagligt stå-upp-möte 24 timmar
Produktlogg
Etapplogg
Erfarenhetsmöte och demonstration av etappresultat
Genomförandeprocessen i agila projekt.
Agila metoder lyfter fram två områden avseende genomförande av projekt. Det ena området är processen som beskriver hur vi ska arbeta dag för dag. Det andra området rör praktiska frågor för effektivare projektarbete, här benämnAlltför mycket stabilitet da praktikaliteter, som berörs i kapitlets förhindrar framsteg. senare del. (Harold Wilkinsson) Det viktigaste och tydligaste verktyget för den dagliga arbetsprocessen i projektet är projekttavlan. Den kan utgöras av en stor whiteboard, en tygtavla att sätta nålar i eller en vanlig vägg som tapetserats med blädderblocksblad eller plast. Projekttavlan ger en bild av projektets status och den brukar innehålla följande tre kolumner: Ej påbörjat Påbörjat Klart
128
Kapitel 6
Genomförande
129
De detaljerade krav och aktiviteter, samt tidsuppskattningen i timmar eller heldagar, som skrivits ned i etapploggen överförs till kort, notisar eller post-itlappar och sätts upp i den första kolumnen, med titeln ej påbörjat. Lapparna tejpas upp enligt samma principer som i etapploggen, i prioritetsordning uppifrån och ned på tavlan. Aktiviteten som står högst upp i ej påbörjat-kolumnen är alltså den aktivitet som ska utföras först. För tydlighets skull brukar man ha olika färg på lapparna som visar krav (användarhistorier) respektive aktiviteter. Till exempel vita lappar för krav och gula för de aktiviteter som hör till kravet.
Ej påbörjat
Påbörjat
Besökarna ska kunna gå torrskodda från entrén till scenområdet
Klart
När etappen börjar finns alla krav och aktiviteter i ej påbörjat-kolumnen för att visa att ingenting är genomfört i etappen ännu. Projektdeltagare tar därefter en lapp från ej påbörjat-kolumnen, flyttar lappen till påbörjat-kolumnen, och börjar sitt arbete. Om projektgruppen hann detaljplanera exakt vem som skulle göra vad under uppstartsdagen så vet alla vem som ska ta vilken lapp. Enklast är att skriva initialerna för den som är ansvarig för aktiviteten längst ned i vänstra hörnet. Om inte aktiviteternas ansvariga utsetts är det fritt fram för projektdeltagarna att ta nästa lapp i ordningen som man kan arbeta med, flytta den till påbörjat-kolumnen och själv skriva dit sina initialer för att markera vem som arbetar med aktiviteten. Samma sak gäller om Eva Ek tar hand om den aktivitet som Lars Lind skulle ha ansvarat för. Om nästa aktivitet i ordningen är ”Kör gruslasset till byggarbetsplatsen” som Lars Lind skulle ha ansvarat för men tyvärr inte kan påbörja eftersom han sliter med en försenad uppgift så kan Eva ansvara för den istället. Eva flyttar helt enkelt lappen till påbörjat-kolumnen, stryker över ”LL” i nedre vänstra hörnet och skriver ”EE” istället. När Eva är klar med sin uppgift flyttar hon lappen till klart-kolumnen och plockar därefter en ny lapp från ej påbörjat-listan. När alla aktivitetslappar för ett krav flyttats till klart-kolumnen flyttas även kravlappen för att markera att hela kravets aktiviteter är utförda.
Markera sträckan för gångbro 8
Kör gruslasset till byggarbetsplatsen
Ta emot och instruera leverantörer av gångbro 16
LL EE
Genom att skapa en kultur där varje projektdeltagare ansvarar för att flytta sin aktivitetslapp precis innan man påbörjar arbetet med aktiviteten kan projektet skapa den exakta ögonblicksbilden av hur projektet går. Nedan beskrivs hur man kan använda tavlan för att få den ännu mer informativ.
Besökarna ska passera en och en vid biljettkontrollen Fixa fållor utanför biljettstånd 12
Röda lappar Aktivitetslappen ”Flytta den mobila scenen” sitter i påbörjat-kolumnen eftersom Elisabet arbetar med den just nu. Elisabet har ringt Anders som jobbar på transportavdelningen för att få låna en lastbil och fått det burdusa svaret:
Hyra spärrar 16
130
Kapitel 6
Genomförande
131
De detaljerade krav och aktiviteter, samt tidsuppskattningen i timmar eller heldagar, som skrivits ned i etapploggen överförs till kort, notisar eller post-itlappar och sätts upp i den första kolumnen, med titeln ej påbörjat. Lapparna tejpas upp enligt samma principer som i etapploggen, i prioritetsordning uppifrån och ned på tavlan. Aktiviteten som står högst upp i ej påbörjat-kolumnen är alltså den aktivitet som ska utföras först. För tydlighets skull brukar man ha olika färg på lapparna som visar krav (användarhistorier) respektive aktiviteter. Till exempel vita lappar för krav och gula för de aktiviteter som hör till kravet.
Ej påbörjat
Påbörjat
Besökarna ska kunna gå torrskodda från entrén till scenområdet
Klart
När etappen börjar finns alla krav och aktiviteter i ej påbörjat-kolumnen för att visa att ingenting är genomfört i etappen ännu. Projektdeltagare tar därefter en lapp från ej påbörjat-kolumnen, flyttar lappen till påbörjat-kolumnen, och börjar sitt arbete. Om projektgruppen hann detaljplanera exakt vem som skulle göra vad under uppstartsdagen så vet alla vem som ska ta vilken lapp. Enklast är att skriva initialerna för den som är ansvarig för aktiviteten längst ned i vänstra hörnet. Om inte aktiviteternas ansvariga utsetts är det fritt fram för projektdeltagarna att ta nästa lapp i ordningen som man kan arbeta med, flytta den till påbörjat-kolumnen och själv skriva dit sina initialer för att markera vem som arbetar med aktiviteten. Samma sak gäller om Eva Ek tar hand om den aktivitet som Lars Lind skulle ha ansvarat för. Om nästa aktivitet i ordningen är ”Kör gruslasset till byggarbetsplatsen” som Lars Lind skulle ha ansvarat för men tyvärr inte kan påbörja eftersom han sliter med en försenad uppgift så kan Eva ansvara för den istället. Eva flyttar helt enkelt lappen till påbörjat-kolumnen, stryker över ”LL” i nedre vänstra hörnet och skriver ”EE” istället. När Eva är klar med sin uppgift flyttar hon lappen till klart-kolumnen och plockar därefter en ny lapp från ej påbörjat-listan. När alla aktivitetslappar för ett krav flyttats till klart-kolumnen flyttas även kravlappen för att markera att hela kravets aktiviteter är utförda.
Markera sträckan för gångbro 8
Kör gruslasset till byggarbetsplatsen
Ta emot och instruera leverantörer av gångbro 16
LL EE
Genom att skapa en kultur där varje projektdeltagare ansvarar för att flytta sin aktivitetslapp precis innan man påbörjar arbetet med aktiviteten kan projektet skapa den exakta ögonblicksbilden av hur projektet går. Nedan beskrivs hur man kan använda tavlan för att få den ännu mer informativ.
Besökarna ska passera en och en vid biljettkontrollen Fixa fållor utanför biljettstånd 12
Röda lappar Aktivitetslappen ”Flytta den mobila scenen” sitter i påbörjat-kolumnen eftersom Elisabet arbetar med den just nu. Elisabet har ringt Anders som jobbar på transportavdelningen för att få låna en lastbil och fått det burdusa svaret:
Hyra spärrar 16
130
Kapitel 6
Genomförande
131
”Det kan du glömma! Det finns ingen lastbil ledig förrän på fredag”. Den påbörjade aktiviteten kan alltså inte avslutas på grund av ett hinder. Ett sätt att visualisera den här sortens problem är att använda sig av röda lappar, vars färg för tankarna till en stoppsignal. Elisabet sätter en röd lapp på sin aktivitetslapp och på den röda lappen skriver hon datum och klockslag (för att alla ska se när aktiviteten blev stoppad) samt vilken anledningen är. Hon skriver därför ”Enligt Anders finns det inga lediga lastbilar förrän på fredag” på den röda lappen.
naturligtvis flyttas tillbaka till påbörjat-kolumnen eftersom den inte alls är klar. Personen som ansvarade för aktiviteten bör snarast meddelas om detta så att arbetet kan färdigställas. I vissa projekt kan många delar behöva testas och att flytta en lapp till klart-kolumnen trots att målet inte är uppfyllt blir ju lite missvisande, inte sant? Många lägger därför till kolumnen klart för test mellan påbörjat och klart. Det gör att någon annan (ofta en utsedd testare) då avgör om lappen kan flyttas vidare till klart eller om lappen ska flyttas tillbaka till påbörjat för att något inte var färdigt.
Kanban Flytta den mobila scenen 2012-09-01 10.35 Enligt Anders finns det inga lediga lastbilar förrän på fredag
På det här viset blir det tydligt för projektmedlemmar, projektledaren, beställare och olika chefer vilka hinder projektet står inför. På vissa arbetsplatser har cheferna tagit för vana att dagligen gå igenom projektrummen och läsa på de röda lapparna. Det ger en löpande statusuppdatering om de problem som finns i projektet och cheferna kan genast se om någon av de röda lapparna hör till deras avdelning eller ansvar. I exemplet ovan kanske chefen för transportavdelningen ser lappen, inser komplikationen för projektet, pratar med Anders och löser problemet.
Ytterligare kolumner De tre kolumnerna (ej påbörjat, påbörjat och klart) är en bra utgångspunkt för att se såväl status som ett tydligt flöde av arbete som pågår i projektet. Men som i allt kring det agila så är projekttavlan bara är ett verktyg som mycket lätt kan modifieras. Många brukar därför lägga till ytterligare kolumner för att få en tydligare bild av hur projektet ligger till. Vad händer om en aktivitetslapp som sitter i klart-kolumnen visar sig ha brister så att mer arbete bör utföras för att få aktiviteten klar? Den ska
132
Kapitel 6
Vissa som arbetar med projekttavlan har upptäckt en risk med att många lappar fastnar i påbörjat-kolumnen. Visserligen strävar agila projekt efter principen att varje aktivitet ska avslutas innan nästa påbörjas men om en aktivitet är hindrad eller av någon orsak inte kan avslutas måste den ansvarige gruppmedlemmen ta en ny uppgift för att inte sitta sysslolös. En lösning för att slippa många halvfärdiga aktiviteter har fått namnet Kanban (som är japanska och betyder ungefär tavla). Kanban bygger på principen från Lean som säger att vi ska agera snabbt så fort vi fattat vårt beslut. Fokus för gruppen är alltså att få varje aktivitet slutförd så snabbt som möjligt. Hur uppnår man då det? Jo, en Kanban-tavla ser ut precis som den beskrivna projekttavlan men ofta har den fler kolumner som ersätter påbörjat -kolumnen (exempelvis i ett it-projekt: analys, design, utveckling, test) som tydligt visar de steg i projektets process som behövs för att uppnå varje mål. Lappflyttandet går till precis som tidigare beskrivits, det vill säga att Kalle flyttar sin lapp från analys till design när Kalle har analyserat färdigt. Skillnaden mellan Kanban och den normala projekttavlan upptäcker man inte förrän Kalle nu ska välja sin nästa lapp för att börja arbeta med. En Kanban-tavla har nämligen ett maxantal angivet för varje kolumn, exempelvis max två lappar för analys. Kalle skulle kanske egentligen velat ta tag i en ny uppgift för att börja analysera men om analys-kolumnen redan innehåller två lappar får han inte göra det. Kalle måste då istället hjälpa någon av sina gruppmedlemmar för att få en redan påbörjad analysuppgift att bli klar för design. Det här var i väldigt korta drag en beskrivning av Kanban och det finns mycket mer att läsa (exempelvis Kniberg, 2010) om ämnet för den som är
Genomförande
133
”Det kan du glömma! Det finns ingen lastbil ledig förrän på fredag”. Den påbörjade aktiviteten kan alltså inte avslutas på grund av ett hinder. Ett sätt att visualisera den här sortens problem är att använda sig av röda lappar, vars färg för tankarna till en stoppsignal. Elisabet sätter en röd lapp på sin aktivitetslapp och på den röda lappen skriver hon datum och klockslag (för att alla ska se när aktiviteten blev stoppad) samt vilken anledningen är. Hon skriver därför ”Enligt Anders finns det inga lediga lastbilar förrän på fredag” på den röda lappen.
naturligtvis flyttas tillbaka till påbörjat-kolumnen eftersom den inte alls är klar. Personen som ansvarade för aktiviteten bör snarast meddelas om detta så att arbetet kan färdigställas. I vissa projekt kan många delar behöva testas och att flytta en lapp till klart-kolumnen trots att målet inte är uppfyllt blir ju lite missvisande, inte sant? Många lägger därför till kolumnen klart för test mellan påbörjat och klart. Det gör att någon annan (ofta en utsedd testare) då avgör om lappen kan flyttas vidare till klart eller om lappen ska flyttas tillbaka till påbörjat för att något inte var färdigt.
Kanban Flytta den mobila scenen 2012-09-01 10.35 Enligt Anders finns det inga lediga lastbilar förrän på fredag
På det här viset blir det tydligt för projektmedlemmar, projektledaren, beställare och olika chefer vilka hinder projektet står inför. På vissa arbetsplatser har cheferna tagit för vana att dagligen gå igenom projektrummen och läsa på de röda lapparna. Det ger en löpande statusuppdatering om de problem som finns i projektet och cheferna kan genast se om någon av de röda lapparna hör till deras avdelning eller ansvar. I exemplet ovan kanske chefen för transportavdelningen ser lappen, inser komplikationen för projektet, pratar med Anders och löser problemet.
Ytterligare kolumner De tre kolumnerna (ej påbörjat, påbörjat och klart) är en bra utgångspunkt för att se såväl status som ett tydligt flöde av arbete som pågår i projektet. Men som i allt kring det agila så är projekttavlan bara är ett verktyg som mycket lätt kan modifieras. Många brukar därför lägga till ytterligare kolumner för att få en tydligare bild av hur projektet ligger till. Vad händer om en aktivitetslapp som sitter i klart-kolumnen visar sig ha brister så att mer arbete bör utföras för att få aktiviteten klar? Den ska
132
Kapitel 6
Vissa som arbetar med projekttavlan har upptäckt en risk med att många lappar fastnar i påbörjat-kolumnen. Visserligen strävar agila projekt efter principen att varje aktivitet ska avslutas innan nästa påbörjas men om en aktivitet är hindrad eller av någon orsak inte kan avslutas måste den ansvarige gruppmedlemmen ta en ny uppgift för att inte sitta sysslolös. En lösning för att slippa många halvfärdiga aktiviteter har fått namnet Kanban (som är japanska och betyder ungefär tavla). Kanban bygger på principen från Lean som säger att vi ska agera snabbt så fort vi fattat vårt beslut. Fokus för gruppen är alltså att få varje aktivitet slutförd så snabbt som möjligt. Hur uppnår man då det? Jo, en Kanban-tavla ser ut precis som den beskrivna projekttavlan men ofta har den fler kolumner som ersätter påbörjat -kolumnen (exempelvis i ett it-projekt: analys, design, utveckling, test) som tydligt visar de steg i projektets process som behövs för att uppnå varje mål. Lappflyttandet går till precis som tidigare beskrivits, det vill säga att Kalle flyttar sin lapp från analys till design när Kalle har analyserat färdigt. Skillnaden mellan Kanban och den normala projekttavlan upptäcker man inte förrän Kalle nu ska välja sin nästa lapp för att börja arbeta med. En Kanban-tavla har nämligen ett maxantal angivet för varje kolumn, exempelvis max två lappar för analys. Kalle skulle kanske egentligen velat ta tag i en ny uppgift för att börja analysera men om analys-kolumnen redan innehåller två lappar får han inte göra det. Kalle måste då istället hjälpa någon av sina gruppmedlemmar för att få en redan påbörjad analysuppgift att bli klar för design. Det här var i väldigt korta drag en beskrivning av Kanban och det finns mycket mer att läsa (exempelvis Kniberg, 2010) om ämnet för den som är
Genomförande
133
intresserad. Det grundläggande problemet som Kanban vill lösa är alltså att få varje påbörjad aktivitet färdig så snabbt som möjligt. Det har gjort att Kanbantavlan blivit väldigt populär i it-support och –förvaltningssammanhang.
Stå-upp-möte Som beskrivits inledningsvis i detta kapitel så är det en agil princip att ha ständig kontroll över var projektet befinner sig. Projektrummet ska vara som ett flygplans cockpit där olika instrument visar var projektet befinner sig. Ett av dessa instrument är däremot inte visuellt utan utgörs av en muntlig avstämning där projektledaren varje dag följer upp projektets status med alla projektmedlemmar samlade. Den dagliga avstämningen kallas stå-upp-möte. Inom modellen Scrum benämns aktiviteten Daily Scrum för att undvika ordet möte i termen. Skälet att utesluta ordet möte är att ordet ofta förknippas med ineffektiva och långdragna sammanträden. Ett stå-upp-möte handlar om att stående, under en kort avsatt tid, stämma av status och hantera problem inom gruppen.
SIP-frågorna Samtliga deltagare träffas för att svara på följande tre frågor: 1. Sedan sist? – Vad har du gjort sedan förra mötet? 2. Idag? – Vad kommer du att göra till nästa möte? 3. Problem? – Vad kan hindra dig från att lyckas? (Alltså: Vad kan projektledaren eller gruppen göra för att hjälpa dig?) För att komma ihåg och behålla fokus på de tre frågorna kan man kalla mötena för SIP-möten. Detta är de tre grundläggande frågorna som skaparna av modellen Scrum tagit fram. Författaren Craig Larman (2004) föreslår ytterligare två kompletterande frågor: 4. Har ni upptäckt några nya aktiviteter som behöver genomföras för att kunna uppnå etappens mål? 5. Har ni lärt er eller beslutat något som gruppen har nytta av att få veta?
134
Kapitel 6
Dessa ytterligare två frågor behöver inte vara något som varje projektdeltagare ska svara på men är bra att ha i bakhuvudet om det skulle vara relevant för mötet. Som scrum master kan man annars avsluta med att ställa dessa två frågor till hela gruppen.
Avstämning – inte rättegång Nu tänker kanske en och annan läsare: ”Men vänta nu, ska verkligen projektledaren agera som någon sorts polis och hela tiden detaljgranska allt som görs? Hur bra är det för motivationen i vår projektgrupp?” För att bemöta denna fråga beskrivs hur det agila sättet att göra uppföljning och avstämning genomförs inom agil projektledning. I kapitlet om roller beskrevs projektledarens roll som den hjälpande individen som banar väg för projektgruppen och undanröjer problem. Samma attityd gäller under all uppföljning i agila projekt. De dagligen återkommande avstämningarna måste vara stödjande för projektgruppen. Grundidén är att ju fler som känner till ett problem, desto fler hjärnor finns det som kan hjälpa till med att lösa problemet. De dagliga avstämningarna är i första hand till för gruppen. Avstämningarna är inte till för att ställa projektmedlemmarna till svars för någonting. Ett tyvärr förekommande beteende bland projektledare är att avkräva individuella förklaringar till varför tidsuppskattningar inte höll. Istället bör fokus ligga på hur lång tid aktiviteten verkligen kommer att ta och stötta projektgruppen och individen så att inte projektet försenas ännu mer. Människor tycks ofta tro att det går att förutsäga framtiden. Personligt åtagande är viktigt för att projektmedlemmar ska göra sitt bästa men man kan inte avkräva att människor exakt ska kunna förutspå framtiden. Tyvärr uppstår det lätt en ledarskapskultur där projektdeltagare ska försvara sig och i detalj förklara varför de misslyckades med sin tidsuppskattning. Detta gör att en typ av skamkultur uppstår. Personen som uppskattade en viss tidsåtgång får kritik för att ha misslyckats med sitt åtagande och risken finns då att projektmedlemmen nästa gång tar till en överdriven tidsuppskattning för att undgå risken att misslyckas igen. Plötsligt har då ett otrevligt falskspel påbörjats i projektkulturen, som handlar om att lägga luft i sin planering för att slippa skämmas. Det finns även en risk att deltagaren upplever ett misslyckande även om uppgiften tog kortare tid än beräknat eftersom hon då måste erkänna att även denna tidsuppskattning var felaktig, om än åt det positiva hållet. De sista fem timmarna kanske projektdeltagaren helt enkelt mörkar att
Genomförande
135
intresserad. Det grundläggande problemet som Kanban vill lösa är alltså att få varje påbörjad aktivitet färdig så snabbt som möjligt. Det har gjort att Kanbantavlan blivit väldigt populär i it-support och –förvaltningssammanhang.
Stå-upp-möte Som beskrivits inledningsvis i detta kapitel så är det en agil princip att ha ständig kontroll över var projektet befinner sig. Projektrummet ska vara som ett flygplans cockpit där olika instrument visar var projektet befinner sig. Ett av dessa instrument är däremot inte visuellt utan utgörs av en muntlig avstämning där projektledaren varje dag följer upp projektets status med alla projektmedlemmar samlade. Den dagliga avstämningen kallas stå-upp-möte. Inom modellen Scrum benämns aktiviteten Daily Scrum för att undvika ordet möte i termen. Skälet att utesluta ordet möte är att ordet ofta förknippas med ineffektiva och långdragna sammanträden. Ett stå-upp-möte handlar om att stående, under en kort avsatt tid, stämma av status och hantera problem inom gruppen.
SIP-frågorna Samtliga deltagare träffas för att svara på följande tre frågor: 1. Sedan sist? – Vad har du gjort sedan förra mötet? 2. Idag? – Vad kommer du att göra till nästa möte? 3. Problem? – Vad kan hindra dig från att lyckas? (Alltså: Vad kan projektledaren eller gruppen göra för att hjälpa dig?) För att komma ihåg och behålla fokus på de tre frågorna kan man kalla mötena för SIP-möten. Detta är de tre grundläggande frågorna som skaparna av modellen Scrum tagit fram. Författaren Craig Larman (2004) föreslår ytterligare två kompletterande frågor: 4. Har ni upptäckt några nya aktiviteter som behöver genomföras för att kunna uppnå etappens mål? 5. Har ni lärt er eller beslutat något som gruppen har nytta av att få veta?
134
Kapitel 6
Dessa ytterligare två frågor behöver inte vara något som varje projektdeltagare ska svara på men är bra att ha i bakhuvudet om det skulle vara relevant för mötet. Som scrum master kan man annars avsluta med att ställa dessa två frågor till hela gruppen.
Avstämning – inte rättegång Nu tänker kanske en och annan läsare: ”Men vänta nu, ska verkligen projektledaren agera som någon sorts polis och hela tiden detaljgranska allt som görs? Hur bra är det för motivationen i vår projektgrupp?” För att bemöta denna fråga beskrivs hur det agila sättet att göra uppföljning och avstämning genomförs inom agil projektledning. I kapitlet om roller beskrevs projektledarens roll som den hjälpande individen som banar väg för projektgruppen och undanröjer problem. Samma attityd gäller under all uppföljning i agila projekt. De dagligen återkommande avstämningarna måste vara stödjande för projektgruppen. Grundidén är att ju fler som känner till ett problem, desto fler hjärnor finns det som kan hjälpa till med att lösa problemet. De dagliga avstämningarna är i första hand till för gruppen. Avstämningarna är inte till för att ställa projektmedlemmarna till svars för någonting. Ett tyvärr förekommande beteende bland projektledare är att avkräva individuella förklaringar till varför tidsuppskattningar inte höll. Istället bör fokus ligga på hur lång tid aktiviteten verkligen kommer att ta och stötta projektgruppen och individen så att inte projektet försenas ännu mer. Människor tycks ofta tro att det går att förutsäga framtiden. Personligt åtagande är viktigt för att projektmedlemmar ska göra sitt bästa men man kan inte avkräva att människor exakt ska kunna förutspå framtiden. Tyvärr uppstår det lätt en ledarskapskultur där projektdeltagare ska försvara sig och i detalj förklara varför de misslyckades med sin tidsuppskattning. Detta gör att en typ av skamkultur uppstår. Personen som uppskattade en viss tidsåtgång får kritik för att ha misslyckats med sitt åtagande och risken finns då att projektmedlemmen nästa gång tar till en överdriven tidsuppskattning för att undgå risken att misslyckas igen. Plötsligt har då ett otrevligt falskspel påbörjats i projektkulturen, som handlar om att lägga luft i sin planering för att slippa skämmas. Det finns även en risk att deltagaren upplever ett misslyckande även om uppgiften tog kortare tid än beräknat eftersom hon då måste erkänna att även denna tidsuppskattning var felaktig, om än åt det positiva hållet. De sista fem timmarna kanske projektdeltagaren helt enkelt mörkar att
Genomförande
135
Sakregister Agile 1, 31 ansvarsdiffusion 47 användarhistorier 107–109, 113, 130 arbetscykel 34–35 avslut 17, 163–165 avslutsfas 19 beslutslogg 152 beslutspunkt 20 beställare 62 buffertetapp 104 burn down chart 139 Crystal Clear 30 daily scrum 134 De 12 agila principerna 36–37 delmål 16 delresultat 34, 67, 141 Demingcykeln 33 det agila manifestet 32–35 detaljera 95 detaljplanering 95, 110 diskussionswebsida 153 distanskommunikation 187 DSDM (Dynamic Systems Development Model) 30, 114 Dynamic Systems Development Model, DSM 30, 114 erfarenhetsmöte 143 etapp 34-35, 103–104, 163 etappgraf 139 etapplan 96, 103, 200 etapplogg 105, 110–111, 113, 130 evenemangsprojekt 184 expertfunktioner 45 eXtreme Programming, XP 11, 30
220
Sakregister
faser 17 fasta kontrakt 177 fel 146 färdplan 96–97,101, 198 förändringsprojekt 184 gaffling 119 Gantt-schema 25, 103 genomförande 17 genomförandefas 18 ground rules 150 gruppregler 150 gränssnitt 176 inkrement 29 interaktioner 32–33 intern mottagare 62–63, 167 intressentanalys 76–80 intressentkarta 91 iterationer 29 kaizen 26 kanban 133 kommunikationsplan 76, 84–88 konflikt 52 kontraktsförhandling 32, 34 krav 104, 106, 130 kritiska linjens princip 25 kultur 176, 180 kundmedverkan 9 kundorderprojekt 49–50, 58, 184 kundsamarbete 32, 34 Lean 26–30 ledtid 25 leveransplan 96, 102, 199 leverantörer 66 logiska nätverk 25, 99 marknadsprojekt 184 meta scrum 182 moderator 89 mål 106
Sakregister
221
Sakregister Agile 1, 31 ansvarsdiffusion 47 användarhistorier 107–109, 113, 130 arbetscykel 34–35 avslut 17, 163–165 avslutsfas 19 beslutslogg 152 beslutspunkt 20 beställare 62 buffertetapp 104 burn down chart 139 Crystal Clear 30 daily scrum 134 De 12 agila principerna 36–37 delmål 16 delresultat 34, 67, 141 Demingcykeln 33 det agila manifestet 32–35 detaljera 95 detaljplanering 95, 110 diskussionswebsida 153 distanskommunikation 187 DSDM (Dynamic Systems Development Model) 30, 114 Dynamic Systems Development Model, DSM 30, 114 erfarenhetsmöte 143 etapp 34-35, 103–104, 163 etappgraf 139 etapplan 96, 103, 200 etapplogg 105, 110–111, 113, 130 evenemangsprojekt 184 expertfunktioner 45 eXtreme Programming, XP 11, 30
220
Sakregister
faser 17 fasta kontrakt 177 fel 146 färdplan 96–97,101, 198 förändringsprojekt 184 gaffling 119 Gantt-schema 25, 103 genomförande 17 genomförandefas 18 ground rules 150 gruppregler 150 gränssnitt 176 inkrement 29 interaktioner 32–33 intern mottagare 62–63, 167 intressentanalys 76–80 intressentkarta 91 iterationer 29 kaizen 26 kanban 133 kommunikationsplan 76, 84–88 konflikt 52 kontraktsförhandling 32, 34 krav 104, 106, 130 kritiska linjens princip 25 kultur 176, 180 kundmedverkan 9 kundorderprojekt 49–50, 58, 184 kundsamarbete 32, 34 Lean 26–30 ledtid 25 leveransplan 96, 102, 199 leverantörer 66 logiska nätverk 25, 99 marknadsprojekt 184 meta scrum 182 moderator 89 mål 106
Sakregister
221
OBS (Organization Breakdown Structure) 66 Organization Breakdown Structure, OBS 66 parallellisering 25 PBS (Product Breakdown Structure) 97 PDCA-cykeln 33 planeringsfas 18 planning poker 120 PMI (Project Management Institute) 14 post-it-lappar 151 praktikaliteter 129, 148 processdiagram 139 Product Breakdown Structure, PBS 97 produktlogg 105–107, 109, 201 produktutvecklingsprojekt–184 produktägare 49, 56, 59–61, 181, 196 progressdiagram 139–140 Project Management Institute, PMI 14 projektavslut 167 projektbeställare 56 projektledare 10, 47–50, 53–56, 135 projektmodell 17 projektplan 210 projektrum 79 projekttavla 129 projekttriangeln 14 projektvägg 151 projektöverlämning 161 RAD (Rapid Application Development) 30 Rapid Application Development, RAD 30 Rational Unified Process, RUP 30, 108 referensgruppen 66 resursägare 62–63 riskhantering 145 rullande närzonsplanering 110 RUP (Rational Unified Process) 30, 108
222
Sakregister
Schwaber, Ken 31, 43 scope creap 57 Scrum 11, 30, 31, 43 scrum master 47–50, 52–56, 62 scrum of scrums 182 scrum team 31 SIP-frågorna 134–138 självstyre 43, 47 slutrapport 168 sprint 16, 105 statusdiagram 139 styrgrupp 62–64 stå-upp-möte 134 Sutherland, Jeff 31 test 105 testare 46–47 tidsuppskattning 113, 115, 135 timeboxing 13 town hall meeting 183 Toytoa Production System, TPS 26–29 TPS (Toytoa Production System) 26–29 tvärkompeten 44 use cases 108 WBS (Work Breakdown Structure) 25 Wiki 153 vision 76, 81–84, 96 visionsdokument 76, 81–84 Work Breakdown Structure, WBS 25, 98 workshop 74, 88–90 X- och Y-teorin 51 XP (eXtreme Programming) 11 åtagande 96 överlämning 17, 162–166 överlämningsfas 18
Sakregister
223
OBS (Organization Breakdown Structure) 66 Organization Breakdown Structure, OBS 66 parallellisering 25 PBS (Product Breakdown Structure) 97 PDCA-cykeln 33 planeringsfas 18 planning poker 120 PMI (Project Management Institute) 14 post-it-lappar 151 praktikaliteter 129, 148 processdiagram 139 Product Breakdown Structure, PBS 97 produktlogg 105–107, 109, 201 produktutvecklingsprojekt–184 produktägare 49, 56, 59–61, 181, 196 progressdiagram 139–140 Project Management Institute, PMI 14 projektavslut 167 projektbeställare 56 projektledare 10, 47–50, 53–56, 135 projektmodell 17 projektplan 210 projektrum 79 projekttavla 129 projekttriangeln 14 projektvägg 151 projektöverlämning 161 RAD (Rapid Application Development) 30 Rapid Application Development, RAD 30 Rational Unified Process, RUP 30, 108 referensgruppen 66 resursägare 62–63 riskhantering 145 rullande närzonsplanering 110 RUP (Rational Unified Process) 30, 108
222
Sakregister
Schwaber, Ken 31, 43 scope creap 57 Scrum 11, 30, 31, 43 scrum master 47–50, 52–56, 62 scrum of scrums 182 scrum team 31 SIP-frågorna 134–138 självstyre 43, 47 slutrapport 168 sprint 16, 105 statusdiagram 139 styrgrupp 62–64 stå-upp-möte 134 Sutherland, Jeff 31 test 105 testare 46–47 tidsuppskattning 113, 115, 135 timeboxing 13 town hall meeting 183 Toytoa Production System, TPS 26–29 TPS (Toytoa Production System) 26–29 tvärkompeten 44 use cases 108 WBS (Work Breakdown Structure) 25 Wiki 153 vision 76, 81–84, 96 visionsdokument 76, 81–84 Work Breakdown Structure, WBS 25, 98 workshop 74, 88–90 X- och Y-teorin 51 XP (eXtreme Programming) 11 åtagande 96 överlämning 17, 162–166 överlämningsfas 18
Sakregister
223