Agil Projektledning [4 ed.] 9789752358368

Citation preview

projektledning FJARDE UPPLAG

Tomas Gustavsson

Agil projektledninq Tomas Gustavsson Sanoma Utbildning

Sanoma Utbildning Postadress: Box 38073, 700 64 Stockholm Besöksadress: Rosenlundsgatan 54, 4T, Stockholm Hemsida: www.sanomautbildning.se E-post: [email protected] Order/Läromedelsinformation Telefon: 08-587 642 70 Redaktör/Projektledare: Karin Sörensen Förläggare: Amanda Schött Franzen Omslag, illustrationer och originalets grafiska form: Anna-Karin Nilsson och Filip Rensfelt Agil projektledning ISBN 978-97-523-5836-8 02020 Tomas Gustavsson och Sanoma Utbildning AB, Stockholm Fjärde upplagan 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 Copyright Access 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 Copyright Access. 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. Tryck: Livonia Print, Lettland 2020

Det är inte den här boken som kommer göra dig till en agil projektledare. 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 ska 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. Lärarkollegorna inom 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. Det här är fjärde upplagan av boken och det gläder mig att så många visat intresse för agil projektledning. Det agila arbetssättet används alltmer i stora organisationer såsom Ericsson, Volvo, Försäkringskassan och på de stora bankerna. När det agila arbete skalas upp behöver organisationen ofta göra anpassningar för att hela verksamheten ska fungera agilt. Ett ramverk som blivit vanligt att införa i större verksamheter kallas Scaled Agile Framework (förkortas SAFe) och i den här fjärde upplagan av boken skriver jag mer om såväl uppskalning generellt som om SAFe specifikt. Trevlig läsning! Tomas Gustavsson, januari 2020

Innehåll Kapitel 1. Vad är agil

Kapitel 5. Planering 95

projektledning? 7

Planering på kort eller lång sikt 97

Vad ger agil projektledning? 9

Färdplan 99

Den agila synen på tid och resultat 13

Leveransplan 104

Faser i projekt 17

Sprintplan 107

Sammanfattning 21

Planering enligt SAFe 108

Kapitel 2. Det agila manifestet

Sprintbacklogg 118

Produktbacklogg 112 och metodernas historia 23

Tidsuppskattning 124

Projektledningens historia 25

Sammanfattning 132

Lean 26

Övningar 133

De agila metoderna växer fram 29 Det agila manifestet 32

Kapitel 6. Genomförande 735

De 12 agila principerna 36

Projekttavla 137

Sammanfattning 40

Stå-upp-möte 142

Kapitel 3. Roller 41

Erfarenhetsmöte 151

Gruppen 43

Löpande riskhantering 154

Projektledare och scrum master 48

Presentation vid sprintslut 149

Produktägaren 57

Mer om Kanban: att arbeta utan pulser 157 Praktikaliteter 158

Styrgruppen 63

Sammanfattning 169

Referensgruppen 67

Övningar 170

Leverantörer 68 Chefens roll i agila projekt 69

Kapitel 7. Avsluta projekt 173

Sammanfattning 70

Att avsluta agila projekt 175

Övningar 71

Att överlämna eller inte - det är frågan 178 Projektavslut 182

Kapitel 4. Förstudien 73

Sammanfattning 183

Ofta förbisedd, ej försumbar 75

Övningar 183

Förstudiens frågor 77 Intressentanalys 78

Kapitel 8. När passar agila

Visionen 83

metoder? 785

Planera kommunikationen 87

Goda förutsättningar för agila projekt 187

Workshop 91

Sämre förutsättningar för agila metoder 189

Sammanfattning 93

Agila metoder i stora projekt 192

Övningar 93

Kulturen krossar 195 Lämpliga projekttyper 200 Arbete på distans 202 Sammanfattning 205

Kapitel 9. Hallar och checklistor 207 Dokument till stöd 209 Checklista - Passar agil projektledning? 210 Checklista - Frågor att ställa sig 211 Checklista - Produktägare 212 Checklista - Komma igång med agil projektledning 213 Mall - Projektanalys 214 Mall - Färdplan 215 Mall - Övergripande leveransplan 216 Mall - Detaljerad leveransplan 217 Mall - Produktbacklogg 218

Kapitel 70. Projektledare berättar 279 Sven på ett it-konsultföretag 221

Agil

Elin som driver evenemangsprojekt 224 Peter som jobbar på ett call center 228 Sammanfattning 231

projektledning

Litteratur 232

ÖVNINGSBOK

Bildförteckning 235 Sakregister 236 I Agil projektledning - Övningsbok kan du öva på textbokens innehåll genom instuderingsfrågor, praktiska övningar, diskussionsövningar och scenarioövningar. I slutet av varje kapitel ges förslag på övningar i Agil projektledning - Övningsbok som du kan göra.

Agil projektledning har en hemsida med presentationsmaterial, Boken finns även översatt

mallar och checklistor som stöd

till engelska med titeln Agile

till lärare, studenter, projekt-

Project Management.

ledare och projektgrupper: www.sanomautbildning.se/agil

'

'

jef

fr

-

•

• 11

LI

•

• Vad är agil projektledning?

Agil projektledning handlar om att driva projekt på ett smidigare sätt. Ordet "agil" kommer från engelskans agile som betyder rörlig eller vig. Att vara agil innebär att organisationen har den smidighet som krävs för att ständigt förbättras och utvecklas löpande med sin verksamhet. Av allt som finns beskrivet och definierat kring vad som är agilt finns en överordnad princip: Att varje dag försöka utföra saker bättre än de gjordes dagen innan för såväl projektresultatet som för arbetsprocessen. Det agila arbetssättet innebär att projektgruppen har mandat att själv genomföra sina dagliga förbättringar och tillåts göra fel, lära sig och förändra sitt arbetssätt genom hela projektet.

8

Kapitel ii

Vad ger agil projektledning? Många verksamheter har nått enorma framgångar genom att gå över till ett agilt arbetssätt. Företaget Yahoo! beskriver i en intern undersökning (Benefield, 2007) att de ökat sin produktivitet med i genomsnitt 34 procent, bara genom att förändra sitt arbetssätt. Det är ett antal faktorer som utmärker agil projektledning och som kan få organisationer att nå denna effektivitetsexplosion. Här kommer några av de viktigaste:

Hantera förändringar

När det gäller metoder pp finns det kanske en miljon eller fler, men principer är det ont om. Den som förstår principerna kan med framgång välja sina egna metoder. Den som prövar metoder men ignorerar principerna kommer utan tvekan att få problem.

Agil projektledning handlar om en självklarhet: Förändringar sker alltid i projekt. Stora som små, välplanerade som dåligt planerade, alla projekt får förändrade förutsättningar. I många projekt kritiseras projektledare för att projekten inte gått enligt plan — precis som om man väntat sig att framtiden skulle kunna förutses i (Ralph Waldo Emerson) detalj. Många projektledare klagar över hur administrativt krångligt det är att ändra och uppdatera planer när den jobbiga verkligheten gör sig påmind och får projekten att inte bli som man tänkt sig. Dessutom är det ofta förändringar på grund av nya insikter eller marknadsförhållanden som gör att ett projekt

blir en framgång — inte den fina ursprungliga planen. En agil projektledare har stöd av en metodik som gör att förändringar kan hanteras på ett mycket effektivare sätt än i de flesta traditionella projektledningsmetoder. Att arbeta agilt innebär att arbeta i korta steg som är mindre än en månad långa och där projektets krav och mål kan förändras vid varje sådant steg.

Mer nytta för kunden under hela projektet Inom traditionell projektledning har man alltid vetat att kund- eller beställarmedverkan är viktigt. Men få har kunnat redogöra för hur den ska gå till. En agil projektledare har en metod för att involvera kunden strukturerat och återkommande i projektet. Eftersom resultat levereras i varje kort etapp

Vad är agil projektledning?

9

(eller sprint som det kallas i agila projekt), "tvingas" kunden att ha åsikter i varje steg av projektet. En kund eller beställare vet att allt är möjligt att förändra vid varje stegs avslut. Kunden behöver inte oroa sig för om alla krav verkligen finns nedskrivna i detalj eftersom varje stegövergång ger en möjlighet att förändra, utöka eller ta bort krav och mål för projektet. Detta gör att kunden får maximal nytta av projektet och behöver sällan vara orolig för vad som kommer att hända i slutändan eftersom man är involverad ofta och löpande genom hela projektet. Kunden kan också avsluta projektet när som helst och behöver inte vara orolig för att onödigt mycket pengar investeras i projektet. Ett agilt arbetssätt kan på så vis ge mer nytta per krona. I de flesta agila projekt innebär det dessutom att nytta levereras ofta och återkommande, inte bara i slutet av projektet som ofta är fallet i traditionella projekt. Vid varje kort steg försöker nämligen projektgruppen att slutföra användbart projektresultat som kunden kan använda och tjäna pengar på, redan tidigt i projektet.

En motiverad projektgrupp Ordet projektledning för tankarna till projektledaren, rollen som normalt ansvarar för projektets resultat. Synen på roller är något som skiljer agil projektledning från traditionell projektledning. Fokus i agil projektledning är i första hand inriktat på gruppens, inte projektledarens, förmåga att leda projekt. Det agila synsättet innebär att gruppen ska vara självgående och beslutsmässig eftersom gruppens deltagare är de som vet mest om detaljer och problem i projektet. Agil projektledning har ofta växt fram som motreaktioner i miljöer där all beslutskraft legat på projektledaren och där gruppens röster inte blivit hörda. Genom att få projektgruppen att känna ansvar och mandat frigörs projektledarens tid och kraft. Projektledaren kan då syssla med det som ger verklig effektivitet: att undanröja hinder och bana väg för gruppen. Allt som hindrar eller stör gruppen skapar slöseri med tid, pengar och resultat och bör prioriteras av projektledaren för att få ett så effektivt projektarbete som möjligt.

En jämn och rimlig arbetsbelastning Agil projektledning innebär medbestämmande och påverkan från alla deltagare i projektgruppen. Varje deltagares åsikt tas hänsyn till vid beslut om

Kapitel i

hur arbetet ska gå till. Det är inte bara en rättighet, det är en skyldighet att ha åsikter och förslag för att ta fram den bästa lösningen för projektet. Vid varje kort steg i projektet får dessutom projektdeltagarna visa upp vad de gjort och får direkt feedback från beställare eller kunder. Det gör naturligtvis att agila projektgrupper blir väldigt motiverade i sitt arbete. Att de dessutom blir gladare är för att de får den respekt de förtjänar. Varje kort definierat steg sker nämligen med en jämn arbetsbelastning. Många års projektforskning visar väldigt tydligt vilka kvalitetsbrister som uppstår om projektgrupper drivs till att jobba orimliga övertidstimmar och pressas till att lämna ifrån sig projektresultat som skulle kunnat bli mycket bättre om det fått ytterligare några timmars förbättring. För hårt pressade projektgrupper straffar sig ofta i slutet av projekten, då felen upptäcks, och får då ofta projektförseningar som följd. I agila projekt strävar gruppen efter ett jämnt arbetstempo där fokus ligger på att slutföra varje steg innan nästa arbetsuppgift påbörjas.

En flygplanscockpit för projekt Många klagar över otydligheten i projekt. Projektbeställare skäller och projektledare river ibland sitt hår över den otydlighet kring hur status egentligen ser ut i projektet. Inom agil projektledning finns därför ett antal verktyg och visuella mätinstrument som gör att alla hela tiden kan se var projektet befinner sig på sekunden när. Det kan liknas vid en flygplanscockpit av instrument som på olika sätt visar status. Dessa instrument baseras alltid på enkla tekniker som inte kräver tung administration. Ett av dessa verktyg är dessutom helt administrationsfritt då det handlar om tätare och mer strukturerad kommunikation gruppmedlemmarna emellan vilket gör att alla vet vad var och en gör just nu. För projektets omgivning innebär instrumenten en enkel och effektiv inblick i projektets omedelbara status.

Fungerar i många branscher Agil är ett samlingsnamn för ett antal ramverk och metoder som växt fram på olika håll där Scrum och eXtreme Programming (XP) är de vanligaste. Vissa av dessa metoder bygger på lärdomar dragna från projekt som lyckats mot alla odds. I krisprojekt som återtagit kontrollen har man frågat sig: "Om detta fungerar i kris, varför skulle det inte kunna fungera i vanliga projekt också?". Andra agila metoder kommer från studier av värderingar,

Vad är agil projektledning?

11

principer och tekniker inom processindustri som förfinats och anpassats för att driva projekt på ett effektivt sätt. De agila metoderna har utvecklats inom it-branschen. Det betyder inte att man måste verka inom it-branschen för att arbeta agilt. Oavsett om du jobbar med ideella projekt, med sidoprojekt i en liten organisation eller om du befinner dig i en global koncern med en inarbetad projektmodell kan du ha nytta av att anamma ett agilt synsätt.

Idag arbetar så vitt skilda verksamheter som evenemangsprojekt, call centerföretag och enheter inom försvarsmakten som utvecklar militärstrategiska koncept med agil projektledning. Däremot passar metoderna bättre för vissa situationer än andra och detta beskrivs noggrannare i kapitel 8, "När passar agila metoder?". Beroende på situation kan du kanske inte använda dig av alla delar av de agila metoderna men det grundläggande synsättet går att ta med sig överallt, oavsett typ av projekt.

12

Kapitel i

Den agila synen på tid och resultat I det följande kapitlet kommer några jämförande beskrivningar ges mellan det agila arbetssättet och traditionella projektledningskoncept.

Timeboxing Timeboxing är ett engelskt uttryck, som tyvärr ännu saknar en vedertagen svensk översättning. Timeboxing innebär att definiera ett mål för en tidsperiod och sedan låta tiden vara den heliga faktorn. Att göra det bästa av situationen inom en given tidsram är alltså vad timeboxing innebär och är grundläggande för det agila arbetssättet. De korta cyklerna av arbete (som kallas sprintar), med stopp för att visa upp projektresultat och reflektera kring möjligheter till förbättring, är alltså tidsperioder då projektet gör det bästa av situationen. Tiden, inte kraven, är faktorn man inte ruckar på. Genom att arbeta mot en deadline tvingas man att prioritera mellan vad som är viktigt och mindre viktigt. Den prioriteringen är en viktig del av beställarens eller kundens arbete med projektgruppen. Eftersom kunden inte alltid kan vara närvarande och ge besked om detaljer måste projektgruppen veta vad som är viktigast ur nyttoperspektiv för att prioritera rätt under arbetets gång.

TIMEBOXAT TÅRTKALAS Tänk dig att du behöver arrangera en 6o-årsfest för din släkting. En

e

lördag två månader framåt i tiden fyller släktingen år och festen ska hållas på självaste födelsedagen. Oavsett hur du planerar så finns det en faktor du aldrig kan ändra på: tidpunkten. Det innebär att du måste se till att det viktigaste är ordnat och att mindre viktiga saker kan strykas om det blir allt för ont om tid. Om de brasilianska servettringarna tar tre månader att leverera kan du stryka dem ur planeringen utan att det är någon katastrof - festen blir säkert lika bra ändå. Tårtan är däremot något som förväntas och står högt upp på önskelistan för alla närvarande. Att bestämma och beställa tårtan måste därför göras tidigt i arbetet så att den inte riskerar att prioriteras bort senare på grund av tidsbrist.

Vad är agil projektledning?

13

Projekttriangeln Ett vanligt sätt att definiera ett projekt är utifrån de tre parametrarna tid, kostnad och resultat eller omfattning. De kan sägas utgöra projektets ramar och brukar för pedagogikens skull ritas som en triangel. Projekttriangeln härstammar från traditionella projektledningsmetoder.

Tid

Kostnad

ETT PROJEKT HAR RAMARNA: ■ Tid ■ Kostnad ■ Resultat eller omfattning

Inom den amerikanska organisationen för att certifiera projektledare, PMI (Project Management Institute), kallas denna projekttriangel även för begränsningstriangeln eftersom den visar vilka begränsande ramar som projektmålet innehåller. Detta blir extra tydligt då projekt avviker från sin ursprungliga planering.

14

Kapitel

EXEMPEL - ÄNDRADE RAMAR

Detta alternativ visar alltså hur vi för-

Projektet "Träbron över Svartforsen"

ändrar kostnadsramen för att klara av

"Projektets mål är att bygga en träbro

att genomföra projektet med oföränd-

över forsen för mindre än 200 000 SEK

rade ramar för tid och resultat.

och bron ska gå att använda senast sista juni".

Alternativ 2: Enligt planen ska ett

väldigt tjusigt räcke skapas med alle-

De tre begränsningar som definierar

handa snickarglädje. Om projektgrup-

projektet är:

pen istället gör ett enkelt och funk-

Tid: Sista juni

tionsdugligt räcke kan det levereras i

Kostnad: 200 000 SEK

tid och till planerad kostnad.

Resultat: Träbro

I detta alternativ förändrar vi alltså resultatramen för att klara av att ge-

Låt oss säga att projektets aktiviteter tyvärr dragit ut på tiden och att leveransdatum därför blir svårt att möta. Projektledaren måste då ta upp problemet med en projektbeställare och lyfta fram olika alternativ baserade på förändring av de tre ramarna:

nomföra projektet med oförändrade ramar för tid och kostnad. Ett tredje alternativ skulle kunna visa på hur vi förändrar parametern tid för att bibehålla ramarna för kostnad och resultat. Tyvärr är det svårt att genomföra i praktiken eftersom antal arbetade

Alternativ 1: Projektet skulle kunna

timmar och kostnad ofta hänger intimt

leverera i tid om det fick fler deltagare

samman i projekt. Däremot skulle

till projektgruppen. Det skulle tyvärr

ytterligare ett alternativ kunna vara att

innebära att kostnaden blir högre än

förändra såväl tid som kostnad för att

planerat.

bibehålla resultatet.

Tiden är helig Agila projekt fungerar utifrån timeboxing-principen, alltså att tidsramen i varje steg av projektet alltid står fast. Det innebär att projektgruppen alltid justerar parametern resultat. Tillfällen då planen inte stämmer överens med verkligheten hanteras alltså genom att projektet skär ned på projektets resultat eller omfattning. Somliga reagerar genast på denna princip och säger: "Vad menas med att anpassa resultatet? Då vet man ju inte vad som kommer att levereras? Så går det ju inte att bedriva projekt, framför allt inte ett kundorderprojekt när man redan lovat vad projektresultatet ska innehålla".

Vad är agil projektledning?

15

Läsaren som reagerar på detta vis vill jag uppmana att ta ett djupt andetag och följa med i beskrivningen av det agila arbetssättet: Det agila arbetssättet med timeboxing innebär att projektgruppen i varje kort cykel (eller sprint som har blivit det vedertagna försvenskade ordet) ser tiden som helig. Det innebär att rätt saker prioriteras först och att de saker som inte blir färdiga helt enkelt inte hinns med i den sprinten. Men det förbjuder inte beställaren att senarelägga projektets deadline. Det här ger väldigt tydliga tidiga signaler om hur projektet går. Om projektet bestämmer sig för att jobba med tre-veckors-sprinter och hela projektet förväntas pågå under tio stycken sprinter ser alla hur projektet har gått efter varje tre-veckors-sprint. Visar projektet att endast åtta av de tio inplanerade delmålen har uppnåtts efter en sprint kan verksamheten fatta beslut för hela projektet baserat på projekttriangeln. NÄR ALLA DELMÅL INTE HINNS MED ■ Projektet kan tilldelas fler resurser, motsvarande till exempel tjugo procent, för att hinna med allt arbete. ■ Vissa delresultat av projektet, som planerats in längre fram i tiden, kan tas bort. ■ Projektet kan förvarna mottagare av projektresultatet att det just nu ser ut att behöva ta till exempel tjugo procent längre tid än förväntat.

Denna förändrade helhetsplanering blir alltså enklare med ett timeboxingtänkande eftersom det ger en ärlig och tydlig förvarning. Att tiden är helig handlar om varje kort sprint. För projektets helhet är det upp till beställaren om projektet ska förlängas, förkortas (minska antalet krav) eller få fler resurser för att hinna med alla krav i tid. Projekt där alla arbetat alldeles för hårt med att få alla krav tillgodosedda inför varje deadline får tyvärr ofta problem med projektets kvalitet. För många sena timmar gör lätt att vi som människor tänker fel eller väljer den enklaste lösning som vi kommer på utan att ifrågasätta om det är lämpligt eller inte. Har man istället många korta deadlines vinner dels kvaliteten på att varje sak blir ordentligt gjord, dels blir den negativa effekten av att några krav inte uppnås i tid inte lika stor — eftersom nästa deadline är nära i tiden, bara tre veckor bort. I kapitel 6, om genomförande, berörs närmare hur man prioriterar om tidsbrist uppstår i en sprint.

16

Kapitel i

Faser i projekt En av styrkorna i den traditionella projektledningen är dess tydlighet kring helhet och struktur. Den traditionella projektstrukturen är relevant även för den som väljer att arbeta agilt. Många av dess termer har blivit praxis, men vissa saker har däremot fått flera namn. Därför är det på sin plats att definiera några grundläggande begrepp som kommer att användas i boken för att beskriva projekts olika delar. Traditionellt brukar man dela in ett projekt i olika faser.

Förstudie

Planering Genomförande Överlämning

Avslut

Traditionell projektmodell med typisk indelning i projektfaser. AVSEDDA FÖRDELAR MED ATT DELA IN ETT PROJEKT I FASER: ■ Det är enklare att ha ett begränsat område att fokusera sin energi på än att försöka hantera för många saker på en och samma gång. ■ Genom tydliga steg kan man avsluta en del innan nästa del påbörjas.

Förstudiefas

Förstudie

Planering

Genomförande

Överlämning

Avslut

Förstudien ska ge svaret på vad projektet ska åstadkomma. Här definieras ofta projektets ramar som anger gränser för tid, kostnad och resultat eller omfattning.

Vad är agil projektledning?

17

Planeringsfas

Förstudie

Planering

Genomförande

Överlämning

Avslut

I denna fas ska svar ges på frågan om hur projektet ska genomföras. Resultatet från planeringsfasen är bland annat en tidsplan, en budget, ett organisationsschema och ofta en risklista.

Genomförandefas

Förstudie

Planering

Genomförande

Överlämning

Avslut

Här genomförs projektet för andra gången. Under planeringsfasen genomfördes projektet i teorin men nu genomförs det på riktigt. Här handlar projektledningsarbetet om uppföljning och justeringar.

Överlämningsfas

Förstudie

Planering

Genomförande

Överlämning

Avslut

När projektet är genomfört måste ofta projektresultatet överlämnas till en annan part. Ett kontorskomplex överlämnas till en förvaltande organisation och den nyutvecklade produkten överlämnas till produktionsavdelningen som påbörjar tillverkningen.

18

Kapitel i

Avsluts fas

Förstudie

Planering

Genomförande

Överlämning

Avslut

När ett projekt avslutas innebär det uppstädning och ibland att resurser ska återlämnas och avslutande dokument ska skrivas på. En slutrapport med erfarenheter av projektet skrivs och i ett kundprojekt innebär det kanske att den sista delbetalningen görs.

Beslut vid fasövergångar För varje fasövergång finns ofta en beslutspunkt. Det innebär att styrgruppen eller beställaren måste fatta två beslut: 7. Ska vi påbörja nästa fas? 2. Ska vi avsluta den föregående fasen?

Många ser detta som ett enda beslut (att avsluta en fas för att påbörja nästa). Men för att få bättre kontroll på projektet och dess resurser finns en fördel i att dela upp beslutet i två delar. Ta till exempel ett vägbyggesprojekt som är i slutet av planeringsfasen och arbetsveckan börjar lida mot sitt slut. En asfaltskokare är beställd och kommer dyka upp utanför kontoret måndag morgon då genomförandefasen ska börja. När styrgruppen går igenom dokumentationen som blivit resultatet av planeringsfasen på fredag eftermiddag inser de att dokumentationen behöver förbättras för att kunna godkännas. Om de då ser denna beslutspunkt som ett enda beslut (avsluta planeringsfasen för att påbörja genomförandefasen) kan projektet bli onödigt dyrt. Asfaltskokaren måste då avbeställas och den personal som skulle börjat arbeta på måndagen måste avbokas. Betraktar man fasövergången som två beslut skulle styrgruppen istället, som svar på ovanstående frågor, kunna besluta: 7. Ja, vi påbörjar nästa fas. 2. Nej, dokumentationen behöver förbättras innan vi kan avsluta den föregående fasen.

Vad är agil projektledning?

19

Tyvärr är däremot ofta problemen större än så här. I många projektorganisationer ses beslutspunkten som något som bara passeras istället för ett tillfälle för att fatta verkliga beslut om påbörjande och avslut.

Flexibilitet vid fasövergångar Genom att tänka i termer av faser och genom användande av beslutspunkter får projektet ofta struktur och bättre möjlighet till god styrning. Det finns emellertid också en risk med det här synsättet, nämligen att man får en förenklad uppfattning om projekt som något som går i prydliga, exakta steg och att om projektet inte följer dem så är det tecken på att det sköts dåligt. Med en styrgrupp som lägger för stor vikt vid att projektet ska följa dessa exakta steg kommer projektledaren mest av allt eftersträva att projektet ska följa den här mallen. "Men varför är det så dåligt?" kanske då blir den naturliga följdfrågan. Låt oss säga att vi har ett projekt med målet att ta fram den grymmaste cykeln någonsin. Vi vet att konkurrenten Superbike är på väg att skapa en ny cykeltyp så det är bråttom. Vår produkt måste både vara bättre och komma ut i tid. GrymCykelprojektet behöver planera för fyra olika delar: ram, växlar, styre och hjul. Under planeringsfasen inser projektledaren att underleverantören inom två månader kommer ut med ett nytt växelsystem som kommer att slå världen med häpnad och som skulle kunna användas i projektet. Projektledaren kan därför inte planera klart projektet under planeringsfasen eftersom hen skulle vilja ha med det nya växelsystemet i GrymCykelprojektet. När hen föreslår att hen skulle vilja köra igång projektet utan att ha en viktig del av projektet planerad fnyser styrgruppen och säger: "Är inte planeringsfasen klar kan vi ju inte starta genomförandefasen, det förstår du väl". Bedrövad planerar hen därför in användandet av det befintliga, sämre, växelsystemet i projektet - för att få planeringen godkänd och tillåtelse att påbörja genomförandefasen. Denna brist i synsättet på projekt - som en serie av distinkta faser - är en av de saker som fått den agila rörelsen att vända sig emot det traditionella sättet att driva projekt.

20

Kapitel i

Sammanfattning Agil betyder smidig och huvudprincipen i agil projektledning handlar om flexibilitet och en strävan att hela tiden förbättra sitt projektarbete. Det åstadkoms genom att ha korta sprinter som består av cykler av att planera, utföra, kontrollera och därefter handla utifrån dragna slutsatser. I agil projektledning ruckar man inte på sprinternas längd och tack vare att arbetet delas upp i sprinter blir det tidigt synligt om resultatkrav och tidsramar är rimliga. Agil projektledning handlar inte så mycket om projektledaren som beslutsfattare utan om att få gruppen att leda projektet genom att få mandat och bli självgående. Projektledarens huvudfokus blir istället att undanröja hinder för att få gruppen att bli så effektiv som möjligt.

Övningsboken: I övningsbokens kapitel 7 hittar du två övningar som handlar om att identifiera er

Agil piajeMtledning

ÖVNINGSBOK

mognadsnivå för agil verksamhet. Där finns såväl en individuell övning som en gruppövning för att på ett enkelt sätt "mäta" er agila mognad.

Vad är agil projektledning?

21

Det agila manifestet och metodernas historia

Vad var det i det traditionella sättet att driva projekt som inte fungerade och som gjorde att behov av nya, agila metoder föddes? Hur uppkom arbetssättet Lean och hur förhåller sig agil projektledning till det? Något förenklat kan man säga att de agila metoderna har utvecklats både som en motreaktion till den traditionella projektledningen, och med värderingarna i Lean som inspiration och förebild. Att känna till denna bakgrund är en nyckel till att förstå de agila principerna.

24

Kapitel 2

Projektledningens historia De flesta metoder, verktyg och arbetssätt som används vid traditionell projektledning kommer från det kalla krigets dagar. Den typiska tidpslanen, Gantt-schemat, är ännu äldre. Det utvecklades i samband med stora infrastrukturbyggen i USA, så Historien flyter inte fram i en stor tidigt som på 1910-talet. Syftet med de projektledflod utan i många små bäckar. ningsmetoder som togs fram (Alberto Moravia) efter andra världskriget var att slutföra försvarsprojekt innan "den andra sidan" hann före. Nato tävlade mot Warszawapakten inom allt från rymdfärder till att vara först med långdistansmissiler. Huvudfokus var alltid ledtiden, alltså den kalendertid det tar från att påbörja ett projekt till att avsluta ett projekt. Ju fler aktiviteter som kunde utföras parallellt desto kortare kunde ledtiden bli för projektet.

pp

Stora projekt, stora resurser Vissa av de gigantiska militärprojekten involverade över 200 000 forskare, ingenjörer och militärer. Resurserna var näst intill oändliga och projektledarnas utmaning var att koordinera denna stora mängd personer, aktiviteter, material och kapital. De verktyg som togs fram under denna era syftade också främst till minimering av ledtiden och koordinering. Hit hör Work Breakdown Structure (WBS) och logiska nätverk med kritiska linjens princip. Samma principer används i dag i stora projekt då exempelvis företaget Ericsson ska "rulla ut" en ny generations mobiltelefonisystem i ett land. På mindre än 24 månader ska projektet växa från ett fåtal individer som genomför förstudien till uppåt 2 000 individer under den mest hektiska fasen. Projektarbetsstyrkan minskar sedan för att avvecklas helt och hållet med en ensam projektledare som lämnar över de sista dokumenten.

Fler och mindre projekt De traditionella verktygen för planering och uppföljning lärs idag ut i projekt av alla sorter. Men den främsta styrkan hos dessa verktyg (att koordinera ett stort antal människor och få så kort ledtid som möjligt genom parallellisering av många aktiviteter) kommer till nytta för endast ett fåtal typer av projekt. Faktum är att man idag jobbar projektorienterat i väldigt skilda verksamheter

Det agila manifestet och metodernas historia

25

och antalet projektdeltagare i projekten blir färre och färre. Forskaren Roland Gareis pekade redan 1990 i sin "Handbook of management by projects" på hur projekten blir fler och fler och att storleken på projekten, sett till antalet projektdeltagare, krymper.

Nya projekttyper, nya behov Men trots att projekten minskat i storlek fortsätter de flesta projektledare att planera och följa upp med samma verktyg som tidigare. Projektledare skickas på kurser för att lära sig att parallellisera projektaktiviteter och kommer tillbaka till sin fem-mannagrupp där aktiviteterna oftast måste genomföras i sekvens, och där alltså möjligheterna till parallellisering eller annan koordinering för att förkorta ledtiden är få. Inom systemutvecklingsbranschen har det därför uppstått en motreaktion till de traditionella projektledningsmetoderna. Denna motreaktion har uppkommit eftersom projektdeltagare ansett sig hindrade snarare än hjälpta av de befintliga projektledningsmetoderna. Systemutvecklingsbranschen upplevde framför allt de traditionella metoderna att driva projekt som oerhört statiska och tröga. De sökte efter sätt att fortsätta producera it-system med hög kvalitet och med någon form av projektledning som gav dem riktigt stöd. Metodutvecklare började därför leta efter tekniker som skulle kunna hantera större flexibilitet, det vill säga ge möjlighet att förändra krav löpande men med bibehållen kontroll och kvalitet. Utifrån detta behov formades de agila metoderna.

Lean Arbetssättet som i Japan kallas Toyota Production System (TPS) har i resten av världen fått namnet Lean efter engelskans smärt, slimmad, fettsnål. Toyota, och många andra japanska företag, tvingades efter nederlaget i andra världskriget att hitta effektiva och billiga lösningar för att kunna konkurrera med resten av världen. De projekt som startades i Japan under denna tid hade omständigheter som var motsatsen till den situation som Nato och Warzawa-pakten upplevde. Istället för att ha näst intill oändliga resurser tvingades man i Japan hitta lösningar som kostade så lite som möjligt. Istället för att koordinera mängder av människor tvingades man få ut så mycket som möjligt från varje liten arbetsgrupp.

26

Kapitel 2

De agila metoderna har hämtat mycket inspiration från den japanska bilindustrin, dess värderingar och tekniker och inte minst dess metoder att få ut så mycket som möjligt med små resurser. För det räcker inte att bara uppnå flexibilitet, som de agila metoderna skapades för. Det behövs även effektivitet och det är styrkan i de metoder som kallas Lean. Att arbeta enligt Lean innebär att anamma ett antal värderingar. Mary och Tom Poppendieck, som överfört Lean till mjukvaruindustrin, har valt ut de viktigaste. De ger en god summering av vad Lean innebär. CENTRALA VÄRDERINGAR I LEAN • Eliminera slöseri. a Fokusera på lärande. • Skjut på åtagande. B Leverera snabbt. • Respektera människor. I Optimera helheten.

Eliminera slöseri All tid som inte genererar värde för slutresultatet är slöseri. Det innebär att all sorts väntan är slöseri. Om till exempel ett godkännande från chefen för designavdelningen behövs för att arbetet ska kunna gå vidare, är varje sekund från det att förslaget lämnats till dess att besked om godkännande ges, att betraktas som slöseri. Detta är grundläggande för Lean och naturligtvis viktigt i en verksamhet som Toyotas, där bilar ska framställas på löpande band. Men oavsett om arbete sker vid löpande band eller i projektform kan eliminering av slöseri leda till fantastiska förkortningar av ledtid. Om man i ett projekt exempelvis låter en testare av en ny motorsåg jobba tillsammans med teknikern kan man helt slippa all väntan. Testaren kan direkt visa vad som gått snett och teknikern kan omedelbart arbeta med en lösning.

Fokusera på lärande Det är alltid tillåtet att misslyckas en gång. Om man aldrig misslyckas betyder det att man inte provat alternativa tillvägagångssätt. Om man misslyckas två gånger betyder det att man inte lärde sig av misstagen från

Det agila manifestet och metodernas historia

27

första gången. Det är filosofin inom Lean som gett upphov till det japanska uttrycket kaizen och som betyder ständigt lärande (eller ständig förbättring). Kaizen innebär att gruppen ska ges tid och plats för att stanna upp, reflektera och besluta om förändringar som gör att arbetet blir effektivare.

Skjut på åtagande Åtagande kan vara fantastiskt. När en grupp människor tar sitt ansvar på allvar och själva tror på att de kan nå högt uppsatta mål, kan man tala om verkligt åtagande som har betydelse. Men det finns en risk med åtagande och det är att man blir för fäst vid ett tidigt beslut så att man får svårt att acceptera förändringar av beslutet. Lean-principen att skjuta på åtagande handlar om att inte fatta beslut förrän man är så nära som möjligt att genomdriva beslutet. Om man godkänner en tidsplan trots att man inser att dess slutresultat skulle bli mycket bättre om man jobbade några veckor längre än planerat, vad är då viktigast? Att följa planen eller att bryta mot planen och få ett bättre slutresultat? Synsättet att planer är detsamma som åtagande skapar många problem i organisationer. Ett åtagande som kommer så sent som möjligt har bättre möjlighet att efterlevas eftersom målet då är närmare i sikte, inte långt bort i fjärran.

Leverera snabbt När gruppen väl fattat ett beslut och har ett tydligt åtagande om att genomföra en uppgift ska den agera så snabbt och effektivt som möjligt. Anledningen till det är bland annat att vi människor har lätt för att glömma. För varje sekund som tiden går från det fattade beslutet till att vi genomför arbetet och levererar resultat desto större risk finns det både för att omvärlden har förändrat villkoren och att vi börjar glömma detaljer kring det fattade beslutet.

Respektera människor På Toyotas löpande band hänger ett antal gula stroppar. Alla medarbetare kan, genom att dra i en gul stropp, stoppa det löpande bandet. Att stoppa bandet medför naturligtvis enorma kostnader. I många organisationer skulle ett så dyrt beslut behöva godkännande från högre ort men på Toyota tror man att den som är närmast problemet har bäst kännedom om vilket som är det rätta beslutet. Ett sådant system är att i praktiken respektera människor och deras kompetens.

28

Kapitel 2

Optimera helheten Det är ofta lätt att gå in i en liten del av verksamheten och optimera processen eller arbetssättet i den delen. Tyvärr kan det ofta skapa större problem än nytta. Om en organisation lyckas fördubbla sin produktionshastighet men fortfarande säljer i samma takt som tidigare kommer lagret att växa för varje dag som går. Att optimera helheten handlar om att få hela kedjan att bli effektivare och att hitta och ta bort de flaskhalsar som stoppar upp processen.

De agila metoderna växer fram De agila metoderna härstammar från it-branschen. Det finns exempel på metoder som skulle kunna kallas agila inom IBM:s verksamhet redan 1957 men det egentliga startskottet kom 1974 då E. A. Edmonds i en artikel beskrev ett inkrementellt och iterativt arbetssätt. Ett inkrementellt arbetssätt innebär att man löpande skapar färdiga, användbara delar (inkrement) av värdeskapande projektresultat. Ett iterativt arbetssätt betyder att arbetet utförs i cykler (iterationer) där man i varje cykel förbättrar och utvecklar det

Det agila manifestet och metodernas historia

29

redan befintliga projektresultatet. En agil metod innebär nämligen att den både är inkrementell och iterativ. Förutom att delleverera resultat löpande, där kloss läggs till kloss, har agila metoder en process för att undersöka och förbättra eller förändra de klossar som redan är färdiga.

Föregångarna och de första agila metoderna Tyvärr tog inte dessa 70-talsideer fäste på särskilt många arbetsplatser, men här och var började metoder dyka upp som byggde på de inkrementella och iterativa tankarna. För systemutvecklingsprojekt inom it-branschen var exempelvis RAD (Rapid Application Development) på ropet under några år och den mest utbredda metoden som fortfarande har ett visst fotfäste inom it-projekt är RUP (Rational Unified Process).

AGILA VERKTYG I RUP Metoden RUP har svensken Ivar Jacobsen som en av sina upphovsmän. Till skillnad från de agila metoderna har RUP ett omfattande dokumentationsramverk med många typer av mallar för att arbeta med systemutveckling. Inom RUP är dessa dokument (eller artefakter som den korrekta termen lyder) att betrakta som en verktygslåda. RUP är i sin ursprungliga form inte en agil metod men flera av dessa dokument används idag i agila projekt, eftersom de kan ge ett bra kompletterande stöd i det agila arbetssättet. .111111ffiliM23

Många användare av RUP uppskattade arbetssättet kring inkrement (att bygga färdiga bitar steg för steg) och iteration (att i varje steg förbättra och bygga ut den tidigare lösningen) men upplevde problem med att ha ett traditionellt synsätt kring milstolpar som styrde projekten. En milstolpe uttrycks genom att en viss mängd resultat ska vara färdigt vid en viss tidpunkt och projekten upplevdes ofta väldigt stressande då milstolparna blev fler och tätare i projektet. Ett alternativt arbetssätt — den agila approachen, var att istället se tiden som helig och att istället för milstolpar styra efter uppsatta förbestämda tidsrymder (exempelvis tre veckor långa

3o

Kapitel

2

sprintar). Under den här perioden sneglade många åt Lean och dess grundtankar kring att eliminera slöseri blev en inspiration till att skapa nya, effektivare metoder. Det var först under 90-talet som de metoder vi kallar agila började ploppa upp som svampar ur jorden. Den idag mest kända metoden, Scrum, skapades inte förrän 1995 och efterföljdes av Dynamic Systems Development Model (1995), eXtreme Programming (1996), Crystal Clear (1996) och en rad andra metoder som fått mer eller mindre spridning.

Scrum Scrum betyder klunga på svenska. Det är en rugbyterm som refererar till den klunga båda lagen bildar runt bollen när spelet startas om i en rugbymatch (motsvarande uppkast eller tekning i andra sporter). Att en agil metod fått detta namn från idrotten har sin bakgrund i att grundarna Ken Schwaber och Jeff Sutherland med sin metod utgick från en artikel skriven av två Harvardforskare (Hirotaka Takeuchi och Ikujiro Nonaka, 1986) som baserades på fältstudier av framgångsrika företag inom fordons-, dator-, kopiator- och skrivarbranscher. I artikeln argumenterade forskarna för att dessa företag hade en rugbyapproach eftersom de lät ett sammansvetsat, effektivt team med blandad kompetens arbeta tillsammans genom alla faser vid framtagandet av ett projektresultat — istället för att låta projektet överlämnas mellan grupper med olika kompetens. Att ha ett effektivt, självgående team har blivit signifikant för agila metoder och den självgående projektgruppen har därför kallats scrum team.

Agile myntas Det var inte förrän i februari 2001 i den lilla skidorten Snowbird i Utah som benämningen agil kom till. 17 metodutvecklare som representerade olika agila metoder samlades för att diskutera det som under den tiden gick under namnet lättrörliga eller lättviktiga metoder. De ansåg att ett gemensamt namn och gemensamma värderingar för dessa metoder behövdes. Ett namnförslag var Adaptable (anpassningsbar på svenska) men eftersom anpassning signalerar något som sker retroaktivt, en anpassning till något som varit, förkastades detta namn. Begreppet Agile, alltså smidig eller rörlig, blev det framröstade namnförslaget. I Sverige är, sedan ett antal år, det försvenskade ordet agil den vedertagna benämningen för metoderna.

Det agila manifestet och metodernas historia

31

Det agila manifestet Under mötet i Snowbird enades gruppen om ett antal principer för hur agil mjukvaruutveckling skulle bedrivas. Resultatet blev det agila manifestet och de tolv principerna som förtydligar manifestet.

DET AGILA MANIFESTET Agil projektledning prioriterar: Individer och interaktioner

framför

processer och verktyg.

Användbart projektresultat

framför

omfattande dokumentation.

Kundsamarbete

framför

kontraktsförhandling.

Anpassning till förändring

framför

att följa en plan.

Det vill säga, medan det finns värde i punkterna till höger, värdesätter vi punkterna till vänster mer.

Texten i rutan kommer från den svenska översättningen på www.agilemanifesto.org förutom den andra punkten som anpassats för att passa andra branscher än mjukvaruindustrin (i originalet anges "fungerande programvara" istället för "användbart projektresultat"). Vad menas då med att "Det vill säga, medan det finns värde i punkterna till höger, värdesätter vi punkterna till vänster mer"? Var och en som någon gång upplevt frustrationen av att sitta på ett möte med ett dokument som man vill få feedback på, men istället bara får pekpinnar om stavningen, förstår innebörden av det agila manifestets prioritetsordning. Skillnaden mellan vad man själv och andra värderar högt kan vara stor. De flesta håller med om att såväl innehåll som stavning är viktiga för kvaliteten i dokumentation. Men i de flesta verksamheter finns det inget regelverk och ingen vägledning som säger att det ena är viktigare än det andra. Felet i dagens projektledning är, menar agila förespråkare, att det saknas stöd åt projektledare för att göra den här typen av prioriteringar. De menar att projektledare oftare bedöms utifrån om de "gissat rätt" (uppskattningen av när projektet ska vara klart och vad det kommer att kosta) än att projektresultatet blir bra.

32

Kapitel 2

Ett sådant regelverk uttrycks däremot i det agila manifestet. Det säger att aktiviteterna på vänster sida är viktigare att fokusera på än de på höger sida. Om det inte fanns språkpoliser som månar om korrekt stavning skulle många dokument onekligen bli svåra att läsa. Men det är ännu viktigare att innehållet i ett dokument är vettigt och att det i första hand hjälper verksamhetens arbete. Punkterna i manifestet beskriver olika delar av vad agil projektledning innebär.

Individer och interaktioner framför processer och verktyg Hur projektgruppen är sammansatt och hur personerna kan samarbeta måste föregå vilka processer och verktyg som gruppen behöver. För att förstå vad det betyder kan ett exempel på motsatsen behövas: Om processer och verktyg skulle vara viktigare än individer och interaktioner skulle projektgruppen alltid följa en uttalad mall för den exakta processen och för de givna verktygen - oavsett gruppsammansättningen. Det betyder att gruppen skulle kunna luta sig tillbaka och i de tillfällen då något gått snett kunna säga: "Vadå? Vi följde ju bara processen? Det kan ni ju inte hålla oss ansvariga för?" Den här punkten innebär alltså att projektgruppen ansvarar för att arbetet utförs

DEMINGCYKELN: PLAN, DO, CHECK, ACT För att projektgruppen ska kunna ta ansvaret för lokal anpassning av metoder, processer och projektmodeller behöver den mandat och förtroende att prova, förändra och utvecklas löpande i projektet. Detta sker genom en i förväg uttalad cykel av att testa, utvärdera och anpassa arbetssättet. Den process för detta som många refererar till brukar kallas Demingcykeln, eller PDCA-cykeln, utvecklad av Edward Deming på 50-talet. Bokstäverna står för Plan, Do, Check och Act (planera, utföra, kontrollera och handla). Det innebär i agila projekt att hela arbetet delas in i korta cykler eller sprintar där projektgruppen tillåts stanna upp, reflektera, och förändra sitt arbete med som mest en månads mellanrum.

Det agila manifestet och metodernas historia

33

med bästa möjliga process och verktyg. Det betyder inte att agila projekt inte kan följa en uttalad process inom organisationen, det betyder bara att projektdeltagarna är ansvariga för att göra de modifieringar av eller avsteg från processen som behövs för att bli så framgångsrika som möjligt. Den andra punkten i manifestet är: "Fungerande programvara framför omfattande dokumentation". Formuleringen kommer sig av att det agila manifestet ursprungligen skrevs för projekt i it-branschen. Men manifestets innebörd kan tillämpas i alla branscher och punkten kan därför omformuleras i mer generella termer:

Användbart projektresultat framför omfattande dokumentation Det viktiga är alltså att se till att resultat produceras löpande i projektet. Arbetet delas in i korta cykler (sprintar), och varje sprintstart ger möjlighet till kontroll och förändring. I varje arbetscykel är strävan att leverera ett delresultat som är så färdigt som möjligt. Man siktar alltså inte in sig på en enda leverans långt fram i tiden, där resultatet först då ska bli användbart. Istället ska projektgruppen leverera användbart resultat löpande under hela projektet. Hur tidigt användbart resultat kan levereras varierar naturligtvis. Ett projekt med syftet att sätta upp en musikkonsert går naturligtvis inte att slutföra vid en tidigare tidpunkt än själva konserten. Däremot kan varje del av förberedelserna slutföras i många korta steg där varje steg kan innebära nytta. (Bokade bandnamn kan användas i marknadsföringen, försäljning av förköpsbiljetter kan användas för att få fler sponsorer.) Det gör att motivationen inom projektgruppen ökar då de ser resultat löpande genom projektet. Eventuella beställare kan också de vid varje stopp se vilka resultat som har uppnåtts. Genom att göra varje sprints arbete helt klart, blir det faktiskt också möjligt att avsluta projektet när som helst. Den tredje punkten i det agila manifestet är:

Kundsamarbete framför kontraktsförhandling De flesta kan nog skriva under på att de hellre vill ha ett fungerande kundsamarbete än kontraktsförhandlingar. I undersökningar kring framgångsfaktorer i projekt hamnar alltid kund- och/eller beställarsamarbete i topp. (Exempelvis Standish Groups rapporter som

34

Kapitel 2

kallas Chaos Report på www.standishgroup.com). Detta har man inom projektledning vetat länge, så vad är då specifikt eller nytt inom det agila? Den traditionella projektledningen har tyvärr bara talat om att kundsamarbete är viktigt men inte hur det ska kunna uppnås. Inom agil projektledning däremot, görs ett kort stopp efter varje sprint, då projektgruppen visar upp det delresultat som åstadkommits och låter kunden se, känna på och diskutera projektresultatet. Detta görs med som mest en månads mellanrum vilket gör att kunden under hela projektet är närvarande och har möjlighet att påverka projektet. (Kund kan i det här fallet innebära såväl en intern kund, eller beställare, som en verklig slutkund - beroende på typ av projekt.) Den fjärde punkten i det agila manifestet lyder:

Anpassning till förändring framför att följa en plan Inom agil projektledning utgår man ifrån att det är lönlöst att försöka förutse exakt hur allting blir i framtiden. Man förutser att planer som skrivs innan ett projekt startas troligtvis kommer att behöva justeras allteftersom projektresultatet växer fram, eftersom omvärlden förändras och kunden eller beställaren löpande får insikter kring hur projektresultatet ska bli ännu bättre. Det är naturligt att förändras och vägen till att skapa fantastiska projektresultat är inte att spendera ytterligare en månad på att planera projektet utan att ha en process som möjliggör, och även välkomnar, förändringar. Det innebär däremot inte att förändringar kan ske hur som helst. Skulle förändringar genomföras hur som helst i ett projekt skulle förmodligen kaos uppstå och projektarbetet skulle bli ineffektivt. Den agila principen är därför att i första hand lägga energi på att leta efter förändringsförslag vid varje stopp som de återkommande arbetscyklerna innebär. Om varje arbetscykel är tillräckligt kort - mindre än en månad och gärna bara ett par veckor - kan beställaren låta projektgruppen arbeta effektivt utan förändringar under den korta cykeln. Men för den skull är det inte förbjudet att tillåta ändringar även löpande, när som helst i projektet. Bara beställaren förstår konsekvenserna av förändringen och tar på sig sitt ansvar att vissa påbörjade delresultat kanske måste kastas på grund av förändringen så är det inga problem. Beställaren har alltid sista ordet kring förändringar, när som helst i projektet.

Det agila manifestet och metodernas historia

35

De 72 agil a principerna För att förtydliga det agila manifestet, som visar agila värderingar, beskrevs 12 principer som skulle visa hur värderingarna ska efterlevas. I sin ursprungsform kretsar principerna kring begrepp som programvara och utvecklare - eftersom de formulerades av metodutvecklare inom it. Dessa termer kan dock ersättas med de mer generella benämningarna projektresultat och projektdeltagare, vilket visar att tankegångarna kan tillämpas på projekt även inom andra områden. Nedan återges det agila manifestets förklarande principer i sin ursprungsform, fritt översatta från engelskan. Inom parentes står de mer generella termer som gör principerna användbara för de flesta typer av projekt.

36

Kapitel 2

7. Vår högsta prioritet är att tillfredsställa kunden genom tidig och kontinuerlig leverans av värdefull programvara (värdefullt projektresultat). 2. Välkomna förändrade krav, även sent under utvecklingen. Agila metoder utnyttjar förändring till kundens konkurrensfördel. 3. fungerande programvara (användbart projektresultat) ofta, med ett par veckors till ett par månaders mellanrum, ju oftare desto bättre. 4. Verksamhetskunniga och utvecklare (projektdeltagare) måste arbeta tillsammans dagligen under hela projektet. 5. Bygg projekt kring motiverade individer. Ge dem den miljö och det stöd de behöver, och lita på att de får jobbet gjort. 6. Kommunikation ansikte mot ansikte är det bästa och effektivaste sättet att förmedla information, både till och inom utvecklingsteamet (projektgruppen). 7. Fungerande programvara (användbart projektresultat) är främsta måttet på framsteg. 8. Agila metoder verkar för hållbarhet. Sponsorer, utvecklare (projektmedlemmar) och användare ska kunna hålla jämn utvecklingstakt (arbetsbelastning) under obegränsad tid. 9. Kontinuerlig uppmärksamhet på förstklassig teknik och bra design stärker anpassningsförmågan. lo. Enkelhet - konsten att maximera mängden arbete som inte görs - är grundläggande. 77. Bäst arkitektur, krav och design växer fram med självorganiserande team. 72. Med jämna mellanrum reflekterar teamet över hur det kan bli mer effektivt och justerar sitt beteende därefter.

Det agila manifestet och metodernas historia

37

En anpassningsbar metod Under de senaste åren har fler och fler företag inom vitt skilda branscher börjat anamma de agila värderingarna - i mer eller mindre renlärig form. De tolv principerna är inte odelbara utan kan variera i betydelse beroende på bransch och projekttyp. Att anamma ett agilt förhållningssätt behöver alltså inte betyda att man strängt och strikt tillämpar samtliga tolv principer. För ett projekt som går ut på att bygga en ny förskola är till exempel princip nummer fyra central: Att förskolepersonal, alltså personer med gedigen kunskap om verksamheten, ska involveras kontinuerligt i projektet. Detta för att kunna ge input och agera testare under arbetets gång. Däremot kan princip nummer tre tolkas lite friare för det här projektet: projektresultatet som ska levereras löpande kan kanske i detta fall inte anses vara användbart förrän helheten är på plats. (Det är svårt att bedriva förskoleverksamhet, ens för några få barn, på endast en gjuten husgrund.) För ett kommunalt projekt som går ut på att minska ungdomsarbetslösheten är princip nummer nio, om hur förstklassig teknik och bra design stärker anpassningsförmågan, av mindre betydelse. Däremot är princip nummer sju för samma projekt av högsta relevans: Projektets framsteg visar sig i stigande sysselsättningsgrad bland kommunens ungdomar - inget annat. Det är inte antalet företagssponsorer som knutits till projektet, det är inte de tjusiga powerpointpresentationerna som kommunens ansvariga visar upp och det är inte heller kommunens ökade skatteintäkter som utgör mått på projektets framsteg.

Principerna ger vägledning I viss mån låter det agila manifestets tolv förklarande principer som vanligt sunt förnuft. Men många som arbetar i traditionellt ledda projekt kan vittna om att det sunda förnuftet ofta brister. Fokus förloras lätt så att man glömmer ta in åsikter från verksamhetsnära personer och så att onödigt arbete bedrivs för att man glömmer bort vad användbart projektresultat egentligen är. Ändrade krav från beställaren mottas med förvåning och motstånd - trots att risk för förändrade omständigheter är verkligheten för alla projekt. Listan över sätt på vilka projekt kan gå fel kan tyvärr göras lång. Att ha principer som dessa formulerade hjälper alla involverade i projektet att bli medvetna om när projektarbetet börjar slira iväg åt något håll, så att felen kan rättas innan de egentligen uppstått. De agila

38

Kapitel 2

metoderna är sällan helt nydanande men kan helt enkelt sägas vara effektiva paketeringar av sunda principer för att driva projekt framgångsrikt.

Declaration of Interdependence (D01) År 2005 skrevs en avsiktsförklaring av 15 projektledare tillika metodexperter (varav flera var med vid författandet av det agila manifestet) som döptes till Declaration of Interdependence (DOI). På svenska betyder det ungefär "avsiktsförklaring om ömsesidigt beroende". Det ömsesidiga beroendet har flera betydelser. Dels pekar det på beroendet mellan projektgrupp, kunder och andra intressenter men även det ömsesidiga beroendet mellan individerna i en projektgrupp. De menade att projekt som inte förstår dessa ömsesidiga beroenden sällan kommer att bli särskilt lyckade. DOI liknar det agila manifestet genom att det beskriver viktiga principer, men riktar sig till projektledare. Avsiktsförklaringen är presenterad som ett förslag för andra projektledare att acceptera och skriva under på. Översatt till svenska lyder de sex principerna i DOI enligt följande: Vi är ett nätverk av projektledare som levererar resultat på ett mycket framgångsrikt sätt. För att uppnå det: ■ Ökar vi avkastningen på kundens investeringar genom att ha kontinuerliga leveranser av värdeskapande projektresultat i fokus. ■ Levererar vi pålitliga resultat genom att engagera kunder genom täta kontakter och delat ägarskap av slutresultatet. ■ Förväntar vi oss osäkerhet och hanterar osäkerheten genom att lyssna på intressenters förväntningar, arbeta i iterationer och anpassa projektresultatet genom hela processen. ■ Släpper vi loss kreativitet och innovation genom att erkänna att individer är den yttersta källan till värde. Därför skapar vi en miljö där de kan göra en skillnad. ■ Ökar vi gruppens prestationsförmåga genom att tilldela gruppen ansvaret för resultatet och låter hela teamet ansvara för teamets effektivitet. ■ Förbättrar vi effektiviteten och tillförlitligheten genom att situationsanpassa strategier, processer och metoder.

Det agila manifestet och metodernas historia

39

DOI sammanfattar på ett enkelt och tydligt sätt vad det agila arbetssättet innebär genom att lyfta fram viktiga principer för projektledare som behövs för att efterleva de agila värderingarna.

Sammanfattning De flesta verktyg för projektledning härstammar från kalla krigets dagar och skapades för att koordinera stora mängder resurser för att få så kort ledtid (kalendertid) som möjligt. Toyotas processer och verktyg för att effektivt producera bilar kallas Lean och kommer från en omvänd situation jämfört med verktygen från traditionell projektledning. De har utgångspunkten att med mycket knappa resurser få bästa möjliga resultat. Detta åstadkommer Toyota framför allt genom att eliminera resursslöseri. De agila metoderna kommer ursprungligen från it-branschen och har utvecklats genom: ■ Krav på ökad flexibilitet - för att sådana projekt är svåra att förutse och svåra att ställa rätt krav på från början. ■ Motreaktioner till traditionell projektledning - då många upplevt att de inte fått tillräckligt med stöd i de verktyg som erbjudits. ■ Inspiration från Lean - som utgår från effektivitet i varje litet steg och att få ut det mesta av varje människa.

40

Kapitel 2

• Roller

Det agila synsättet förespråkar att en grupp aldrig ska vara större än att alla kan se varandras ögon, eftersom stora grupper försvårar kommunikation och beslut. För att det agila arbetssättet ska realiseras är det också avgörande att hitta rätt sammansättning av kompetens i gruppen och att ansvar och funktioner fördelas så att man blir så lite beroende av enskilda personers expertis som möjligt. De flesta roller som är typiska för agila metoder kommer från metoden Scrum där också den självstyrande projektgruppen är central.

42

Kapitel 3

Gruppen Att se gruppen som en egen lednings- eller beslutsnivå är kärnan i det agila sättet att hantera projektgruppen. Den agila projektmetoden Scrum har fått sitt namn efter det engelska ordet för den klunga som ett rugbylag formerar då bollen sätts i spel. Varför försöker metodförespråkaren Ken Schwaber (2004) då likna sin agila metod med ett rugbylag? Jo, det är för att ett rugbylag arbetar enligt principer som också präglar den agila projektgruppen. KÄNNETECKEN HOS EN AGIL PROJEKTGRUPP ■ Självstyre - även om en lagkapten har ett ledaransvar så har varje

spelarposition sina egna ansvars- och befogenhetsområden på sin position. ■ Tydliga mål - alla i faget vet att bollen ska över till andra sidan planen

och att det viktigaste är att göra flest mål. ■ Kollektivt ansvar - alla är ansvariga för och hjälps åt att vinna

matchen oavsett individuella ansvarsområden. Detta funktionssätt genomsyrar såväl rugby som metoder för agil projektledning.

Storlek

Den bästa chefen är den som har omdöme nog att välja skickliga personer till att göra det han vill ha gjort, och självbehärskning nog för att avhålla sig från att lägga sig i deras arbete medan de gör det.

Många projektledare klagar på svårigheten i att ha kontroll över sitt projekt när antalet deltagare blir för stort. Det blir svårt att ha fingertoppskänsla (Theodore Roosevelt) för hur projektet ligger till om de inblandade är många. Om någon aktivitet haltar eller om ett problem plötsligt dyker upp hör man ofta projektledare säga: "Men varför har jag inte fått höra om det här problemet

tidigare?" Det agila synsättet förespråkar att en grupp aldrig ska vara större än att alla kan se varandras ögon. Synsättet betyder att vi inte får vara fler än att vi kan sätta oss ned tillsammans, se varandra i ögonen och föra en diskussion med varje individ i vår grupp. Såväl romare som azteker ordnade in sina minsta militära enheter i mindre än tio personer av precis samma

Roller

43

anledning. Den optimala gruppstorleken för effektivitet brukar, beroende på vilken författare inom grupputvecklingsteori man frågar, sägas ligga mellan fem och nio individer. Blir behovet av antalet projektdeltagare större bör gruppen delas upp i flera grupper där varje grupp har sitt uttalade ansvarsområde.

Tvärkompetens Men antalet individer är inte det enda viktiga för att få en effektiv grupp. Enligt det agila synsättet är det viktigt att gruppen innehåller all nödvändig kompetens. Projekt har tyvärr ofta en tendens att bli kraftigt försenade på grund av väntan på resultat som ska levereras utifrån. Varje sådant externt beroende medför en ökad risk för projektet. Det är därför viktigt att gruppen, så långt det är möjligt, har kompetensen att själva lösa problemet. Gruppen får därför inte heller vara för liten. För att höja gruppens effektivitet ännu mer eftersträvar man i agila sammanhang att varje gruppmedlem har tvärfunktionell kompetens. Några må ha specialistkompetens, men alla förväntas ha tillräckligt bred kompetens för att hjälpa till om problem uppstår. En grundläggande förutsättning för samarbete och flexibilitet är att varje individ i gruppen har förmågan att hjälpa till där det så behövs. Betyder det då att vi vill ha ett gäng generalister? Nej, bara att människor är tillräckligt breda i sin kompetens för att hjälpa varandra. På engelska kallas detta "T-shaped people" (T-formade människor), där det vertikala strecket i T:et står för den specialistkompetens man har, och det horisontella strecket den bredd man har. Med för lite bredd blir det ett I istället för ett T. I metoden Scrum går man så långt att man säger att ingen i gruppen ska ha någon speciellt utsedd roll. Anledningen är att man vill behålla gruppåtagandet och se hela projektresultatet som ett gemensamt ansvar. Resonemang såsom: "Jo, men det problemet kan inte jag göra något åt eftersom jag är designer" borgar för en stelbent projektgrupp och bör i mesta möjliga mån undvikas.

Att bli fler har ett pris Ett antagande inom agila projekt är att det är svårt att ta in nya medlemmar i projekt och få dem produktiva. Det är förvisso lätt att hamna i synsättet: "Med ytterligare en medlem i projektgruppen borde vi hinna leverera i

44

Kapitel 3

tid". Men man får inte glömma att det är resurskrävande att ta in en ny projektmedlem som ska sättas in i arbetsuppgiften och bli produktiv. Ett andra antagande är därför att projektgruppen bör behållas så intakt som möjligt. Med det menas inte att projektledare i agila projekt tackar nej till ytterligare resurser utan att agila projektledare har respekt för den komplexitet ytterligare projektmedlemmar innebär för ett väl fungerande team. Detta synsätt skiljer sig från traditionella projektledningsmetoder där synsättet rätt man på rätt plats tyvärr gjort att man underskattat de fördelar som finns med ett väl fungerande lag. I en jämförande undersökning av 50 produktutvecklingsteam som gjordes av Ralph Katz 1982 visade han att team som får jobba tillsammans är som mest produktiva från att de arbetat tillsammans i två år fram till fem år utan att förändras särskilt mycket (han utgick från grupper som haft samma laguppställning till minst 75 procent av sitt ursprungliga team). Oavsett om projekten är korta eller långa är det alltså en god ide att så långt det är möjligt hålla samman ett team som får ansvar för olika projekt över tiden.

Färre expertfunktioner En vanlig fråga kring grupper och roller i agil projektledning är hur man ska handskas med expertfunktioner. Att projekt strävar efter att ha all

Roller

45

kompetens inom sin grupp kan vara svårt i organisationer med hög grad av expertis kopplad till olika befattningar. Exempelvis kan en säkerhetsexpert behöva godkänna lösningar eller en arkitekt godkänna ett förslag. Eftersom agil projektledning förespråkar att all kompetens finns inom gruppen innebär det även att organisationer som vill anpassa sin verksamhet till ett agilt synsätt helst ska se över sin organisation för att minska antalet expertfunktioner. Det kanske låter krasst och svårt att åstadkomma men kan ge stora fördelar. Att delegera ned expertens mandat till fler individer eller att helt enkelt ta bort godkännandefunktionen är självklart en omvälvande förändring som inte kan ske över en natt. Men att minska antalet expertfunktioner är en förändring som behövs för att agil projektorienterad verksamhet ska fungera så effektivt som möjligt. Men även om organisationen minimerar antalet expertfunktioner kan ändå problemet finnas kvar. Vissa expertfunktioner är till och med lagstadgade (exempelvis skyddsombud på arbetsplatser). Lösningen på detta problem stavas tydlighet. Inom it-branschen talas det mycket om gränssnitt och med gränssnitt menas egentligen regler för hur samarbete ska ske. Som ett tekniskt exempel kan man ta en vanlig stickkontakt. För att kunna använda sig av elektricitet som är indragen i huset måste man ha en plastkontakt som har ett specifikt avstånd mellan sina två metallpinnar, en viss form på kontakten, en viss typ av kablar och så vidare. Ordet gränssnitt kan användas även i kommunikations- och samarbetssammanhang för att diskutera hur man ska hantera expertfunktionen. Behöver gruppen exempelvis ha avstämning varje tisdag för att granska och få ett godkännande av säkerhetsexperten? Kan projektet invänta beslut om godkännande till tisdagen i varje vecka med risk för att tidsplanen försenas? Denna typ av gränssnittsfrågor är viktiga att klarlägga med experter för att i mesta möjliga mån undvika risker för förseningar.

Testare Gruppen ska helst vara utan roller eller expertfunktioner. Det finns dock en specifik roll som med fördel bör pekas ut i projektgruppen. Rollen testare är oerhört viktig ur ett projekts kvalitetsperspektiv. Det som skiljer testaren från andra roller är nämligen att det är någon som granskar och är kritisk mot det som levereras. Den tidigare nämnde forskaren Katz (1982) visade att team som arbetar tillsammans i mer än fem år förlorar gradvis

46

Kapitel 3

sin effektivitet. Sämre kvalitet på projektresultatet och fler missförstånd uppträder. Anledningen till det, vilket även lyfts fram av andra forskare, är att team som blivit för sammansvetsade riskerar att bli mindre kritiska till sitt eget arbete. En attityd av att "det vi gör vet vi är grymt bra" riskerar att infinna sig och kritik negligeras. I de flesta typer av projekt behövs därför en eller flera testare för att leverera hög kvalitet: ett bokmanus behöver en testläsare, en ny måltidsdryck behöver en testpanel och programvaror behöver testanvändare. Det är viktigt att testaren är noggrann och intresserad av att hitta brister och fel som, om de avhjälps, kan förbättra slutresultatet. I ett kundprojekt kan rollen innehas av en anställd i kundens organisation. Är testaren istället en person från det egna företaget bör personen helst vara någon som inte själv är med och producerar projektresultat. Annars kan lojalitetsproblem uppstå eftersom det kan vara svårt att kritisera det man själv varit med och skapat. Somliga säger kanske att det blir svårt att ha en testare delaktig under hela projektet. Vore det inte bättre att ha en testare i slutet av projektet? Med ett sådant synsätt går man tyvärr emot den agila principen om att hela tiden leverera användbart resultat. En testare behövs hela tiden, under varenda sprint för att kunna leverera användbart, testat, projektresultat. Ibland kan det finnas väldigt lite som testaren kan testa, som under de första dagarna av en sprint. Det finns då en mängd andra saker hen bör göra. TESTARENS UPPGIFTER (UTÖVER TESTANDET) ■ Förtydliga krav åt projektdeltagare (Testaren vet hur resultatet ska testas och kan därför beskriva detta för att förtydliga kravbilden). ■ Sätta upp en testmiljö (Testaren kan behöva förbereda vissa tester

genom att skaffa relevant information, teknik eller labbutrustning). ■ Förbereda för överlämning (Eftersom testaren har bred kunskap om projektresultatet kan en testare förbereda en drifts- och förvaltningsorganisation inför kommande överlämning).

Ansvarsdiffusion Synsättet att projektgruppen är autonom och självstyrande, möts inte sällan av skepticism. Att gruppen kan klara att leda sig själv anses orealistiskt, till exempel då det rör sig om konfliktsituationer, vilket kommer behandlas

Roller

47

mer i kommande avsnitt. Ett annat problem som kan uppstå i självstyrande grupper är ansvarsdiffusion. Innebörden i det ordet (som härstammar från psykologisk forskning) speglas ganska väl av talesättet "delat ansvar är inget ansvar" vilket i sin tur betyder att uppgifter som inte dedikerats till en specifik person lätt kan hamna mellan stolarna. Om två personer har utsetts till ansvariga för att granska ett dokument kan båda säga: "Men, jag trodde att du granskade det här dokumentet". Lösningen på det här potentiella problemet i projekt där gruppen är autonom, är att varje aktivitet har en utpekad ansvarig. Ett typiskt dåligt sätt att driva verksamheten på är att ha en gemensam lista över vad som ska utföras men utan öronmärkning för vem som ska göra vad. Alltså, man kan dela ansvaret för projektåtagandet i gruppen men inte de enskilda aktiviteterna.

Projektledare och scrum master Som jag tidigare nämnde så förespråkar grundarna av metoden Scrum att projektmedlemmarna i gruppen inte ska ha uttalade roller. Den enda roll som lyfts fram är rollen scrum master som har en sammanhållande funktion för gruppen.

Mer coach än chef Det engelska namnet scrum master är valt för att det inte innehåller ord som manager eller leader. Detta för att poängtera att rollen skiljer sig från det traditionella synsättet på projektledaren. Därför är det något vanskligt att översätta begreppet scrum master med det svenska ordet projektledare. (Att man ibland ändå gör så kan motiveras med att scrum mastern kan anses vara en specifik typ av agil projektledare.) Scrum master för ett agilt projekt ska i första hand vara en coach, inte en chef. Med coach menas att det inte är den direkta styrningen som är väsentlig utan att stötta och hjälpa gruppen för att gruppen ska kunna agera så autonomt och effektivt som möjligt. Ett exempel: I ett traditionellt projekt kan projektmedlemmen Anders gå till projektledaren och ställa frågan: "Ska vi använda reklamföretaget Eventsucce eller SynsÖverallt för att marknadsföra sommarens hundraårsjubileum?" och förvänta sig ett direkt

48

Kapitel 3

Beslutsfattande i

Beslutsfattande i

traditionella projekt

agila projekt

Grupp

Grupp

Projektbeställaren

Produktägaren

Projektledaren

Scrum master

I det agila projektet har scrum mastern betydligt mindre beslutsmandat än projektledaren i ett traditionellt projekt.

svar. I ett agilt projekt, om samma fråga uppstår, bör det förväntade svaret vara i stil med: "Det ska vi ta upp med kunden snarast, när har du möjlighet att träffa kunden under dagen?" Eller: "Det bör Sabiha, Emil och Kajsa i vår projektgrupp veta mest om eftersom de jobbat med båda företagen. Jag hämtar dem så reder vi ut det direkt". Scrum mastern ska alltså inte besluta över gruppen utan undanröja svårigheter för gruppen och fungera lite som en snöplog. Detta gör att en scrum master mer är att likna vid en gruppledare än en traditionell projektledare. Men det finns ett mandat som en scrum master alltid har och det är dagliga beslut kring processen. Om hen inser att varje tillfälle då projektresultatet demonstreras ger för lite information kan scrum mastern besluta att varje demonstrationstillfälle till exempel ska förlängas från en till två timmar. Samma sak gäller för stå-uppmöten, erfarenhetsmöten, innehållet i varje erfarenhetsmöte, agenda för projektmöten, äskande efter fler projektmedlemmar eller vad som helst som kan förbättra projektarbetet, det vill säga processen.

Roller

49

Scrum master i interna projekt I många interna agila projekt har titeln projektledare försvunnit. Kvar finns istället rollen scrum master och produktägaren, vilket är den närvarande beställaren som ställer detaljerade krav på vad projektet ska leverera. (Rollen produktägare förklaras längre fram i kapitlet.) Det traditionella ansvar och mandat som projektledare har haft delas på så vis mellan gruppen (beslut kring hur arbetet ska genomföras och vem som ska göra vad) och produktägaren (beslut kring vad som ska göras).

Traditionell

Scrum

projektledare

master

Får besluta om:

Får besluta om:

Processen - hur vi arbetar.

Processen - hur vi arbetar agilt.

Val av teknisk lösning. Vem som ska göra vad.

Får inte besluta om: Val av teknisk lösning. Vem som ska göra vad.

Exempel på skillnader mellan traditionell projektledare och scrum master.

50

Kapitel 3

Scrum master i kundorderprojekt I kundorderprojekt däremot, där vi har en kund som ställer krav på en levererande projektgrupp (till exempel ett konsultbolag som bygger och levererar ett projektresultat) behövs projektledarfunktionen för affären och ekonomiska beslut. Vissa väljer att förutom scrum mastern, ha en specifikt utsedd projektledare som blir länken mellan kund och scrum master. Andra väljer att låta scrum mastern agera både som scrum master (det vill säga coach för gruppen) och projektledare för affären. En sådan scrum master har då ansvar såväl för att coacha gruppen som för att hantera kund-/leverantörsspecifika frågor för projektet. Det finns många olika sorters lösningar för tillfällen då projekten är större än bara en grupp och några av dem beskrivs senare i detta kapitel. Rollbenämningarna kan också benämnas på lite olika sätt beroende på vad som passar det enskilda projektet. I vissa sammanhang, ofta just då projekten blir lite större, kallar man till exempel den person som ansvarar för varje liten grupp för scrum master men behåller rollen projektledare för den som samordnar de olika små grupperna. I ramverket SAFe, som är avsett för större organisationer, kallar man rollen som ansvarar för att samordna flera team för Release Train Engineer (RTE) för att inte blanda in ordet projektledare över huvud taget.

Morötter och mandat X- och Y-teorierna formulerades av den amerikanske forskaren Douglas McGregor på 1960-talet. Han delade in ledares förhållningssätt till sina underordnade i två kategorier. X-teorins syn på anställda: Människor är av naturen lata och vill inte arbeta.

De gillar inte ansvar och behöver bli styrda för att bli effektiva. (Piska) Y-teorins syn på anställda: Människor uppskattar sitt arbete och lägger lika

mycket energi på arbetet som sin fritid om de motiveras tillräckligt. (Morot) Olika ledarskapsstilar kan klassificeras utifrån dessa teorier och agila metoder förutsätter, så klart, Y-teorins syn på anställda. Få ledare idag skulle öppet erkänna sig till X-teorin eftersom det uppfattas som ett förlegat sätt att se på ledarskap. Men i praktiken är det ganska vanligt att människor leder utifrån X-teorin. Ledare som pekar med hela handen och stressar sina

Roller

57

anställda till att jobba hårdare och till senare på kvällen på grund av en för snäv deadline är exempel på det. Det som skiljer den agila projektledningen från många andra inriktningar är att scrum mastern fråntas sitt mandat och därigenom saknar möjlighet att leda enligt X-teorin. Agila förespråkare tror på en högre effektivitet om man litar på gruppens förmåga och låter dem som sitter närmast problemet fatta rätt beslut. Liknelsen till morot eller piska blir egentligen även den felaktig ur ett agilt perspektiv. Eftersom den agila ledarens roll är att stötta sina teammedlemmar och låta dem själva fatta beslut handlar det inte om att erbjuda teammedlemmar någon morot, utan att låta dem utvecklas och bli bra på det de själva motiveras av. Att låta var och en definiera och följa sin egen morot, om man så vill. Synsättet att projektledaren ska överlåta åt gruppen att ta beslut stöter ibland på kritik. I varje grupp där jag talat om projektledarens roll som coach finns alltid en eller flera som menar att detta är ett naivt sätt att se på projektledning och att gruppen behöver ett mycket tydligt ledarskap. Ofta kommer dessa kommentarer från oerfarna projektledare som nyligen påbörjat sin bana inom detta skrå. Som ny och kanske lite osäker projektledare finns ofta en oro över om projektdeltagarna verkligen gör rätt, om de har rätt kompetens eller rätt information. Denna oro övergår ofta i ett kontrollbehov. De allra flesta erfarna projektledare brukar däremot vittna om att det agila synsättet på projektledaren som coach inte är något nytt, utan att det är precis så de brukar driva sina projekt. Att lyfta fram projektledarens roll som coach är ett sätt att med metodik försöka skola oerfarna projektledare till att agera som erfarna projektledare. Istället för att en nybliven projektledare ska ödsla ett antal år på att försöka leda genom att styra, bara för att därefter nå insikten att det bästa sättet att leda är att hjälpa sin grupp och delegera ned besluten till rätt nivå, så hjälper den agila metoden projektledare att agera som erfarna projektledare direkt.

Ledarrollen och konflikter Om synsättet att gruppen kan styra sig själv ifrågasätts av erfarna projektledare så rör sig tvivlet oftast om problemet med konflikter. De säger: "Visst, det där låter ju bra men vad händer om gruppen är delad i två läger i öppen konflikt med varandra?" Ett principiellt svar på det är att scrum masterns viktigaste uppgift är att underlätta gruppens arbete och i detta arbete ingår även att lösa konflikter. Konkret finns det såväl kortsiktiga lösningar som

52

Kapitel 3

långsiktiga lösningar för att lösa konflikter. Den absolut bästa lösningen är att bearbeta och reda ut konflikten så att dessa läger upplöses och gruppen fortsätter att ta egna beslut. Ibland, då det är ont om tid, måste däremot scrum mastern vara tungan på vågen som avgör gruppens beslut för att kortsiktigt lösa konflikter. Men detta bör ske i undantagsfall och strävan bör alltid vara att överlämna beslutsfattandet till gruppen. Principen handlar inte om någon skenbar demokrati där gruppen ska tro att de kan bestämma men att de i verkligheten inte gör det. Principen handlar istället om "99 procent demokrati" där scrum mastern ytterst sällan ska behöva använda sig av sitt mandat som yttersta beslutsfattare. Denna princip, hur tilltalande den än må låta, ställer samtidigt höga krav på projektets deltagare. För att gruppen ska kunna arbeta effektivt under dessa premisser förväntas varje deltagare vara drivande och ha vilja och åsikter kring sin del i arbetet. För att scrum mastern ska kunna coacha, istället för att detaljstyra, krävs eget ansvarstagande. En del av coachningen handlar om att fa gruppmedlemmar att bli aktiva men om en person inte ställer upp på det kan den personen behöva lyftas ur gruppen. Scrum mastern ska undanröja hinder för gruppen vilket kan få detta som konsekvens.

Scrum masters uppgifter Som en del av scrum masterns ansvar för beslut kring processen ingår även ansvar för att den agila metoden följs av projektgruppen såväl som intressenter runt omkring. Detta innebär att en scrum master bör ha ett intresse för pedagogik och mentorskap då upplärning av nya projektmedlemmar blir en del av arbetsuppgiften. Även kringliggande intressenter som inte känner till arbetssättet behöver utbildas avseende förväntningar på dem inför presentationer av delresultat och återkoppling på projektresultatet. Så vad gör en scrum master konkret med sin tid? Här är exempel på uppgifter som scrum mastern kan behöva göra i projektet: UPPGIFTER FÖR SCRUM MASTERN ■ Undanröja hinder. ■ Underlätta för gruppen att arbeta genom att skapa bättre arbetsmiljö (fysisk och psykisk). ■ Resurshantera/resurssäkra (så att gruppen får vara så intakt som möjligt).

Roller

53

■ Ordna medel för utgifter inom projektet (helst enligt en förankrad budget). ■ Gå på möten. ■ Ordna med alla praktiska detaljer kring möten såsom: Agendor inför möten. Protokoll efter möten. ■ Kommunicera inom verksamheten (utanför projektgruppen). ■ Kommunicera utanför verksamheten (om lobbyverksamhet behövs). ■ Arrangera projekt-kick-off. ■ Arrangera ett värdeskapande avslutningsmöte för projektet. ■ Mota "olle i grind" (åtgärda potentiella kommande svårigheter). ■ Hantera konflikter i gruppen. ■ Hantera kunden (i de fall kunden inte är tillräckligt engagerad eller är överdrivet engagerad vilket kan ta för mycket av projektgruppens tid). ■ Hantera produktägare och/eller projekt beställare. ■ Hantera företagspolitik som kan hindra projektet. ■ Hantera efterfrågade rapporter och administration.

Generellt är det viktigt att inse att scrum masterns uppgift kan ha väldigt olika utseende beroende på gruppsammansättningen. I en grupp med många starka viljor kan konflikthantering stå för en stor del av arbetet medan det i självgående, väl fungerande grupper, kan handla om trivselfaktorer och motiverande tillrop.

Scrum master på deltid? Självklart vill gruppen att någon underlättar deras arbete på bästa möjliga sätt genom att administrera, undanröja hinder, gå på möten, få klarhet i svårigheter och så vidare - vilket sammantaget tar mycket tid. Många scrum masters arbetar heltid som scrum master i sina projekt, framför allt under uppstarten av projekt. Samtidigt strävar agila projekt mot att få en så självgående grupp som möjligt. Att lägga för mycket ledningsarbete på en scrum master riskerar att skapa ett beroende för gruppen.

54

Kapitel 3

För en nybildad grupp eller för ett helt nytt projekt i en redan fungerande grupp bör en scrum master få lägga hela sin tid på ledningsuppgifter för att snabbt få upp effektivitet. Men när de första stapplande stegen har tagits bör projektet sträva efter att minska mängden projektledaruppgifter för scrum mastern. Craig Larman (2004) förespråkar att en projektledare för en grupp på sju personer bör sysselsätta sig med 50 procent projektledning och 50 procent projektarbete. Scrum-grundaren Ken Schwaber ger liknande rekommendationer. En svårighet som många projektledare upplever idag är att man med små projektgrupper får ansvar för två eller flera projekt. Risken med en sådan lösning är att problem med prioritering lätt uppstår: Vilket projekt är viktigast? Vilket projekt ska jag lägga mest krut på att stötta? Risken ligger också i förlorad detaljinsikt om personen inte är med i det operativa arbetet. Att en projektledare fungerar bra med 50 procent projektledaruppgifter ska alltså tolkas som att den kvarvarande halvtiden bör användas i samma projekt till andra resultatproducerande uppgifter.

DELADE ROLLER En nybliven programmerare jobbade som teknisk projektledare i ett projekt hos en kund i försäkringsbranschen. Han var sysselsatt med projektledning till 20 procent och programmering till 80 procent i ett tio-manna-projekt. Denna fördelning var oerhört effektiv avseende insikten i projektet och i de problem som projektet stötte på. Men efter hand tog programmeringen över allt mer och många projektledningsuppgifter fick stryka på foten de dagar han stötte på problem i sina programmeringsuppgifter. Han negligerade många ledningsuppgifter vilket gjorde att effektiviteten för hela gruppen sjönk. En 50-50 fördelning av projektarbetet hade förmodligen varit en bättre lösning för projektet.

Det finns självklart också en risk med att lägga för mycket operativa uppgifter på en scrum master. I projekt med idealisk gruppstorlek (fem till nio personer) och en hyfsat väl fungerande grupp är minst en

Roller

55

halvtidstjänst rimlig att avsätta för scrum masterns uppgifter. Helst ska personens övriga arbete vara av en sådan karaktär att det arbetet inte riskerar att växa exempelvis genom att vara ansvarig för en avgränsad liten del av projektresultatet. På så sätt ger en jämn fördelning minsta möjliga sårbarhet eller risk för ineffektivt resursanvändande. Det finns dock tillfällen när en scrum master bör ansvara för flera grupper. GRUPPER KAN DELA SCRUM MASTER OM DET FINNS ■ Beroende mellan grupperna - Om grupperna är väldigt beroende av varandras arbete i ett och samma övergripande projekt kan en scrum master för flera grupper få bättre insikt i helheten. ■ En särskilt lämpad scrum master - Om en person visar sig vara en fantastiskt skicklig scrum master bör naturligtvis organisationen

använda sig av personens kompetens på bästa sätt och låta personen dela sin tid mellan flera grupper.

Att hitta rätt scrum master Att vara projektledare kan se väldigt olika ut i olika organisationer. I vissa organisationer är projektledare såväl en befattning som en roll där människor anställs med titeln projektledare på sitt visitkort. I många projektorienterade organisationer får individer rollen som projektledare beroende på arten av projekt och på hur individen är som person. I de agila metoderna är det coachandet som sätts i fokus och det är därför viktigt att organisationen hittar personer som är intresserade av gruppen och deras utveckling. Typiska ledaregenskaper, som att vara en stark beslutfattare eller organisatör, är inte alltid fördelaktiga eftersom fokus ligger på att lyfta fram gruppen i första hand. Att fatta beslut och organisera arbetet ska i första hand gruppen ansvara för i en agil verksamhet, inte ledaren. Det finns dessutom en annan parameter att ta hänsyn till som har att göra med de uppgifter som en projektledare har i agila projekt. I modellen Scrum poängteras noga vikten av att det är scrum masterns ansvar att införliva modellen i projektgruppens arbete och att såväl nya som erfarna projektdeltagare ska ledsagas i processen av scrum mastern. Det innebär att det finns ett krav på kunskap och kompetens inom agila metoder för att passa för rollen.

56

Kapitel 3

En enkel lösning för att vaska fram en lämplig scrum master är att, helt i enlighet med det agila synsättet, att prova och förändra om det inte fungerar. Exempelvis kan vi låta scrum master-rollen rotera så att en gruppmedlem är scrum master per sprint under de första månaderna. Vissa hittar den mest lämpade på det sättet och andra arbetar alltid med roterande roller för att alla ska få träning och inblick i vad rollen innebär.

Produktägaren Den som formellt beställer ett projekt kan vara en extern uppdragsgivare och/eller någon från den egna organisationen. I kundorderprojekt, vilket kommer beröras mer längre fram, räknas ofta både kunden och den säljare som avtalat med kunden som beställare. Inom traditionella projekt finns rollen projektbeställare som står för övergripande krav och ramar för projektet. I vissa projektverksamheter benämns rollen sponsor. I den agila metoden Scrum har rollen fått namnet produktägare eftersom metoden kom till i verksamheter som skapar produkter i form av datasystem eller dataprogram. Rollens ansvar är, oavsett namn, att ställa krav på projektet utifrån beställarnas perspektiv. Handlar däremot projektet om att ta fram en produkt som ska säljas till konsumenter måste produktägaren förstå slutkundernas behov.

Mer närvarande än projektbeställaren Att termen produktägare används i agila projekt beror på att rollen projektbeställare i många verksamheter innebär någon som endast beställer projektet utan att vara närvarande och engagerad under projektets gång. Så ska det inte fungera i agila projekt. En produktägare ansvarar för alla verksamhetens krav på projektresultatet. I kravbeskrivningar finns det nästan alltid otydligheter som måste redas ut och produktägaren ska kunna svara på detaljfrågor såväl som prioritera krav så att projektresultatet ger maximal avkastning. Därför är det viktigt att produktägaren är både insatt i verksamhet och intressen hos den eller de som formellt beställt projektet samt att hen är tillgänglig för avstämningar och frågor från projektgruppen. Produktägaren beslutar om vad som ska byggas, gruppen bestämmer hur det ska gå till.

Roller

57

Traditionell

Produktägare

beställare

Kan fatta beslut om:

Kan fatta beslut om:

Ökad budget.

Ökad budget.

Fler resurser.

Fler resurser.

Senareläggning av leverans.

Senareläggning av leverans.

Att acceptera ett förän-

Att acceptera ett förän-

dringsförslag.

dringsförslag. Att välja annan teknisk lösning. Att prioritera funktionen X före funktion Y. Att välja gul eller grön färg för skylten.

Exempel på skillnader mellan traditionell beställare och produktägare.

ha en tillräckligt närvarande produktägare är kritiskt för de agila projektens framgång. Många agila projekt faller tyvärr på den här punkten då kunden meddelat att de inte kan avsätta så mycket tid i projektet. De agila projekten får ofta stora problem när det händer och det har ibland gett de agila metoderna dåligt rykte. Ett problem som kan uppstå och som är av motsatt art är om produktägaren är en del av teamet, då det lätt kan bli för snabba beslut och kraven kan komma att ändras väldigt fort och ofta. (Fenomenet att målet eller kraven växer utan att resurserna som avsätts för projektet gör det kallas scope creap.) Många har aktivt flyttat produktägaren från projektrummet, för att påverkan på projektets detaljer inte ska bli för stora. Men det är ofta ett mycket ovanligare problem än att få en produktägare tillräckligt engagerad. Att

58

Kapitel 3

Mängden tid produktägaren måste avsätta för att vara närvarande i projektet bör ställas som krav från teamet. Exempelvis kan det vara överenskommet att produktägaren ska vara tillgänglig en timma per dag för att ge möjlighet att stämma av eventuella frågor. ~MI PRODUKTÄGARENS

■ Jag kommer att delta vid

KRAVPROFIL

varje uppstartsmöte som

Det kan vara bra att veta vilka

genomförs vid start av varje

krav organisationen ska ställa

nytt delprojekt/sprint.

på en produktägare. Här är en enkel checklista över kriterier

■ Jag kan ställa krav på projektresultatet på detaljnivå.

den tilltänkta personen kan ta ställning till. Mallen är bra att använda i uppstarten av en agil verksamhet då produktägaren

■ Jag kan vara tillgänglig dagligen för att ge svar på teamets frågor.

ska få klart för sig vilka krav

■ Jag vet vilka jag kan ta hjälp

som finns på rollen.

av för att teamet ska få svar på frågor jag inte kan besvara själv.

■ Jag har god insikt i verksamhetens mål och förväntningar på projektet.

■ Jag vet vilka jag kan ta hjälp av för att teamet ska få relevant feedback på framtaget

■ Jag vet vilken nytta projektresultatet förväntas

projektresultat om jag själv inte har rätt kompetens för det.

innebära för organisationen. ■ Jag kan prioritera mellan olika krav utifrån nyttan av projektresultatet.

Om det visar sig att en individ inte kan leva upp till kraven måste rollen delas mellan flera individer, men rätten att

■ Jag kan prioritera mellan olika sprintresultat, när saker förväntas levereras.

prioritera mellan krav bör ägas av endast en person. Det två sista punkterna visar att en

■ Jag kommer att delta vid

produktägare inte måste vara

varje demonstration och

en supermänniska som kan

granskning av delresultat och

allt, men att hen måste ha rätt

där ge åsikter och feedback på

kontaktnät för att hjälpa teamet

det genomförda arbetet.

om hen saknar viss kompetens.

Roller

59

Kunden som produktägare I kundorderprojekt har man i bästa fall en representant från kunden som antar rollen produktägare. Har kunden av olika skäl inte möjlighet att närvara som produktägare i projektet får någon ur den egna organisationen utses som språkrör för kundens krav och intressen. Det måste vara en person som kan ställa såväl övergripande krav kring projektets ramar som detaljerade krav på funktionalitet. Kan inte detta lösas i en och samma person måste rollen delas.

Kund

Projekt

Produktägare

Projektgruppen

••

Om avståndet till kund är litet vill man helst ha kunden i rollen som produktägare.

Kund

Projekt

Produktägare

Projektgruppen

När inte kunden inte har möjlighet till täta avstämningar måste produktägaren finnas inom vår verksamhet.

60

Kapitel 3

••••••••

Konsumenter

Projekt

Produktägare

Projektgruppen

•••••

•••••

När projektresultatet vänder sig till många och vi inte har en direkt kund att gå till måste en utsedd produktägaren finnas inom vår verksamhet som helst ska samla in data kring kundens önskemål.

Att dela upp produktiigarrollen Med tanke på bredden av beslut som produktägaren ska kunna fatta så krävs det ofta att rollen delas mellan flera individer. Exempelvis kan en verksamhetschef svara för prioriteringarna men en framtida användare av projektresultatet kan svara på detaljfrågor rörande krav. Det är i dessa lägen viktigt att vara oerhört tydlig med gränser för mandat och befogenhet.

Roller

67

Exempel - två produktägare Projektet "Nya mallar"

Produktägare

Produktägare 2

Verksamhetschef för

Handläggare på

skadereg leringsen het

skadereglerings-

på försäkringsbolag

avdelningen

Får besluta om:

Får besluta om:

Prioriteringar

Lösningens innehåll

"Den här mallen ska vi

"De här fälten ska vara med

använda men inte den här".

i den här mallen".

Fler resurser till projektet. Senareläggning av leverans.

Lösningens utformning "De får vara max 14 ifyllningsbara fält per sida".

Att acceptera ett förändringsförslag.

Exempel på uppdelning av beslutsområden mellan två produktägare.

Uppdelning av produktägarrollen på flera individer är i sig inte eftersträvansvärd - i metoden Scrum förespråkas att projekt alltid ska ha en person som produktägare då risken för dubbla budskap till projektgruppen är så stor. Tyvärr är det dock för många organisationer inte möjligt då rollen kräver ett mycket brett synsätt och insikt i projektkraven på alla nivåer. Vikten av att kunna "tala till bönder på bönders vis och med lärde på latin" gäller i allra högsta grad för agila projekt. Det är viktigt att produktägaren pratar med gruppen på rätt språk, och är förmögen att ge svar på frågor på rätt nivå för projektets behov. Därför kan en uppdelning av rollen vara befogad så att exempelvis en person kan besluta kring projektets ramar och en annan beslutar om innehåll och utformning.

62

Kapitel 3

Mandat och befogenhetsgränser när roller delas, måste redas ut och dokumenteras. Det gäller att vara tydlig kring var gränserna går. Vem får bestämma vad? När behöver beslut fattas av ena parten och när behöver båda parter enas för att beslutet ska vara godtagbart? Det skadar inte att lägga någon timma på att detaljerat beskriva dessa rollers gränser i agila projekt. "Men om man upptäcker att rollfördelningen inte var särskilt tydlig efter en sprint, vad gör man då?" Rätt svar är att stanna upp efter sprintleveransen, utvärdera, omformulera rollfördelningen och därefter köra en ny sprint. Hela tiden, om och om igen. För det är det som kännetecknar agil projektledning - att hela tiden förbättra saker som inte fungerar bra, såväl projektresultat som arbetssätt. Så vad är viktigast för en produktägare då? Svaret är tillgänglig tid. I flera undersökningar som gjorts har varken verksamhets eller teknisk kompetens hamnat överst på önskelistan, utan istället att personen har tillräckligt med avsatt tid för att hjälpa gruppen framåt. Leta inte efter den optimala produktägaren, leta efter den som kan avsätta tillräckligt med tid för att jobba med gruppen.

Styrgruppen I de flesta beskrivningar av agila metoder omtalas inte fler roller än scrum master, produktägaren och testaren. Anledningen till denna minimalism är att man i agila metodbeskrivningar sällan nämner mer än den minsta enhet som kan vara universell för alla typer av projekt. Men alla projekt behöver visså roller också i sin omgivning. Beroende på projektets storlek och art kan en styrgrupp för projektet behöva tillsättas. I mindre projekt finns ingen nivå ovanför produktägaren/ projektbeställaren men ofta krävs även ett engagemang från individer utanför själva projektgruppen. Här följer därför några viktiga roller som bör finnas i styrgruppen, även om de sällan explicit anges i projektbeskrivningar för agila projekt.

Roller

63

Roller som bör ingå i en styrgrupp

Intern

Resursägare

mottagare

Projekt-

Produktägare

(Kund)

(Scrum master)

beställare

I kundorderprojekt väljer många att skapa en gemensam styrgrupp där kundrepresentanter deltar, i andra sammanhang skapas två styrgrupper: en hos kunden och en hos leverantören. I mindre projekt som bara består av en enda grupp är scrum mastern adjungerad, vilket betyder att hen kan bjudas in att delta då styrgruppen möts. Antingen bjuds då scrum mastern in för vissa frågor på dagordningen eller för hela mötet, det är upp till ordförande i styrgruppen att bestämma.

Intern mottagare Det är den interna mottagaren som ansvarar för projektresultatet när det övergår till drift och förvaltning efter att projektet avslutats. I itsammanhang innehas rollen ofta av en förvaltningschef eller av chefen för driftsavdelningen. Den interna mottagarens roll kan vara svår att identifiera i många organisationer och det gör ofta att projektledare drabbas av evighetssjukan. Evighetssjukan innebär att projektledare, som gått vidare till nya projekt, drabbas av frågor och krav på att lösa problem med projektresultatet från projekt som avslutats för länge sedan. Detta sker eftersom själva projektledaren tenderar att bli synonym med projektet i hela övriga organisationen. Projektledarens namn har synts i dokument som beskrivit projektet och när användare av projektresultatet väl stöter på problem och frågeställningar kontaktar de projektledaren. I en organisation där det inte finns en given intern mottagare är det viktigt att projektledaren tidigt i projektet tar upp frågan med produktägaren eller en överordnad beställare. Ofta finns det någon chef i organisationen som lämpligen kan ha den rollen. Det är trots allt cheferna i en organisation, inte projektledarna, som ska ansvara för det långsiktiga bibehållna resultatet.

64

Kapitel 3

Resursägare Resursägaren ansvarar för de resurser och personer som ingår i projektet. Ofta är det en roll som behöver delas mellan flera chefer i organisationen. Om projektgruppen består av anställda både från ekonomienheten och verkstadsgolvet behöver alltså rollen fyllas av såväl ekonomichefen som av verkstadschefen.

Kunden I en del kundorderprojekt låter den som formellt beställt projektet sig företrädas av en mer närvarande produktägare, vilket tidigare förklarats. Beställaren, i detta fall kunden, kvarstår då som en extern roll för produktägaren att ta hänsyn till och bör ingå i projektets styrgrupp. I kundorderprojekt kan man tala om att det dessutom finns en beställare av projektet inom organisationen. Ofta är det den ansvarige säljaren som också fungerar som projektbeställare genom att beskriva inom vilka ramar som projektet ska utföras, till exempel budgetnivåer som inte får överskridas. Men kunden, som är en extern beställare, har andra typer av krav. Dessa krav rör projektresultatet som säljaren har garanterat kunden. Kundens intresse ligger i att få ut så mycket nytta för sin organisation som möjligt medan säljaren är intresserad av att projektet innebär så stor nytta för den egna organisationen som möjligt.

Styrgruppens storlek En styrgrupp bör vara liten. De som tvärtom menar att storleken kan anpassas efter projektets eller verksamhetens storlek missar några viktiga poänger. Med en liten styrgrupp kan beslut fattas snabbare eftersom det är få parter som ska komma överens. Varje möte kan bli kortare eftersom det är färre som ska yttra sig och delge sin åsikt. En utvidgning av gruppen med syftet att inbegripa många av organisationens chefer i projektet gör tyvärr oftast att styrgruppen istället förlorar sin funktion. Styrgruppen ska styra. Den ska fatta de beslut som projektledaren eller gruppens deltagare inte kan fatta själva. Styrgruppen ska inte vara ett forum för åsikter och kommentarer, vilka istället kan ges inom ramen för en rådgivande referensgrupp där personer utan mandat att fatta beslut för projektet sitter med. Ett effektivt sätt att arbeta är att gå till en utsedd referensgrupp för att

Roller

65

få förslag och kommentarer på lösningar och att ta med sig dessa förslag till en styrgrupp som då kan fatta beslut. Ett alternativ till att utse en referensgrupp är att helt enkelt låta rätt sorts chefer delta på demo-tillfällen i slutet av varje sprint. Där kan produktägaren fånga upp åsikter som hen tar med sig till styrgruppsmöten. Ett stort problem med tillsättande av styrgrupper är att det ofta kan ses som en prestigefråga vilka som bör sitta där. En projektledare gör klokt i att få ordföranden i styrgruppen att visa vilket beslutsmandat varje föreslagen styrgruppsmedlem har i projektet, för att motivera att de ska vara med. Det är då inte relevant vilket generellt mandat de har (exempelvis vilket mandat de har som chefer i organisationen) utan vad de faktiskt får besluta om inom projektets ramar. När jag skriver att styrgruppen ska vara så liten som möjligt så innebär det att den bör innehålla personer som har de roller i projektet som beskrevs ovan. Men kom ihåg att jag talar om roller, inte personer. Vissa personer kan ha två roller och en roll kan ibland behöva delas mellan två eller flera personer. För det mesta bör scrum mastern vara med i styrgruppen som adjungerad i mindre projekt, det vill säga projekt som bara består av ett team. Består det av flera team finns det risk att styrgruppen blir för stor om alla scrum masters ska vara med. Ofta låter man då istället bara produktägarna vara med. Är du osäker på vad som blir bäst? Prova. Som allt annat i agila verksamheter är det ont om rätt eller fel. Hamnar diskussionerna på för detaljerad nivå på styrgruppsmötena? Ja, då bör kanske inte era scrum masters vara med. Det finns tillfällen då styrgruppen vill diskutera saker som scrum mastern inte får vara med och besluta om (exempelvis förändring av projektets ramar), därför bjuds denne inte nödvändigtvis in till alla styrgruppens sammankomster.

66

Kapitel 3

1,1•0~N,, N6Z'~iiMME11~11~111111~~1~1111KM«1111~~1 SNABBHET ÄR EN FRAMGÅNGSFAKTOR Gruppbeteendeforskaren Doktor Meredith Belbin (1993) undersökte grupper och dess effektivitet och iakttog ett antal typiska beteenden för framgångsrika grupper. Under nio år undersökte han projektgrupper, ledningsgrupper, styrgrupper och styrelser. En av de viktigaste iakttagelser som gjordes vara att framgångsrika team tog snabba beslut. Team med omfattande diskussioner och långbänkar var genomgående mindre framgångsrika. I alla former av forum kan någon räcka upp handen och säga "vi måste analysera djupare och inte bara hasta fram beslutet". I somliga fall finns det fog för denna typ av bromsande, men att snabbhet är en framgångsfaktor bör också hållas i åtanke. En grundläggande anledning till det uttrycks i talesättet "Ej fattat beslut är också ett beslut". Genom att inte fatta beslut i en viss fråga visar vi att "även i dag har vi fattat beslut om att vänta". Att ha allt för många kvalitetsmedvetna bromsare i ett team bör ses som en varningssignal att ta på allvar.

Referensgruppen För att få konstruktiv återkoppling så att projektresultat blir det allra bästa utses ofta en referensgrupp. I referensgruppen bör åtminstone användare (brukare) och förvaltare av projektresultatet ingå — de som kommer att påverkas av projektresultatet — där de kan få göra sina röster hörda. Traditionellt i projekt finner man ofta en referensgrupp inritad i en projektorganisationskarta (eller OBS, Organization Breakdown Structure som Project Management Institute benämner den). Men ofta planeras referensgruppen inte in i de aktiviteter som ingår i projektet. Initialt uttalas ofta intentionen att referensgruppen ska granska projektresultatet så att förbättringar kan göras utifrån det, men dessa aktiviteter genomförs sällan. Efteråt brukar man få höra saker som: "Projektet blev tidigt så försenat att vi inte hade tid för att stämma av med referensgruppen". Synd, kan man tycka. För det är ju när projektet spårat ur som hjälpen utifrån verkligen hade behövts.

Roller

67

I agila projekt är ofta användandet av en referensgrupp istället inbakat i processen. Demonstration och granskning av delresultat planeras in i projektet efter varje sprint och referenspersoner bjuds in till dessa återkopplingssessioner. Betyder det att hela referensgruppen bör närvara vid varje demonstration? Helst inte. För att inte slösa bort människors tid till meningslösa möten är det bra att bara bjuda in rätt personer: de som har relevant återkoppling att ge på projektresultatet för den aktuella sprinten. Under sprintplaneringsmötet, när sprintmålet är överenskommet, bör produktägaren diskutera med gruppen vilka som bör bjudas in till demonstrationen. Om delar av sprintens arbete inte hinner fullfärdigas bör produktägaren ansvara för sista minuten-kontakten med referenspersoner så att inte Anna dyker upp på demonstrationen bara för att få veta att hennes önskade delresultat inte kommer att demonstreras.

Leverantörer Agila projekt fungerar som bäst när det går att hantera alla arbetsuppgifter inom den egna gruppen. Men många projekt ser inte ut på det viset. Ofta måste projektet få hjälp av leverantörer som levererar delresultat och ibland består hela projektet av att koordinera leverantörers projektresultat. Vissa organisationer saknar interna resurser för att genomföra projekt och projektledarens jobb blir då inte att ha hand om en egen grupp utan måste koordinera verksamheten för olika externa leverantörer. Oavsett projektmetod är det svårare att koordinera externa resurser som kan ha delat sitt engagemang mellan flera aktörer.

Agil-kompatibla leverantörer Så hur ska organisationer med externa leverantörer göra för att få fördelarna med det agila synsättet? Det enkla svaret är att välja leverantörer som kan anamma samma agila synsätt. Framför allt bör leverantören anamma två viktiga principer: 7. Leverera och presentera delresultat ofta (enligt våra önskemål). 2. Kontinuerliga, korta avstiimningar.

68

Kapitel 3

Att leverera och presentera delresultat ofta är olika lätt att anamma beroende på vilken typ av leverantör det handlar om. Inom systemutveckling är det exempelvis vanligt att produktleverantörer har ett fastslaget program för när de levererar olika typer av funktionalitet i releaser (utgåvor av produkten) och då är det svårt att påverka deras arbetssätt. Organisationen kan försöka påverka innehållet genom att argumentera för sina prioriteringar inför varje delresultat men det kan ändå vara svårt. Mitt råd är att så långt det är möjligt ha ett avtal med leverantören som möjliggör prioritering mellan krav och tidpunkt för del- eller sprintresultat. De kontinuerliga, korta, avstämningarna kan däremot kräva lite inkörning för att få samarbeten att fungera väl. Många leverantörer blir överambitiösa då de förväntas rapportera status och tenderar att lägga för mycket tid på att skapa fina presentationer. Därför är det viktigt att påpeka skillnaden mellan korta avstämningar och rena projektmöten då diskussioner om lösningar och krav ska genomföras. För att markera att ingen av projektets medarbetare bör lägga tid på resor eller onödiga presentationer, kan projektledaren förlägga möten hos leverantören och förtydliga då mötet planeras att hen endast väntar sig en kort muntlig avstämning och att fokus ligger på att ge återkoppling på det hittills framtagna projektresultatet.

Chefens roll i agila projekt I detta kapitel om roller har allt utgått ifrån projektet som arbetsform. I förbigående nämndes chefer som typiska för roller såsom resursägare och intern mottagare. Men i de flesta organisationer finns chefer för varje avdelning. En chef som är ansvarig för att se medarbetare och få dem att utvecklas långsiktigt för organisationens bästa. Vad har de för roll i det agila arbetet? Det här är en svårare fråga än det kan verka. Traditionellt sett har chefen haft stort beslutsmandat och varit någon som gruppmedlemmar ofta vänt sig till för beslut och stöd. Här beskrivs det agila arbetssättet som gruppcentrerat, en miljö där gruppen ska få så mycket mandat som möjligt. Självklart ställer det plötsligt nya krav på cheferna. Om man med några få ord ska förklara chefens nya roll i en agil projektmiljö så blir det: lyssna, stötta och delegera mera. Ett vanligt problem för chefer i organisationer som blir agila är att de upplever att de inte är med på allt som händer längre. Det är helt naturligt

Roller

69

eftersom varje grupp skapar egna rutiner, väljer sina mötestider och arbetar tätare tillsammans. Cheferna måste därför lägga mer tid på att lyssna. Det vill säga, anpassa sig efter varje grupps regler och ofta närvara på stå-upp-möten, planeringsdagar och demonstrationer. Annars kommer de inte att kunna utföra sina jobb särskilt bra. Cheferna måste anpassa sig efter gruppen och det innebär även att våga delegera mer och mer av beslutskraften. Det skrämmer en del chefer men samtidigt är det det som oftast ger de största fördelarna av det agila; att på riktigt ge kraften till teamen. Samtidigt kan teamen behöva hjälp och då är det viktigt med en stöttande chef. Många chefer har arbetat längre än sina medarbetare på företaget och har en bättre helhetsbild av verksamheten. De har ofta själva varit en del av visions- och målarbetet och kan hjälpa teamen att bättre förstå helheten och vad som är viktigt för organisationen, vad man strävar mot. På många företag börjar man idag prata om agil HR (Human Resources eller personalpolitik, med ett svenskt ord) eftersom det agila synsättet ställer andra krav på cheferna än tidigare. Personalavdelningarna måste helt enkelt lära om inför rekryteringar av chefer och lära sig att leta efter människor som är duktiga på att lyssna, stötta och delegera. Har då plötsligt allt mandat försvunnit från cheferna? Nej, inte alls. Personalansvaret, det långsiktiga ansvaret för de anställda, ligger fortfarande på deras bord och det gör framför allt att de får (och bör) stötta sin organisation genom att fatta beslut om personalen. Exempelvis vilka team som behöver förstärkning, vilka individer som behöver utvecklas för att passa in i ett team och ibland även fatta svåra beslut om personer inte presterar tillräckligt eller helt enkelt inte fungerar i ett team.

Sammanfattning De agila metoderna pekar ut ett antal roller varav de viktigaste är: ■ Gruppen - som är en egen beslutandenivå eftersom den fattar detaljbeslut kring vilken lösning som ska väljas och vem som ska göra vad. ■ Serum master - som är den coachande projektledaren. ■ Produktägare - som är den närvarande beställaren i agila projekt. ■ Testaren - som kontrollerar projektresultatet löpande under varje sprint.

70

Kapitel 3

I den omgivande organisationen kring projektet behövs roller såsom: ■ Intern mottagare - som ansvarar för att ta över projektresultatet när det är färdigt. ■ Resursägare - som ansvarar för vilka resurser och personer som ska ingå i projektet. ■ Styrgruppsmedlemmar - där de två ovanstående bör ingå tillsammans med den eller de formella beställarna och produktägaren.

Framgångsfaktorer för agila metoder ligger i: ■ En ständigt närvarande produktägare - som helst är kunden, eller, om det är ett internt projekt, en beställare som är engagerad, närvarande och verksamhetskunnig. ■ En självorganiserande grupp - som tillåts fatta egna beslut.

••

Ovningar — Uppgifter

får scrum master

Tid för övningen: 10 + 20 minuter. Det agila sättet att arbeta i grupp innebär att scrum master i första hand ska vara den som banar väg och undanröjer problem för gruppen. I denna övning får varje gruppdeltagare ett antal post-it-lappar. Var och en skriver ett antal aktiviteter som man tycker att scrum master ska ansvara för som gör att personen kan underlätta för gruppens arbete (10 minuter). Scrum master läser därefter upp varje lapp och gruppen diskuterar om det är en lämplig uppgift för hen att ansvara för eller inte.

2 — Krav på produktägare Tid för övningen: 15 + 20 minuter. Det kan vara svårt att börja arbeta agilt. Även om såväl scrum master som projektdeltagare är motiverade och pålästa kan det vara svårt att få hela organisationen att agera agilt. Projektgruppen delas in i smågrupper och diskuterar vilka krav som behöver ställas på produktägaren för att det agila arbetet ska fungera så effektivt som möjligt.

Roller

71

Efter 15 minuters diskussion samlas alla och diskuterar vad man kommit fram till. Gruppen enas om en gemensam lista över krav som behöver ställas på produktägaren. Den här övningen fungerar bäst om produktägaren är med i diskussionerna, annars behöver listan förankras hos produktägaren efter avslutad övning.

3 - Krav på leverantörer Tid för övningen: 15 + 20 minuter. Precis som för produktägaren så behöver man enas om vilka krav som ska ställas på leverantörer. I denna övning delas projektgruppen in i smågrupper som diskuterar i 15 minuter och sedan återsamlas för att enas om en lista med krav på leverantörerna. Det är bra om representanter från befintliga leverantörer är med i den här övningen men det är inte tvunget. Det är projektgruppen som ska upprätta krav för att välja vilka leverantörer som anlitas. Tanken är att kravlistan ska kunna användas för såväl befintliga som kommande leverantörer.

Agil propAtiedJung

ÖVNINGSBOK

72

Kapitel 3

Övningsboken: I kapitel 6 finns sju praktiska grupputvecklingsövningar som ni som grupp kan använda. De är till för att lära känna varandra bättre, för att identifiera gemensamma mål och för att stötta varandra som grupp.

Förstudien

Förstudien ska ge svar på frågorna: "Vad ska vi göra och varför?" Ofta resulterar förstudiearbetet i ett beslutsunderlag som en beställare använder för att fatta beslut om att sätta igång med projektet. I kundorderprojekt resulterar förstudien ofta i en offert som ska accepteras för att starta projektet. Under förstudien ska de viktigaste frågetecknen rätas ut. Om det inte görs kommer starten av projektet att bli ineffektiv och projektgruppen kommer att känna tvivel kring vad som är viktigt, vilka mål som ska uppnås och vem de ska lyssna på.

74

Kapitel 4

Ofta förbisedd, ej försumbar

Pr

Förespråkare för agila metoder talar sällan särskilt mycket om förstudiearbete. Ibland verkar det som att förstudien är ett arbete som på något magiskt vis bara avklarats före det egentliga projektet. Tyvärr har det gjort att många förstagångsutövare av agila metoder trott att förstudiearbetet är något som inte egentligen behövs, att det bara är att sätta igång med projektet. Dock finns det tunga skäl för att förstudieEn vision utan genomförande arbetet inte ska försummas, även när är en dagdröm. Genomförande man valt att arbeta agilt. Faktum är att de allra flesta agila metoderna utan vision är en mardröm. lägger stor vikt vid att ha en väldigt (Japanskt ordspråk) klar bild över vad man vill göra, vilka mål och framför allt vilken nytta projektresultatet ska ha. Och det är vad förstudiearbetet ska ge svar på: Vad är det vi ska göra? Till skillnad från planeringen som ger svar på frågan: Hur ska vi göra? Omfanget på förstudien ska alltså inte minska men man ska sträva efter att ha så kort tid som möjligt från start till färdigställande av förstudien. Det finns tekniker som avsevärt kan minska tiden för genomförandet av en förstudie. Precis som i Toyotas principer för Lean så vill vi ha kort tid från att beslutet om att genomföra en förstudie har fattats till en färdig förstudie. Eller som Leanförespråkare skulle uttryckt det: När beslutet är fattat, agera snabbt.

Att börja effektivt Citatet nedan gäller i allra högsta grad för arbete i projekt. Det är många saker som måste vara på plats innan genomförandet kan sättas igång. Rätt personer måste godkänna budget för ett projekt. Förankring hos rätt personer måste ordnas för att få stöd från organisationen. Rätt grupp av projektmedlemmar måste sättas samman och rätt personer måste leda projektet. De mest betydelsefulla människorna i organisationen är ofta de mest upptagna Att börja är halva arbetet vilket kan göra det än svårare att samla (Kinesiskt ordspråk) rätt sorts människor. Detta gör att många verksamheter lider av att projekt tar lång tid från i& till att de kan påbörjas. Så hur kan man lösa det här problemet? Ett exempel från British Telecom visar vägen:

"

Förstudien

75

I

EXEMPEL - EFFEKTIV FÖRSTUDIE

form av nytta som projektresultatet

Three-day-hothouse på

innebär efter go dagar. För att slippa

. ' British Telecom

en lång startsträcka bestämde man sig

. Tidigare hade man på det gigantiska

också för att varje go-dagars-period

: företaget British Telecom bedömt vilka projekt man skulle satsa på ; genom att gå igenom business case och ge dem tummen upp eller tumI men ned. Dessa projekt kunde pågå i flera år och problemet blev att resurir ser låstes upp under allt för lång tid.

ska inledas med tre dagars förstudie, detaljering och planering - varken mer eller mindre. Det viktiga för att få tummen upp blev därför att kunna samla rätt personer och få dem att acceptera att de ska närvara under den tre dagars långa

Korta fönster av möjligheter kunde

uppstarten. Beställare, projektgrupp,

inte utnyttjas eftersom för många

slutanvändare och andra viktiga

medarbetare var uppbundna i projekt

intressenter låser sedan in sig och

under flera år. För att arbeta agilt bestämde sig British Telecom för att inga projekt

detaljerar alla krav och det arbete som ska utföras under go-dagarsperioden. Resultatet av detta tre-dagars-arbete

får pågå under längre tid än go dagar.

visas sedan upp och har det tillräckligt

Alltså, projekten kan precis som förut

bra detaljeringsnivå och får förtro-

ha intentionen att pågå under en

ende från dem som sitter på pengarna

längre tid men för att få tummen upp

kan den go dagars långa projektperio-

är man tvungen att visa upp någon

den köra igång.

Exemplet från British Telecom visar två viktiga saker. Det ena är fördelen med att alla är med på båten från start. Det agila arbetssättet handlar om tron på människors kraft och vilja. För att åstadkomma stordåd måste människor förstå sammanhangen. De måste ha samma helhetsperspektiv som de högsta cheferna för att kunna bidra på bästa sätt. Det andra är att det går att minska tiden från tanke till start på projektet om vi samlar alla beslutsfattare vid ett och samma tillfälle. Att få många människor att jobba tillsammans i en grupp i ett rum (som populärt kallas workshop) är ett bra sätt för att gå från tanke till handling.

76

Kapitel 4

~1.

VARFÖR TALAS DET SÄLLAN OM FÖRSTUDIEN INOM AGIL PROJEKTLEDNING? En orsak till avsaknaden av förstudiestöd inom de agila metoderna är att de flesta av dem inte är kompletta projektmodeller. De flesta visar ett effektivt arbetssätt som kan användas i projekt lika väl som i löpande arbete. Metoderna är ofta snarare ramverk och deras upphovsmän strävar efter att ge ett enkelt skelett som visar vad du som utövare kan behöva. Eftersom förstudiearbete ofta kan se väldigt olika ut i olika situationer bestämmer sig många för att helt enkelt utelämna beskrivningar av förstudiearbete. En annan anledning till att de agila metoderna inte uppehåller sig nämnvärt vid förstudien kan vara problem med gränsdragningar. Gränsen mellan vad som ska ingå i en förstudie jämfört med själva planeringsfasen för ett projekt är ofta föremål för diskussion. Detta gäller såväl traditionella projektledningsmetoder som agila. Deltagare i undervisning om projektmetoder ställer ofta frågor om olika planeringssteg av typen: "Men, är inte det momentet en del av förstudien?" Och eftersom helhetsplanering är något man i de agila metoderna försöker begränsa finns det många som anser att de steg som ingår i ska skäras ned. planeringen p

Förstudiens frågor När är en forstudie klar? Det är den när man klargjort projektets orsak, nytta och omfattning. TYPISKA FRÅGOR SOM FÖRSTUDIEN SKA BESVARA ■ Varför ska projektet genomföras? •

Vilken nytta ska vi få av att projektet genomförs?

■ När startar genomförandet och när är det tänkt att projektet ska avslutas? •

Hur mycket pengar ska investeras i projektet?

•

Vad ska göras?

Förstudien

77

Om bara svar på dessa frågor ges, kan slutresultatet av en förstudie innebära allt från en enkel skiss av projektresultatet till att omfatta flera pärmars dokumentation. De gånger dokumentationen blir omfattande är det ofta svaret på den sista frågan som behövt utförliga beskrivningar (Vad ska göras?). Beroende på projektets storlek och beroende på avståndet mellan beställare och projektgrupp behöver tydligheten vara olika stor i olika projekt. Avståndet kan vara geografiskt (att projektbeställare och projektgrupp inte har möjlighet att träffas tillräckligt ofta) eller mer bildligt, som i de projekt beställaren inte talar samma språk som projektgruppen.

Tre verktyg ger svar Här kommer tre verktyg som tillsammans kan ge svar på frågorna ovan. Använd dem helst genom att träffas i workshop-form, för att få hjälp av hela projektgruppen. FÖRSTUDIENS TRE DELAR ■ Intressentanalys - för att få reda på vilka som kan besvara viktiga frågor under projektets gång. ■ Visionsdokument - för att tydligt och visuellt konkretisera vad som ska göras och varför, samt omfång, tid och pengar för projektet. ■ Kommunikationsplan - för att tidigt slå fast hur vi ska kommunicera i projektet.

Intressentanalys En intressent är en grupp, organisation eller person som påverkar eller påverkas av projektet. En intressentanalys är ett arbete för att identifiera de intressenter som vi ska ta hänsyn till i projektet. Eftersom listan över intressenter kan bli lång handlar det om att identifiera vilka personer, grupperingar eller organisationer som är viktiga att lyssna till. Man kan slita hur mycket som helst med att exempelvis utveckla en ny produkt men får nästan garanterat ett oanvändbart projektresultat om man inte tar reda på tillräckligt mycket om behoven hos den konsumentgrupp man riktar sig till. Att lyssna på rätt intressenter är grunden till framgångsrika projekt. I många projektmetoder ligger fokus på de individer som finns inuti projektet, alltså de som påverkar projektet. Det är sällan tillräckligt fokus på

78

Kapitel 4

dem som påverkas av projektet. Varför är det så? Jag tror att det beror på att vi ofta blir hemmablinda och hellre fokuserar på dem som är närmast oss och hur vår organisation fungerar än att vi tittar utåt, mot dem som projektresultatet är till för. Dessutom vet vi vilka de är, till skillnad från personer utanför den egna organisationen. Detta kallas ibland "inifrån-och-ut-perspektivet", det vill säga att vi inte tänker i kundens banor utan utifrån hur vårt projekt eller vår organisation är uppbyggd. För att inte projektet ska bli en flopp måste man lyssna på båda parter — både de som påverkar och påverkas av projektet. Hur avgörs då vilka de viktiga intressenterna är? Intressentanalyser är tyvärr sällan beskrivna i agila sammanhang så därför lyfter jag här fram en metod tagen från den traditionella projektledningsmetodiken men som följer agila principer. EN AGIL INTRESSENTANALYS ÄR: ■ baserad på kommunikation mer ön dokumentation ■ snabbt genomförbar med synbara resultat

Metoden utgörs av fyra steg. En mer detaljerad version av metoden finns beskriven i boken Projektledningsmetodik skriven av Lennart Ljung och Tomas Jansson.

Referensgruppen

Identifiera grupperingar Personerna som ska arbeta med projektet utrustas med post-it-lappar och sätter sig tillsammans vid ett blädderblock. På lapparna skriver var och en ner de avdelningar, organisationer, team eller andra sorters grupperingar som på något sätt kan påverka

Förstudien

79

projektet. I detta skede är det inte namn på enskilda personer som skrivs ned och diskussioner om olika gruppers betydelse kan också lämnas åt sidan. Tidsåtgången för momentet bör bestämmas på förhand, till exempel tio minuter. Därefter går gruppen gemensamt igenom samtliga lappar. Nu är det tillåtet att diskutera och kritisera vad som är skrivet. För varje gruppering som man enas om är en relevant intressent ritas en cirkel på blädderblocket och namnet på grupperingen skrivs in i cirkeln. Det finns ofta många tyckare kring projekt men eftersom för många kockar som bekant sällan gör en god soppa, kan projektgruppen redan här behöva begränsa antalet intressenter. Samma sak görs sedan för grupperingar som påverkas av projektet genom att rita ytterligare cirklar. Ibland identifieras samma gruppering igen (som alltså både påverkar och påverkas). Eftersom grupperingen redan finns skriven på blädderblocket behöver den inte skrivas igen — det viktiga är att identifiera grupperingar, inte att definiera om de påverkar, påverkas eller både och. Det kan eventuellt behöva förtydligas längre fram i processen men för tillfället räcker det att de finns synliga på blädderblocksbladet.

Identifiera intressenterna Referensgruppen

Länsstyrelsen Handläggaren Anders

80

Kapitel 4

Gruppen går igenom grupperingarna en efter en, och skriver ned namn på de personer som finns i varje intressentgrupp och som man vill ha kontakt med. Det är viktigt att inte se intressenterna som anonyma grupperingar utan att känna till individerna som gruppen består av. Att veta vem eller vilka som ska kontaktas för en viss intressentgrupp är en stor fördel. Det blir då betydligt enklare att se vilka källor

det finns som kan ge svar på frågor som uppstår i projektet. Att veta vilka specifika personer som är projektets intressenter är också en förutsättning för att man ska kunna jobba enligt den agila värderingen kommunikation före dokumentation. Namnen skrivs på nya post-it-lappar som fästs i eller intill respektive cirkel. Anledningen till att det ska vara ritade, fasta, cirklar för intressentgrupper men post-it-lappar för individer är enkel: Intressentgrupperna är (oftast) bestående genom hela projektet, men individerna byts ofta ut. Någon slutar sin anställning och någon ny börjar. Det är då enkelt och praktiskt att rycka bort en post-it-lapp och ersätta med en ny. Proceduren upprepas för intressenter som påverkas av projektet. Nu har gruppen en översiktlig intressentkarta som visar såväl grupperingar som individer. Man bör se till att övningen inte resulterar i ett för stort antal namn där gruppen i efterhand inte kan förstå vilka syften de olika personerna fyller. När varje intressentgrupp har minst en utsedd individ tejpas blädderblocksbladet upp på väggen. Det bästa är om gruppen har ett eget rum för att arbeta i (projektrum) men om det inte går att ordna kan en vägg i en korridor användas. Det är bra om gruppen har en egen plats som blir en naturlig träffpunkt och där planer och den här sortens information kan sättas upp. Det ger en mer levande bild av projektet än att bara spara filer digitalt. Att använda blädderblocksblad kan verka förlegat i vår högteknologiska värld, men det har sina fördelar. Hela gruppen kan när som helst få en översiktlig och informativ bild över aktörerna i projektet. En ny projektmedlem kan ställa sig framför bladet och enkelt bli insatt i projektet genom att förstå individerna och deras medverkan i projektet. Intressentanalysen är till nytta redan i detta skede men kan bli än mer användbar om nästkommande moment genomförs.

Intressenternas relation till projektet Gruppen skriver av samtliga individer från blädderblocksbladen i en lista. Intill namnlistan görs två kolumner som ges rubrikerna engagemang och kommentar. Gruppen diskuterar sedan vilket engagemang intressenterna har i projektet. Resultatet från diskussionen skrivs sedan ned i kolumnen engagemang.

Förstudien

EXEMPEL PÅ FRÅGOR OM INTRESSENTENS ENGAGEMANG ■ I

vilken omfattning behöver de vara en del av projektet?

■ Behöver vi hålla löpande kontakt med intressentgruppen eller ska vi endast bjuda in dem när vi presenterar delresultat?

engagemang

kommentar

Anna Kalle Stina handläggaren Anders S. Svensson

Gå på djupet med de viktigaste intressenterna Gruppen diskuterar sedan om det är något som är extra viktigt att veta kring intressenterna och som förtjänar någon typ av kommentarer för att underlätta för projektarbetet. Finns det exempelvis flera leverantörer nedtecknade som behöver jämföras? Kan det vara bra att förtydliga inom vilka områden de ska jämföras? Allt som underlättar det kommande projektet skriver gruppen ned i kolumnen kommentar. Efter dessa fyra steg har gruppen en både överskådlig och användbar karta över vilka intressenter som är viktiga för projektet och på vilket sätt de är av betydelse. Nu när gruppen vet vilka de viktigaste intressenterna är och även har fattat beslut kring vilka som ska engageras i projektet är det dags för nästa steg: Att samla dem för att utkristallisera projektets vision.

82

Kapitel 4

EXEMPEL - INTRESSENTANALYS

Vi ritade en cirkel för varje grupp

Bokprojektet

och diskuterade namn på lämpliga

Jag driver ett företag där jag hjälper

referenspersoner som kan tänkas vil"

andra att arbeta med agil projektled-

läsa boken.

ning. Nu ska jag skriva en bok i ämnet. I ett första skede har jag och min

Under utvecklingen av boken har intressentanalysen utökats succes-

kompanjon John funderat över lämpliga

sivt. Projektledaren Anna Andersson

intressentgrupper för boken. Vi började

(fingerat) gav oss kommentarer kring

diskutera vilka som påverkar bokprojek-

de delar av bokmanuset som har med

tet och skrev grupperingen:

förstudien att göra men påpekade

■ Förlaget

själv att hon inte har tillräckligt med kunskaper om genomförande för att ge

Därefter frågade vi oss vilka som på-

input till det kapitlet. Vi har då fått leta

verkas av projektet och identifierade

vidare efter någon med den erfarenhe-

följande tre grupper:

ten inom intressentgruppen arbetande

■ Arbetande projektledare.

projektledare och efterfrågat åter-

■ Konsulter inom projektledning och ledarskap.

koppling. Bilden har hela tiden växt och med information om vem som kan vad, har vi senare i processen enkelt

■ Studenter och deltagare på

kunnat gå tillbaka till rätt personer för

kurser i projektledning.

att få återkommande återkoppling.

Visionen För att gå åt rätt håll måste vi veta vilket håll vi ska gå åt, det vet alla som någon gång läst Alice i underlandet. Och för att veta vilket håll vi ska gå åt måste vi våga börja med att tänka stort och acceptera den mycket stora osäkerhet vi befinner oss i när vi ska teckna de stora penseldragen för ett projekt. Jag upplever att allt för många projektgrupper brister i att reda ut vilka långsiktiga mål och visioner projektet har och skälet till det är ofta rädsla. När vi är ute på osäker mark blir vi rädda för att göra fel och för att slippa rädslan fokuserar vi istället på det vi kan. De flesta människor i ledande position kan organisera och strukturera arbete i sömnen om det skulle behövas. I samma ögonblick som riktningen tas upp för diskussion, börjar de rita WBS:er, logiska nätverk eller organisationskartor för glatta livet.

Förstudien

83

Men för att få projekt att bli effektiva måste vi våga diskutera och reda ut projektets vision och mål på djupet. Det betyder inte att en massa dokument eller kartor ska produceras, vilka förvisso kan ge en skenbild av produktivitet. (Det finns ju en lockelse i att kunna visa upp för överordnade vilka fantastiska resultat vi åstadkommit av en dags möte genom att peka på de kartor och scheman man redan producerat.) Tvärtom är det bättre att skifta fokus från dokumentationen och istället ha som mål att arbeta fram en vision som är så koncis och tydlig att den ryms på ett enda papper.

Kortfattat is king De bästa visionsbeskrivningar som vi hittar är sällan särskilt utförliga. Vissa kan till och med rymmas i en enda mening. Men för att förtydliga och specificera projektets mål kan en ritning, några exempel, en prototyp eller en modell komplettera den skrivna visionen. Inom agila metoder kallas detta för visionsdokument. Ett visionsdokument ska visa vad vi vill åstadkomma, helst med både bilder och ord. Att använda bilder ger ofta en bättre tydlighet och sammanfattar budskap och ideer på ett slagkraftigt sätt.

84

Kapitel 4

Apagoreuetai to kapnisma Grekiska Pu?enje zabranjeno Kroatiska Vietato fumare Italienska Defense de fumer Franska Rökning förbjuden Svenska

En bild kan effektivt sammanfatta budskap. Att en vision ska kunna sammanfattas på en enda sida kan vara svårt att acceptera, särskilt för den som jobbar i stora, strukturerade projekt utifrån detaljerade business case och hundratals sidor av resultat från omfattande förstudier. Och poängen är inte att denna typ av dokumentation är bortkastat arbete. Tvärtom är det bra att skriva av sig sina tankar för att de ska bli konkreta och tydliga. Det kan dessutom göra det lättare när man är flera beställare inblandade. Men centralt i det agila arbetssättet är att visionen ska vara kommunicerbar och begriplig för alla. Därför är tydligheten som en kortfattad vision ger så oerhört viktig. Många misslyckas med denna sista bit — man är nöjd med att ha specificerat många detaljer och lägger en sista lilla gnutta energi på en sammanfattning. Trots att det är den sammanfattande bilden som är viktigast för projektet. Risken med att skriva ett för långt och omfattande visionsdokument är dessutom att det börjar betraktas som ett löfte istället för en vision. Låter det konstigt? Löften, eller åtaganden om man så vill, är bra för oss om de är tydliga kring nyttan med det vi ska åstadkomma men inte om de preciserar de exakta detaljerna. Genom att vänta till sista sekunden med att bestämma de exakta detaljerna så utesluter man inte alternativa, bättre lösningar. Om man istället bestämmer de exakta detaljerna tidigt så finns risken att man tar på sig skygglapparna för alternativa lösningar. I en snabbt föränderlig miljö är tidiga åtaganden det bästa receptet för misslyckande.

Förstudien

85

Projektanalys Ett sätt

att göra ett visionsdokument är att utgå från en metod som kallas Projektanalys. Projektanalysen lärs ut på magisterprogrammet i projektledning på Karlstads universitet och har tagits fram av Lennart Ljung som har använt metoden i många sorters projekt. Metoden fungerar såhär: samla intressenter som har möjlighet att påverka projektet till en workshop. Ställ frågan: "Vad är projektets resultat?" och låt alla fundera för sig själva eller diskutera två och två under tio minuter. Påpeka att de ska skriva ned sina tankar. Använd ett blädderblocksblad eller en whiteboardtavla för att rita upp följande figur:

Effekter

Leverabler

Kortsiktiga effekter

Långsiktiga effekter

Viktiga aktiviteter

Projektanalys för att identifiera leverabler, långsiktiga effekter, kortsiktiga effekter och viktiga aktiviteter.

Gå sedan laget runt och låt var och en läsa upp vad de har skrivit och hjälps åt att tillsammans föra in det föreslagna resultatet i rätt ruta. Detta gör att hela gruppen av intressenter får en tydlig bild av hela projektet och framför allt om det är saker som man inte vet. Är det väldigt tomt under "Långsiktiga effekter" kanske projektet borde avbrytas? Saknas leverabler betyder det kanske att man vet för lite om vad projektet verkligen ska åstadkomma, kanske en djupare förstudie behövs för att först utreda vad det verkligen är som ska levereras?

86

Kapitel 4

Checklista Roman Pichler, som är en konsult inom agila metoder, ger en bra sammanfattning på vad visionsdokumentet ska ge svar på. Nedan listas frågorna fritt översatta och något anpassade. FRÅGOR SOM VISIONSDOKUMENTET SKA GE SVAR PÅ 1.Vem ska köpa eller använda projektresultatet? 2. Vem är beställare av projektresultatet? 3. Vilka behov hos användaren ska projektresultatet tillgodose? 4. Vilka attribut/delar/funktioner är kritiska för att tillgodose användarens behov? 5. På vilket sätt särskiljer sig projektresultatet från liknande produkter eller lösningar? Vad är projektresultatets USP (Unique Seiling Propositions/Points)? 6. Vilka tids- och kostnadsramar har projektet? Den svåra delen att begränsa omfånget av är svaret på fråga 4 ovan. Man vill gärna rada upp ett antal fantastiska funktioner eller attribut som ens projektresultat ska åstadkomma utan att fundera över vilka av dessa som verkligen är kritiska. Lynn och Reilly (2002) undersökte ett antal framgångsrika mjukvaruprodukter och insåg att det som skilde dessa från de medelmåttiga var att de innehöll färre uttalade, kritiska, funktioner.

Planera kommunikationen För att leva efter det agila manifestets princip kring att kommunicera snarare än att dokumentera måste man ha skapat förutsättningar för informationsutbyte i projektet. För att arbetet under projektets gång ska flyta smidigt behöver man tidigt bestämma hur kommunikationen ska gå till. I många traditionella projektmodeller skapas inte kommunikationsplanen förrän i slutet av planeringsfasen. Att vii agila metoder skapar kommunikationsplanen redan under förstudien är för att vi redan här måste få åtaganden kring medverkan i projektet. Att till exempel en beställare ska vara tillräckligt närvarande under projektet kan vara en viktig förutsättning, därför måste

Förstudien

87

man redan i tidigt skede ha beslut kring att få den mängd tid av beställaren som man vill ha. Det finns många typer av kommunikation. Den kan äga rum via telefon, skype, videokonferenssystem eller brev i fysisk eller elektronisk form. Agil projektledning förordar alltid fysiska möten i så stor utsträckning som möjligt. Med personliga möten har vi större möjlighet att uppfatta alla nyanser av den information som vi skickar till och från varandra. Det är därför en kommunikationsplan i agila projekt ofta fokuserar på just kommunikation genom möten. Men hur går det då om gruppen jobbar utspridd över världen i ett så kallat distribuerat projekt? Går det inte att arbeta agilt då? Jo, visst gör det det. Däremot kräver det vissa anpassningar. Dessa beskrivs i kapitel 8, i ett avsnitt som handlar om utmaningen med att arbeta på distans. I projekt som drivs med agila metoder är det viktigt med kontinuitet. Kontinuiteten har många fördelar och gör projekt effektiva. Med fasta rutiner för möten blir det mindre risk för dubbelbokningar och människor får svårt att skylla ett missat möte med ett "Jaha, var det klockan åtta vi skulle ses idag? Då måste jag ha skrivit fel i min kalender". Projekt med fasta mötestider har, enligt min erfarenhet, färre problem med delaktighet på möten.

Hur, vem och varför? Det är viktigt att kommunikationsplanen diskuteras, förankras och blir till ett styrande dokument för att underlätta för projektet. Men innan man ger sig i kast med att skapa kommunikationsplanen vill jag uppmärksamma läsaren på två saker att tänka på angående kommunikationsansvar: ■ Lämpligaste formen för information och kommunikation.

Är de möten som normalt används i verksamhetens projekt självklart något som måste ske i mötesform? Eller skulle det gå att spara tid genom att ha mötet via telefon eller skype istället? Eller kanske befinner man sig i en verksamhet där alla bombarderas av allt för mycket mejl för att information i denna kanal ska kunna väcka intresse. Då kanske det är bättre att skicka ut ett papper med den gamla hederliga internposten för att väcka uppmärksamhet? Precis som i marknadsföring är det viktigt att informationen når fram och får förväntad effekt. Att fundera en extra gång över valet av kommunikationsform är oftast till stor nytta.

88

Kapitel 4

■ Vem som ska ha information.

Precis som i punkten ovan är det ett otyg att dränka alla i sin omgivning med information trots att de kanske bara är sparsamt delaktiga i eller intresserade av information rörande projektet. Utgå ifrån intressentanalysen och fundera över vem som verkligen behöver informationen.

Kommunicera mötets syfte För att få människor delaktiga i möten är det viktigt att de förstår anledningen till att de ska närvara. Många anställda klagar över att de går på så många meningslösa möten. Tyvärr är ofta problemet med möten att syftet inte har kommunicerats tillräckligt tydligt. När mötesdeltagare inte vet vilket syfte, mål och förväntat resultat ett möte har så är det svårt att vara såväl bidragande som närvarande. Effektiviteten förbättras för alla parter om varje person har förberett sig inför mötet genom att fundera över de tre enkla punkterna nedan. TRE FRÅGOR ATT FUNDERA PÅ INFÖR MÖTEN ■ I vilken egenskap medverkar jag i mötet? Är det jag som avdelningschef som förväntas fatta beslut eller för att jag har

expertkompetens inom ett visst område? ■ Vilka förväntningar har gruppen på mig under mötet? Förväntas jag presentera något eller ha åsikter i en viss fråga? ■ Vad ska mötet mynna ut i? Förväntas ett beslut fattas under mötet, ska mötet utmynna i ett förslag till beslut eller rör det sig om ett renodlat informationsmöte?

Om man inte vet svaret på dessa frågor är det en god ide att reda ut dem med mötesledaren inför mötet. Genom att förbereda sig på det här sättet kommer alla möten att bli effektivare.

Förstudien

89

Kommunikationsplanen För att skapa en gemensam syn på varför möten genomförs och hur de är tänkta att fungera är det bra att ta fram en kommunikationsplan. En kommunikationsplan är helt enkelt en lista som förslagsvis kan innehålla följande kolumner: ■ Namn på mötet - gärna ett beskrivande namn som enkelt tydliggör mötets funktion (exempelvis "styrgruppsmöte" eller "dagligt stå-uppmöte".) ■ Datum/Dag - för enskilda möten ett specifikt datum och för återkommande möten en viss dag i månaden eller veckan (exempelvis "den 1:e i varje månad" eller "varje onsdag".) ■ Ansvarig - den person som ska se till att mötet blir av och ordnar allt praktiskt såsom att boka lokal, beställa bubbelvatten eller ta med sig dator och projektor (exempelvis "scrum master" eller "produktägare Eva".) ■ Tid - mötets starttidpunkt (exempelvis "15.00" eller "i samband med lunch") ■ Varaktighet - beskrivning av hur länge mötet förväntas hålla på (exempelvis "två timmar" eller "till klockan 16.30"). Är man agil bestämmer man alltid tidsramen för projektets möten (timeboxing). ■ Kommentar - eventuella förtydliganden kring syfte, mål eller något annat som underlättar för mötesdeltagarna (exempelvis "protokoll tas fram senast dagen efter mötet och ligger på server X under mappen Y" eller "samtliga projektgruppsmedlemmar förväntas närvara".)

90

Kapitel 4

Kommunikationsplan för projekt

Datum

Namn på projekt

Dat/dag

Ansvarig

Tid

Varaktighet

Kommentar/ syfte

Uppstartsmöte

Leveransdemo sprint i

Stå-upp-möte

Workshop Hur får man till en effektiv workshop för en förstudie? Den enkla och tråkiga sanningen är: noggrann planering. Även om det agila handlar om att snabbt få fram fungerande projektresultat betyder det inte att noggrann, detaljerad planering av viktiga moment är av ondo. Tvärtom. Än en gång handlar detta om värderingar från Lean som är viktiga att ha i bakhuvudet. Om gruppen inte utnyttjar sin tid optimalt när man är samlad så är det också slöseri. Det är naturligtvis mindre resursslöseri om projektledaren lägger någon eller några timmar på att förbereda en workshop än om en hel grupp tillbringar en workshop tillsammans utan att ha tydliga syften, mål och förväntade resultat. Att börja kan vara enkelt men att börja effektivt är svårare och kräver planering och detaljering. Djävulen är som bekant i

Förstudien

91

detaljerna och det är en god i& att försöka att hålla honom utanför workshopen. Så vad är då viktigast för att få en bra workshop? Jag anser att de avgörande faktorerna kan rangordnas i följande fallande skala: AVG ÖRANDE FAKTORER FÖR EN EFFEKTIV WORKSHOP i. Vilka som kommer. 2. Vilka ämnen som tas upp. 3. Hur länge varje ämne får ta plats.

Utan rätt personer blir det aldrig en bra workshop. Genom att utgå från intressentanalysen hittar gruppen svaret på vilka som bör medverka förutom gruppmedlemmarna själva.

Moderatorn En deltagare i workshopen som kan vara viktig att diskutera är moderatorn. Det underlättar för alla om en person är utsedd till att hålla i diskussionerna, tilldela ordet och hålla koll på tiden under workshopen. Det kan gärna vara en neutral person som inte är en del av projektet men som har erfarenhet av att vara moderator. En bra moderator kan göra underverk för en workshop eftersom moderatorn bara fokuserar på själva processen. Vilka har inte haft någon åsikt i ämnet? Börjar diskussionen cirkulera i samma resonemang? Är det dags för en paus? Den typen av uppgifter kan vara svårt för någon att axla som samtidigt är ansvarig för att till exempel dokumentera det som sägs eller som är beställare av projektet.

Agenda efter prioritet Att arbeta i workshopform innebär även här att vi måste ta till oss timebox-tänkande. Vi vet att vi aldrig kommer att få alla nödvändiga svar men vi måste komma fram till tillräckligt bra svar för att kunna besluta om att gå vidare med vårt projekt. Beställaren måste tillsammans med gruppen bestämma vilka områden som är mest prioriterade. Agendan bör därefter återspegla prioriteringen genom att ha de viktigaste punkterna först på dagen och därefter i fallande ordning efter viktighet. Tillsammans bestämmer ni sedan hur lång tid varje punkt bör diskuteras.

92

Kapitel 4

Workshopregler När workshopen börjat är det viktigt att alla får reda på vilken agenda och vilka regler som gäller. Ju tydligare reglerna är desto bättre. Det betyder inte att det måste finnas en massa regler, bara att de är tydliga. En bra grundregel är: ett ämne i taget. Om alla håller sig till den regeln finns mycket tid och energi att vinna. Att vara agil är ju dessutom att vara förändringsbenägen så en annan bra regel är: Att man börjar med den här regeln men moderatorn får när som helst utse andra regler för att workshopen ska bli så effektiv som möjligt. Enkelt, eller hur? Istället för att ha långa diskussioner kring om handuppräckning är fantastiskt effektivt eller en nedvärderande regel som påminner om grundskoletiden, kan moderatorn lägga till eller ta bort regler allt eftersom.

Sammanfattning Förstudiens syfte är att ge svar på frågorna kring projektets orsak, nytta och tidsrymd. Den ska också ange hur mycket pengar som ska investeras i projektet samt vad som ska göras. Viktiga verktyg för att få fram dessa svar är intressentanalysen, visionsdokumentet och kommunikationsplanen. Workshop är en effektiv form för att genomföra förstudiens tre moment.

Övningar —

Intressentkarta

Tid för övningen: 60 minuter. Samlas i helgrupp för att genomföra en intressentanalys i ert befintliga eller kommande projekt. Börja med intressenter som påverkar och använd 10 minuter för att var och en hitta intressentgrupperingar och därefter 10 minuter för att individer för varje gruppering. Börja sedan om med intressenter som påverkas och gör om proceduren. Genomför analysen så långt som ni känner att det är värdefullt för projektet. Häng upp intressentkartan i ert projektrum och skriv ned individers namn, mejladresser och telefonnummer och sprid detta dokument inom projektet.

Förstudien

93

2 — Kommunikationsplan Tid för övningen: 30 minuter. Börja med att identifiera olika kommunikationsformer som är viktiga för projektet. För agila projekt bör åtminstone följande mötesformer definieras: ■ Sprint-planeringsmöte ■ Löpande avstämningar med produktägare ■ Stå-upp-möte ■ Demo-möte ■ Erfarenhetsmöte

Dessa mötesformer beskrivs ytterligare i kapitlen om planering och genomförande. Diskutera vilka ytterligare mötesformer ni kan behöva i gruppen.

Agil projekel.dni, ÖVNINGSBOK

Övningsboken: I kapitel

2

finns

praktiska övningar för att skapa er förstudie och även en estimatövning som kallas Ögonblicksestimat. Där finns även viktiga diskussionsövningar för att reda ut förväntningar kring olika roller i

94

Kapitel 4

projektet.

Planering

Tänk dig att det är nyårsafton och att du blickar framåt över det kommande året. Det är mycket du har tänkt göra och många saker som kräver planering. Om några månader kommer förberedelserna inför vårsäsongen. Din cykel måste förmodligen ses över men det behöver du ju inte planera för än. Nej, just nu är det den närmsta månaden som står i fokus. Exempelvis måste du hyra en skidbox och redan nästa vecka leta efter nya pjäxor inför skidturen i slutet av januari. Men först av allt måste du faktiskt lägga tankarna på skidresan åt sidan och fokusera på den närmsta veckan. På nyårsdagen kommer dina föräldrar på besök. Bäst att redan nu plocka fram älgsteken ur frysen och skriva en inköpslista inför morgondagens släktmiddag.

96

Kapitel 5

Planering på kort eller lång sikt Att endast detaljplanera för närmast kommande händelser är en agil princip. Vårens cykelbestyr detaljplaneras inte på nyårsafton utan hamnar på agendan först när snön börjar töa bort. Ett sådant synsätt är långt ifrån självklart inom traditionell projektledning. Ofta påpekas där att framgång hänger på hur Planer är värdelösa, detaljerat projektet planeras ända till planering är ovärderligt. dess sista dag, hur stora riskerna än är (Dwight D. Eisenhower) för att kraven kommer att ändras. Det är inte så att långsiktig detaljplanering är av ondo i sig. Men för förändringsbenägna projekt - och det innebär den stora merparten - så görs stor del av planeringsjobbet i onödan om man detaljplanerar för långt in i framtiden. Fastställer man på nyårsafton att cykeln ska tas ut, oljas och pumpas i vecka 15 kommer man att behöva göra om planeringsjobbet om det visar sig att snön ligger 60 cm djup vecka 14. Synsättet bekräftas av ett antal vetenskapliga studier. Exempelvis undersökte Dvir och Lechler (2003) 448 projekt och visade att förmågan att hantera förändring var betydligt viktigare än planeringen. Forskarna såg att effekten av god planering helt förlorades på grund av förändringar i projektet och det skedde i majoriteten av de undersökta fallen. Att planera ännu noggrannare har alltså inte så stor påverkan på projekt som många inbillar sig.

pp

Detaljplanera det närmaste Med ett agilt synsätt konstaterar man att målet "servad cykel" finns med i den grova planen framöver, men att det än så länge inte finns något behov av att detaljera, alltså detaljplanera, några aktiviteter för målet. Vid varje eller vartannat veckoslut eller månadsskifte tittar man på målet och frågar sig: "Behövs målet 'servad cykel' detaljplaneras inför den kommande perioden?". Om svaret är nej så fortsätter målet att ligga längre ned på prioriteringslistan och man detaljplanerar andra mål för den närmaste perioden. Dras detta förhållningssätt till sin spets finns det kritiker som anklagar de agila metoderna för kortsiktighet. De agila förespråkarna å sin sida, kritiserar traditionalisterna för deras ibland överdrivna tro på tvingande detaljerad helhetsplanering, vilken ändå får skrotas så fort projektets omständigheter ändras. Ett praktiskt sätt att slippa denna problematik är att ta det bästa

Planering

97

från båda världar, snarare än att ställa deras ytterligheter mot varandra. Därför beskriver detta kapitel hur såväl långsiktig som kortsiktig planering kan utföras i agila projekt. När genomförs planeringen då? Det beror på projektets storlek och omfattning. För större projekt sker såväl förstudie som planering utanför projektet men många projekt (både stora och små) använder den första sprinten till att göra planeringen. Den sprinten döps ofta till uppstartssprint eller sprint noll eftersom inget konkret projektresultat blir som resultat av denna sprint, endast planeringsdokumentation och andra förberedelser som gör att genomförandet kan påbörjas så effektivt som möjligt i nästa sprint (sprint ett).

Planer - inte åtaganden Långsiktiga planer är alltid gissningar, vilket är en sanning som projektets omvärld måste bli påmind om. Den långsiktiga planen är inte ett åtagande utan ett verktyg som kan hjälpa projektgruppen att nå målet. Och vad är då målet? Jo, ett projektresultat som ger största möjliga nytta och motsvarar allas förväntningar. Målet är inte att ha följt planen så bra som möjligt, även om det är vad många verkar tro. Men trots att långsiktiga planer är gissningar så är de nödvändiga för att åstadkomma framgångsrika projekt. De agila metoderna innebär ett arbetssätt som gör att man kan börja skapa projektresultat utan att ha någon sorts långsiktig planering men det betyder inte att det är rätt att göra det. En snickare vet hur man gör för att regla upp väggar men det betyder inte att det är rätt att börja spika utan att ha fått en ritning först. Samtidigt - vilket poängteras ovan - innebär det ett resursslöseri om verksamheten detaljplanerar och lägger för mycket energi på arbete som sedan ändå måste rivas upp. Det viktiga med långsiktig planering för agil projektledning är att hitta rätt detaljeringsnivå. Ett sätt att åstadkomma det är att göra olika planer för olika tidshorisonter.

Fem nivåer av planering För att täcka in all sorts planering, både lång- och kortsiktig, finns fem lämpliga nivåer att använda sig av. PLANERING I AGILA PROJEKT

7. Vision, 2. Färdplan, 3. Leveransplan, 4. Sprintplan, 5. Daglig plan

98

Kapitel 5

Visionen är ofta framtagen i samband med förstudien (visionsdokumentet) och färdplan och leveransplan bör senast vara klara i slutet av en så kallad uppstartssprint (sprint noll). Leveransplan och sprintplaner görs om löpande under hela projektet. Den femte nivån av planering kallas daglig plan. Att ta fram denna plan är ett arbete som sker dagligen vid det så kallade stå-uppmötet. Sprintplanen, den dagliga planen och arbetet i genomförandefasen i projektet beskrivs i nästa kapitel.

Färdplan En färdplan (på engelska roadmap) ger en översiktlig bild av när olika sorters projektresultat ska vara färdigställda utan att garantera datum eller detaljer. Det är, näst efter visionen, den mest långsiktiga planeringen av projektet och bör inte gå in på detaljer. För att skapa en färdplan är det bra att använda sig av två traditionella projektplaneringstekniker, PBS och logiska nätverk.

PBS - product breakdown structure En PBS är ett dokument som visar alla delresultat eller delmål som projektet innehåller. Det är en visuell modell som visar en hierarkisk nedbrytning av våra delresultat.

EXEMPEL - PBS Beställaren Anna har formulerat visionen för det ettåriga marknadsprojektet "Morotshår i Danmark" där målet är att företaget ska ha lanserat hårtoningsprodukten OrangeSuper i hela Danmark och uppnått en försäljningsvolym av mo 000 flaskor före årsskiftet. Anna bryter ned projektet i följande leveranser och delmål utan att i detta skede tänka på i vilken ordning de behöver genomföras:

Projekt Morotshår

Färdigt

Etablerade

Genomförd

marknadsmaterial

försäljningskanaler

annonsering

Planering

99

EXEMPEL - PBS, FORTSÄTTNING Anna vill beskriva sin färdplan på kvartalsbasis och inser att PBS:en måste brytas ned ytterligare.

Projekt Morotshår

Färdigt

Etablerade

Genomförd

marknadsmaterial

försäljningskanaler

annonsering

Film för

Kartläggning

demonstration

av kedjor

Vykort

Färdigförhandlade avtal

Broschyrer Levererade produkter till butiker Bilder för säljmöten

Anna bestämmer sig för att delmålet "Genomförd annonsering" är tillräckligt detaljerat och bryter därför inte ned den grenen till ytterligare en nivå.

Ett annat sätt att strukturera

projektet, som många fått lära sig i projektledarutbildningar, är att skapa en Work Breakdown Structure (WBS) som visar allt arbete som ska åstadkommas i projektet. Tekniken är densamma — att bryta ned hela projektet till hanterbara delar — men här är det arbetet som står i fokus istället för leveranserna. En WBS tenderar lätt att bli alldeles för detaljerad för den här planeringsnivån, ayseende alla aktiviteter som ska utföras, så för färdplanen är PBS att föredra. Men den viktigaste aspekten

100

Kapitel

5

till att välja PBS hellre än WBS är att vi med WBS riskerar att göra gruppens arbete. Tidigare beskrevs vikten av att låta gruppen ha mandatet kring hur arbetet ska genomföras, och om vi beskriver helheten i vårt projekt med en WBS har vi redan till stor del talat om hur arbetet ska genomföras. För tidigt. För, som du kanske kommer ihåg, vill vi vänta med att besluta om detaljerna tills det är absolut nödvändigt. Visionsdokumentet som visade projektets slutmål är bra att utgå ifrån för att skapa en PBS.

Logiska nätverk Nästa steg mot att ha en färdig färdplan är att få en bild av i vilken ordning projektets delleveranser måste ske. Här kan tekniken för logiska nätverk användas. I ett logiskt nätverk utgår man ifrån de leveranser som beskrivits på lägsta nivån i den tidigare skapade PBS:en och placerar dessa i den ordning man vill att varje del ska levereras (eller färdigställas). Nätverket ritas med start från vänster och läses steg för steg åt höger. Om projektet kan arbeta med två mål samtidigt ritas dessa parallellt i modellen. Detta är en väldigt förenklad och avskalad version av användandet av logiska nätverk. Orsaken till det är att agila projekt gör denna planering på en övergripande nivå. I boken Projektledningsmetodik av Tomas Jansson och Lennart Ljung går det att läsa mer ingående om logiska nätverk.

Planering

101

EXEMPEL - LOGISKA NÄTVERK Anna bestämmer ordningen på sina leveranser och börjar med att rita ut ordningen för "Färdigställt marknadsmaterial".

Start

Bilder för

Broschyrer

säljmöten

Film för

Slut

demonstration

Vykort

Anna funderar över vad som ger mest

sist i ordningen eftersom produkterna måste

nytta i projektet. Genom att ha bilder för

finnas tillgängliga i butikerna först. Därefter

säljmöten klara tidigt kan säljare komma ut

funderar Anna över de andra aktiviteterna

och träffa återförsäljare tidigt i projektet.

och när de lämpligtvis bör färdigställas i

"Vykort" och "Film för demonstration" är rik-

projektet. Hon ritar in dem parallellt med

tade direkt till konsument och måste komma

tidigare planerade mål:

Start

Bilder för säljmöten

Kartläggning av kedjor

102

Levererade Broschyrer

produkter till butiker

Film för

Genomförd

demonstration

annonsering

Slut

Färdigförhandlade

Vykort

avtal

Strecken mellan leveranserna visar beroen-

vara färdig innan projektet ska färdigställa

den, det vill säga vilka aktiviteter som måste

"Film för demonstration" och "Vykort". Dess-

vara levererade för att nästa leverans ska

utom vill projektet att både "Film för demon-

vara möjlig (eller lämplig). Bilden visar att

stration" och "Vykort" ska vara klara innan

"Levererade produkter till butiker" måste

annonseringen ska påbörjas.

Kapitel 5

Ungefärliga datum Det logiska nätverket övergår till en färdplan genom att ett tidsperspektiv tillförs. Tidsperspektivet beror på projektets storlek men färdplanen ska helst visa hela projektet, från start till slut. För ett tvåårsprojekt kan en färdplan skapas med kvartalsindelning och för ett halvårsprojekt kan färdplanen vara uppdelad på månader.

EXEMPEL - FÄRDPLAN Kvartal 1, 2020: Bilder för säljmöten och kartläggning av kedjor klara. Kvartal 2, 2020: Färdiga broschyrer och förhandlade avtal klara. Kvartal 3, 2020: Levererade produkter, film för demonstration och vykort färdigställda. Kvartal 4, 2020: Annonseringen genomförd.

En färdplan ger sällan falska förhoppningar eller besvikna miner eftersom den inte innehåller några strikta åtaganden i form av exakta datum. Det är ett väldigt bra verktyg för att kommunicera projektets innehåll utan att behöva fastna i detaljer. För ledningen innebär det dessutom att alla detaljer kan omvärderas och fattas beslut om i rätt tid, det vill säga så nära genomförandet som möjligt.

Ordning utifrån nytta Färdplanen ska prioriteras utifrån nyttoperspektiv vilket innebär att beställaren måste fundera på följande frågeställning för varje mål: "Ger detta mest nytta för projektet vid den här tidpunkten? Kan jag ändra ordning på något mål för att få ännu mer nytta så tidigt som möjligt i projektet?". Naturligtvis finns det olika praktiska hinder som gör att några delmål måste följa en viss ordning. Brofundamenten måste rimligtvis byggas upp innan vi kan bygga bron. Men alldeles för ofta låter verksamheter en förgivettagen ordning styra utan att reflektera över om det går att ändra ordningen för att få större nytta.

Planering

103

PROJEKT MOROTSHÅR, FORTSÄTTNING Den danska prinsessan Clementine gifter sig i januari. Turistinvasionen och mediepåslaget förutses bli enorma, och prinsessans röda kalufs kommer att synas överallt. Kanske borde vykorten som berättar att OrangeSuper snart lanseras färdigställas i samband med den kongelige bröllopsyran för att kunna börja spridas redan då? I så fall måste ordningen ändras i färdplanen för att projekt Morotshår ska bli ännu mer framgångsrikt. Förändringen baseras då helt på vad som antas ge mest nytta för projektet.

Leveransplan Den tredje planeringsnivån kallas leveransplan och ska innehålla exakta tidsgränser och viktiga datum för vårt projekt. Leveransplanen tas fram under uppstartssprinten men kan, beroende på projektets kalendertid, behöva tas fram vid flera tillfällen i projektet. I traditionell projektledning talar man ofta om milstolpar och det är dessa som ska visas upp i leveransplanen. Leveransplanen används internt och mot externa leverantörer som är beroende av exakta tider för att de ska arbeta så effektivt som möjligt. Leveransplanen behöver inte inbegripa hela projektet utan ska visa den tidsperiod som projektet för tillfället har nytta av att kommunicera exakta datum kring. Det innebär helst minsta möjliga tidsperiod som vi garanterar leveranser för. Orsaken till det är att människor har lätt för att minnas exakta datum. Om projektgruppen en gång sagt "31 augusti 2016" men levererar den 1 september så kommer diskussionen att röra varför det blev försenat. Väldigt sällan ställer någon frågan "Spelade det någon roll att leveransen genomfördes den 1 september?" Missade datum uppfattas som misslyckanden och för att undvika onödig och dålig publicitet för projektet är det bättre att planera långsiktigt för hela projektet i den mindre detaljerade färdplanen istället för här i leveransplanen.

EXEMPEL-LEVERANSPLANEN 12 februari 2020: Färdiga bilder för säljmöten. 20 februari 2020: Första kartläggning av kedjor klar för att värdera. 21 mars 2020: Slutlig kartläggning av potentiella kedjor att förhandla med.

104

Kapitel 5

En leveransplan kan presenteras på olika sätt. Till exempel i form av en lista, som i exemplet ovan, eller med hjälp av ett förenklat Gantt-schema. Så hur gör man för att ta reda på om detta är en rimlig plan? Hur vet vi att de tänkta datumen med utlovade leveranser är möjliga för vår projektgrupp att klara av? Innan projektgruppen kan göra ett åtagande behöver de dela in det tänkta arbetet i ett antal sprintar. Antingen kan de utgå ifrån en milstolpe och planera arbetet fram till den eller så kan man låta tiden styra och bestämma sig för att exempelvis alltid planera för tre månaders arbete i taget. En sprint innebär ett eller flera mindre uttalade delmål. För varje sprint ska projektet slutföra eller leverera ett specifikt projektresultat. Produktägaren ansvarar för att ta fram en produktbacklogg (ofta tillsammans med projektgruppen) som visar dessa delmål i en tidsprioriterad ordning. Åtminstone internt innebär det att den detaljerade leveransplanen visar såväl sprintarnas längd och målet för varje sprint som summerat leder fram till en specifik leverans (milstolpsresultat) eller för en bestämd tidsrymd, till exempel tre månader.

Leverans i Marknadsföring färdig

Sprint o

Sprint 1

Sprint 2

Sprint 3

• • •

2 veckor

2 veckor

2 veckor

2 veckor

Leveransplan för Projekt Morotshår i form av förenklat Gantt-schema.

Planering

105

Sprintens slutdatum (kalendertid) är helig och projektgruppen strävar efter att uppnå det uppsatta målet utan möjlighet att justera sprintens sluttid. Om allt arbete inte hinns med är det i stället vissa aktiviteter som måste strykas. Varje sprint innebär bland annat att sprintplanering, demonstration och test av delresultat samt avrapportering och erfarenhetsmöte genomförs. Antalet sprintar och deras längd bestäms utifrån vilka garantier som gjorts mot omgivande verksamhet. Om exempelvis projektet är ett kundprojekt där krav nummer 1 till och med krav nummer 26 garanterats till fredag 20 april så måste anpassningar ske baserat på hur viktigt detta datum är. Om avtalet säger att projektgruppen måste böta 10 000 kronor per dag för varje dag senare än 20 april gör projektgruppen klokt i att planera in luft, det vill säga en "tom" sprint som buffert inför leveransen, vilket ger projektet tid för att hantera sista-minuten-justeringar. Varje sprint innebär ett delmål för projektet. Ibland finns det skäl att planera in "tom" tid innan slutleverans. Den rättrogne agilisten arbetar egentligen inte med tomma sprintar. Ett korrekt agilt arbetssätt innebär att tiden är helig men att innehållet varieras baserat på de prioriteringar som görs. Emellertid innebär det agila arbetssättet också att anpassningar ska göras efter de förutsättningar som råder. Om leverans garanterats till ett visst datum utan möjlighet till bortprioriteringar av krav - vilket ofta är fallet i till exempel offentliga upphandlingar - finns det skäl att ha en buffertsprint. Däremot finns det många projekt som exempelvis vänder sig till konsumenter och därmed inte har någon "helig" deadline. Nya funktioner på sociala mediesajter är exempelvis bara glada nyheter för användarna och inte något som utlovats till ett visst datum. För den typen av projekt behövs självklart inga buffertsprintar.

106

Kapitel 5

Sprintplan Den fjärde nivån är sprintplanen. En sprintplan visar det arbete som gruppen åtagit sig att utföra under den pågående sprinten och den tas fram under första dagen i den nya sprinten. För många är sprintplan och sprintbacklogg samma sak, även om somliga skiljer dem åt genom att i en sprintplan visa upp praktiska detaljer som datum, frånvaro från projektet och annat som är knutet till tid och datum. Sprintbackloggen är själva delmålen och aktiviteterna som ska utföras under sprinten och denna beskrivs senare i detta kapitel.

Sprintarnas längd Eftersom varje sprint är en ny runda av sprintplanering, demonstration, test, avrapportering och erfarenhetsmöte, är det viktigt att sprintarna vare sig blir för långa och omfattande eller för korta. Tanken är att varje sprint ska skapa något användbart, något som ger nytta. Om det tar lång tid att skapa ett projektresultat som innebär nytta för verksamheten är det bra att arbeta med långa sprintar. Med för korta sprintar däremot kommer projektgruppen riskera att göra halvfärdiga resultat i varje sprint. Om projektgruppen har levererat saker med mycket felaktigheter bör längden på sprintarna kortas ned. Med kortare sprintar har gruppen möjlighet att testa projektresultatet ordentligt utan att komplexiteten blir för hög. Med längre sprintar, och därmed mer innehåll eller funktionalitet, kan det bli för mycket att testa inför varje leverans.

EXEMPEL - TESTA SPRINTVIS En projektgrupp bestående av ett gäng studenter ska ställa upp i den årliga Student-Formell-tävlingen och behöver därför bygga en väl fungerande motor. Om studenterna bygger alla delar av motorn innan de teststartar den blir det väldigt svårt att hitta eventuella fel. Om de i första läget istället bara sätter samman de delar som krävs för en tändstiftsgnista - och testar denna funktion - så vet de att motorn fungerar så långt.

Planering

107

Svårigheterna kring tidsuppskattningar beskrivs längre fram i kapitlet men redan här berörs tidsuppskattning för själva sprinten. Med korta respektive långa sprintar avses här mellan en och sex arbetsveckor, helst kortare än en månad. För att behålla fördelarna av ett agilt angreppssätt, bör man inte sträcka sprintarna längre än så. Om man läser en processbeskrivning av metoden Scrum så säger dess grundare Ken Schwaber (2004) att man bör sträva efter en månadscykel, 30 kalenderdagar, för varje sprint. Denna rekommendation är att se som en startpunkt: en lagom lång sprintlängd att prova i sitt projekt. Principen om ständig förbättring inom agil projektledning gör att det inte finns något rätt svar mer än det svar vi kommer fram till i det egna projektet, genom att prova och utvärdera efter varje sprint. Utöver de fem planeringsnivåerna finns två centrala verktyg som det agila projektet kan använda sig av både inför och under pågående projekt. De är produktbackloggen och sprintbackloggen som beskrivs senare i kapitlet.

Planering enligt SAFe Vad definierar slutet på ett projekt? För somliga projekt är frågan självklar: när projektet Flakmoppe-turn61 har gjort sin sista spelning är projektet slut och musikerna åker hem. För andra projekt kan slutet diskuteras: ska marknadsföringsprojektet avslutas när marknadsmaterialet är producerat eller när planscherna satts upp och flygbladen delats ut? För många it-tjänster som utvecklas finns inte ett naturligt slut, men samtidigt vill organisationer få fördelarna av att ha avgränsade perioder av tidsestimat, leverera funktionalitet och följa upp. Då kan slutet av ett projekt definieras av en tidsgräns istället, precis som i exemplet om British Telecom som beskrevs i Förstudiekapitlet, där projekt inte tilläts vara längre än ett kvartal. Logiken blir helt enkelt att man vänder på det, istället för att hitta "rätt" slut för projektet så bestämmer man t.ex. att varje projekt ska vara 10 veckor långt och sedan "fyller" man projektet med de krav som man estimerar att man hinner. Fördelen med ett sådant tänk blir att organisationen blir bättre på att estimera. Varje gång vet organisationen att man estimerar arbete för 10 veckor i taget och teamen tränas in i att lära sig vad som är rimligt att hinna med. Detta synsätt på planering är grundläggande för planering i SAFe.

108

Kapitel 5

Ramverket SAFe (Scaled Agile Framework) skapades som stöd för större organisationer där många team arbetar tillsammans och beskriver principer, rutiner och roller för olika nivåer inom organisationen. Det är skapat och detaljerat beskrivet för systemutveckling men mycket kan användas i andra typer av verksamheter som har behov av koordinering och samsyn. Även om vissa kritiska röster har höjts mot att SAFe skulle vara för stelbent så har ramverket redan fått stor spridning inom stora organisationer i flera branscher. SAFe beskriver vad som bör göras på teamnivå, programnivå och portföljnivå (för hela organisationen) för att det agila arbetssättet ska genomsyra allt från beslut på högsta nivå ned till ett effektivt arbete i teamen. På portföljnivån sköts affärsutveckling och utformning av övergripande funktionella och arkitektoniska krav (epics) från id& till genomförandestadium. All planering och detaljering visualiseras för att alla ska kunna förstå och granska det som görs. Flödet av planerade, påbörjade och avslutade krav visualiseras exempelvis på post-it-lappar på en stor väggtavla (se exempel nedan).

Planeringstavla

Intratt

Epic

Epic

Granskning (3)

Epic

Analys (3)

Epic

Backlog

Pågår

Klart

Epic

Epic

Planeringstavla som visar övergripande krav (epics). Siffrorna anger maximalt antal tillåtna krav per kolumn.

Planering

109

Programnivån handlar om att bryta ned och skapa tydliga funktionella krav (features) utifrån de övergripande kraven (epics). Förutom funktionella krav skapas även tekniskt viktiga krav (enablers) för saker som behövs för att kunna skapa funktionerna, exempelvis miljöer för att testa eller förändringar i arkitekturen. Detta visualiseras på en likadan planeringstavla som ovan men innehåller då features och enablers (istället för epics), så klart. På teamnivån utvecklas mjukvara och teamen behöver bryta ned kraven ytterligare. En central del av SAFe är att den detaljerade planeringen görs för ett programinkrement (PI), som motsvarar 3-4 sprintar, i taget. Planeringen sker då i workshopform under två dagar med alla team och intressenter samlade. Arbetsuppgifterna i planeringstavlan fördelas ut till de olika teamens backloggar under denna gemensamma planeringsworkshop (PI-planeringen). Nyckelordet här är "cadence", som ungefär betyder rytm. Det innebär att arbetet ska samordnas i de enskilda teamen så att de startar och levererar resultat samtidigt efter en i förväg bestämd tidsrymd, till exempel i sprintar om tre veckor och med en planeringshorisont på fyra sprintar så innebär det ett nytt planeringstillfälle var tolfte vecka. Tanken är att varje team själva väljer vilken uppgift de ska ta hand om under denna workshop, inte att "ledningen" ska bestämma vilket team som ska göra vad. Detta kallas ibland pull, alltså att teamen drar sina uppgifter från planeringstavlan utifrån vad de själva anser att de kan göra bäst, inte push som vore att ledningen skulle tvinga på arbete till varje team. För att teamen ska kunna arbeta sida vid sida mot ett gemensamt mål krävs en hel del koordinering mellan teamen så att man kan lösa gemensamma problem, exempelvis att man får veta när en uppgift är klar som en annan grupp är beroende av. För att visualisera dessa beroenden skapas under den två dagar långa planeringsworkshopen en så kallad programtavla där varje team visar vilka funktioner de ansvarar för och vilka beroenden dessa har till funktioner i andra team (se figuren nedan).

110

Kapitel 5

Sprint 2

Sprint 1

Sprint 3

Milstolpar

Team Glader

Team Butter .••....

. .

.•

Team Blyger . Team Kloker

. ••

Team Prosit

Exempel på programtavla som visar funktioner som har beroende till varandra och vilket team som ansvarar för vilken funktion.

Visst liknar programtavlan ett Gantt-schema? De enda skillnaderna är egentligen att programtavlan visar vilket team som gör vad, och att tidshorisonten anges i sprintar. Dessutom visar inte rutan som anger namnet på en funktion hur lång tid den tar att genomföra, bara när i ordning den ska skapas under sprinten. Det här var en kortfattad beskrivning av hur planering genomförs i SAFe. För att läsa mer om hur det fungerar rekommenderar jag websidan (www.scaledagileframework.com) som dessutom uppdateras allt eftersom ramverket utvecklas.

Planering

717

Produkt backlogg Krav och mål För att veta vad projektet ska syssla med behövs i planeringen även en överblick över de krav och mål projektet står inför. Inom agila projekt används termen produktbacklogg (product backlog) som är en prioriterad lista över de krav kunden förväntar sig att få tillgodosedda. Helst är kraven beskrivna med kundens terminologi. Ofta finns krav redan specificerade i offertförfrågningar eller annan dokumentation men i många fall handlar det om att projektgruppen tillsammans med kunden eller beställaren måste samlas, definiera och sammanställa kraven. Produktbackloggen täcker det tidsspann som är relevant - för ett kortare projekt innebär det hela projektet och för ett längre projekt bara en del i taget. Många kompromissar genom att alltid ha hela projektets krav i produktbackloggen men har krav längre fram i tiden på en mer övergripande nivå och detalj erar kraven löpande allt eftersom tiden går. Ordet mål kan bytas ut till leverabel, alltså ett delprojektresultat som ska levereras men för att hålla sig till en enklare terminologi används här genomgående ordet mål. För tydlighets skull definieras här skillnaden mellan krav och mål: ■ Krav - den förväntan som projektresultatet ska uppfylla. ■ Mål - det faktiska resultat som levereras för att tillgodose kravet.

Somliga tycker att skillnaden mellan krav och mål är självklarheter men man kan ofta se att denna skillnad suddas ut i kravspecifikationer för projekt. Här kommer därför två exempel: ■ Krav - en farkost som flyter och klarar en vikt på 400 kg även under hårt väder i minst två månader. ■ Mål - en flotte . ■ Krav - byggmaterial för en farkost som inte får överstiga 70 000 SEK. ■ Mål - timmer och rep till en flotte.

112

Kapitel 5

Varför är det viktigt att skilja på krav och mål? För att vi kan ha flera möjliga mål, alltså flera lösningsförslag, utifrån ett enda krav. I exemplen ovan skulle vi kunna ha ett antal möjliga mål utifrån kravet på en flytande farkost (såsom segelbåt, roddbåt eller kanot).

Gruppen väljer lösningen Det är viktigt att endast detaljera till en nivå så att man fortfarande tar tillvara projektgruppens kunnande. Det är projektgruppens expertkompetens som ska komma beställaren till nytta - genom att produktägaren anger sitt krav och gruppen föreslår ett eller flera alternativa mål (eller lösningar). Har man en van och väl insatt produktägare som behärskar projektgruppens terminologi är det inte särskilt svårt att landa i exakta mål. I situationer där produktägaren saknar projektgruppens kompetens är det däremot viktigt att hen får uttrycka sina krav men att projektgruppen föreslår mål och får produktägarens godkännande. Det här gör inte bara att projektet har bättre odds för att bli framgångsrikt, det skapar dessutom motiverade medarbetare som trivs bättre med sitt arbete tack vare det inflytande de får. En produktbacklogg kan därför innehålla såväl krav som mål beroende på produktägarens detaljkunskaper. Kravdiskussionen bör alltså analysera ett behov och landa i ett beslut kring val av lösning. I agila projekt genomför man båda dessa moment samtidigt, detaljering av såväl krav som lösningar görs alltså i sprinten. Varför då? Jo, för att i agil projektledning, precis som värderingarna i Lean säger, vill man genomföra arbete så nära det fattade beslutet som möjligt. Risken är annars att projektet beslutar om en lösning i en fas och sedan inser, när lösningen ska genomföras, att den beslutade lösningen inte längre passar. Det innebär att gruppen lagt energi på en lösning tidigare i projektet helt i onödan och den sortens resursslöseri ska så klart undvikas. En produktbacklogg kan se lite olika ut beroende på hur gruppen väljer att beskriva sina krav och mål. Ett sätt är att överföra delmålen från sin PBS eller sitt logiska nätverk och eventuellt bryta ned vissa delmål i mindre delar, framför allt de som ligger närmast i tid. Ett annat bra och vanligt sätt för att definiera krav i agila projekt är att utgå från användarens och andra olika rollers perspektiv. Tekniken för detta kallas användarhistorier.

Planering

113

Användarhistorier Ordet användarhistorier är en direkt översättning av engelskans user storfes.

HISTORIK Inom en metodik för systemutveckling som kallas RUP (Rational Unified Process) finns något som kallas "Use cases" och som översatts till användningsfall (eller ibland, felaktigt, användarfall) på svenska. Användningsfall beskriver hur olika typ av funktionalitet ska användas av olika roller i ett it-system. Ett användningsfall beskriver en viss sorts användare, en viss typ av funktionalitet och ordningen för hur funktionaliteten ska fungera i systemet. Kritiken som framförts mot användningsfall är de samma som kritiken mot allt för detaljerad dokumentation tidigt i projektet: vi riskerar att skapa för mycket dokumentation i ett tidigt skede som sedan behöver förändras, granskas och underhållas löpande under projektets gång. Inom de agila metoderna har istället användarhistorier lyfts fram som en sorts lätt variant av användningsfall som tvingar båda parterna att kommunicera (mer än dokumentera).

En användarhistoria är till för att förtydliga krav på ett kortfattat sätt. EXEMPEL PÅ ANVÄNDARHISTORIER ■ "Deltagare ska kunna resa ett fyrmannatält på träflotten". ■ "Den arbetssökande ska kunna hitta alla lediga jobb inom en viss bransch". ■ "Festivalbesökaren ska kunna gå torrskodd från tältområdet till festivalområdet på mindre än fem minuter".

För att kunna jämföra och prioritera nytta mellan olika krav kan användarhistorierna förtydligas med en kort förklaring till varför det finns ett behov av kravet. Här är några exempel på det: ■ "Cyklisten ska kunna fylla på luft i cykeln vid rastplatsen för att inte behöva ha med sig egen pump". ■ "Konsumenten ska kunna hitta varorna i ögonhöjd för att det ökar försäljningen av våra varor".

114

Kapitel 5

På det viset ser gruppen och beställaren inte bara själva kravet utan även orsaken till att kravet är viktigt. En enkel formel kan vara till hjälp för att formulera användarhistorier. De ovanstående har alla följande utseende: • [Roll] ska kunna (krav eller funktionalitet] för att forsakl. Att använda användarhistorier är ett enkelt och tydligt sätt för beställare att beskriva krav, mål och funktion för projektet på ett sätt som inte kräver detaljerad insikt i projektverksamheten. Med så korta beskrivningar av krav blir det inte särskilt kostsamt att under planeringsfasen ändra kraven om förutsättningarna ändrats.

AH

Uppgift

Namn

Festivalbesökare AH1

ska kunna se liveband spela på scenen

AH2

Samma mobila träscen som i fjol?

Personal ska kunna

Behöver (köpa

se besökares biljetter

och inreda) enkla

för att släppa in till

träbodar att

festivalen

sitta i

Festivalbesökare ska AH3

Kommentar

kunna sätta upp sitt tält på anvisad plats

Markeringar med målarfärg?

Prio Ansv

Tidsuppskattn

Källa

5 dagar

Sven

2 dagar

Inga

2 dagar

Leyla

Exempel på en produktbacklogg. Varje användarhistoria, AH, motsvarar ett krav och får ett nummer, en beskrivning och en tidsuppskattning. Det bästa sättet för att få en produktbacklogg för hela vårt projekt att bli riktigt bra är att skapa den under en kort fokuserad tidsperiod. Det effektivaste och kortaste sättet är att genomföra det i workshopform, (se avsnittet workshoparbete i kapitel 4) och att stänga in alla som bör ha en åsikt kring kraven tills produktbackloggen är klar. Det brukar gå att

Planering

115

genomföra under en till två heldagar i början av projektet och ge bäst effekt om det inte dras ut på längre tid än så. Att beställare och andra intressenter gör detta under en kort period gör dessutom att alla känner samma åtagande och har samma grundinformation om projektet. Precis som för sprintar är det bra att styra detta arbete utifrån tid snarare än resultat. Om projektet bestämmer sig för en dags workshop så skapas så mycket av produktbackloggen som man hinner - med start från det som är högst prioriterat. Det viktigaste är att den första biten är tillräckligt klar så att projektgruppen ska kunna börja arbeta så snart som möjligt. "Roll" i användarhistorieformeln kan såväl representera en fysisk person som en sak (till exempel ett it-system som kommunicerar med ett annat it-system) men försök att utgå från användare/kund/brukare så mycket som möjligt. Det gör att användarhistorien beskriver den verkliga nyttan och behovet. Användarhistorierna kan bli såväl omfattande ("mobilanvändare ska kunna koppla upp sig mot telefonnätet oavsett vilket land i världen hen befinner sig") som väldigt små och detaljerade ("summeringsfältet ska kunna visa upp summan av fält A plus fält B"). För att gruppen ska kunna arbeta med en större användarhistoria måste den brytas ned till flera små. Användarhistorier som är väldigt omfattande kallas på engelska epics (episka historier) och när de bryts ned till hanterbara användarhistorier kan man hänvisa dem till denna epic för att förstå vilka användarhistorier som hör ihop. Hur små ska de vara då? För att kunna slutföra arbete så måste de vara tillräckligt små för att kunna slutföras under en sprint, gärna lite mindre. Somliga använder tumregeln att de ska kunna slutföras på en vecka men heller inte mycket mindre än så - det blir så mycket administration om användarhistorierna blir väldigt många och små. Detta att ha tumregler för omfattningen av användarhistorier kan även vara ett bra sätt för att löpande få produktägare och intressenter att jobba med detaljering och förfining av krav. För om användarhistorien är för omfattande och stor, enligt den överenskomna tumregeln, så kan inte gruppen acceptera att börja arbeta med den - ett bra incitament för att få produktägaren att bryta ned kraven i tid. Många delar upp sin produktbacklogg baserat på hur omfattande användarhistorierna är just nu för att få en tydlighet kring vilka användarhistorier som gruppen kan påbörja. Det gör att produktbackloggen inte bara ordnas utifrån önskad prioritet utan även möjlig prioritet. Här kommer ett förtydligande exempel på hur en sådan

116

Kapitel 5

Mindre än en vecka för att färdigställa

Estimerade men för stora för att ta in i sprintens arbete

Ej estimerade ännu

Produktbackloggspyramid inspirerad av Jimmy Janlbt (2015).

produktbacklogg kan se ut illustrerat som en pyramid. Exemplet är inspirerat av Jimmy Janlens bok (se referenslistan). Prioriteringen är, precis som i en vanlig produktbacklogg, med viktigaste kravet överst. Antalet rutor på varje nivå, visar hur många användarhistorier som får finnas i varje prioritetsnivå. Det hjälper produktägaren att se när det är dags att detaljera ytterligare krav (när hål uppstår överst i pyramiden) och det visar gruppen när det är dags att estimera krav (när hål uppstår på rad fyra och fem). Samma logik beskrevs tidigare för planering enligt ramverket SAFe där varje kolumn i planeringstavlan hade en begränsning för hur många epics som fick finnas i varje kolumn. Det här var ett exempel men oavsett hur produktbackloggen ser ut så bör den vara prioriterad i "önskeordning" och samtidigt visa storlek på kraven/ användarhistorierna/epics. En överenskommen tumregel om maxstorlek för att påbörja arbetet underlättar ytterligare.

Planering

117

Sprintbacklogg Produktbackloggen är alltså en lista över krav och mål för hela eller delar av projektet, där framför allt målen specificeras först efter hand som den aktuella sprinten infinner sig. Men det behövs ett verktyg för att planera projektet på en än mer detaljerad nivå. Det kan liknas vid nyårsaftons mentala att-göra-lista inför morgondagens släktkalas - för att återknyta till exemplet i detta kapitels inledning. Det handlar om att utarbeta produktbackloggens ofta svepande krav och mål till mer specifika sådana, och det görs i en sprintbacklogg.

Rullande närzonsplanering Som jag beskrivit tidigare ska varje sprint vara en kort period (oftast mellan en och fyra veckor). Att ha korta planeringsperspektiv kallas med Torbjörn Wenells språk rullande närzonsplanering (Wenell, 2001) och är alltså inget nytt under solen. Agil projektledning innefattar ett praktiskt arbetssätt för att arbeta med närzonsplanering. Detaljplaneringen sker under den första dagen av en ny sprint. Helst ska varje sprint ha ett uttalat sprintmål för att projektgruppen enklare ska veta vad som är prioriterat. Om exempelvis sprint nummer tre har målet "färdig marknadsföring" så vet projektdeltagarna enklare hur de ska tänka kring prioriteringar för varje aktivitet och blir därför mer självgående. Beroende på sprintens längd går denna planering att genomföra på allt ifrån en timma till en heldag. Precis som för produktback-loggsframtagningen så rekommenderar jag att styra detta utifrån tid. Man bestämmer sig för en tidsperiod (till exempel en halv dag) och gör det bästa av tiden. Efter att sprinten är slut kan projektgruppen reflektera och fatta beslut kring om det var lagom lång tid eller om mötestiden ska förändras inför nästa sprintslut. Följer man SAFe görs nedbrytning till sprintplaner för tre till fyra sprintar i taget under PI-planeringsworkshopen. Ofta går man däremot inte ned i så exakt detalj att alla aktiviteter planeras, bara till krav-/användarhistorienivå för att se helheten för en PI-period och vilka beroenden som finns mellan teamen. Nedbrytning till aktiviteter sker sedan under första dagen av varje sprint.

Sprintens krav förhandlas Under första halvan av planeringen diskuterar, prioriterar och beslutar

118

Kapitel 5

beställaren vilka krav som ska ingå i sprinten. Om beställaren gjort sitt jobb och förberett produktbackloggen så är den redan skriven i prioriteringsordning och de översta kraven är det som beställaren vill ha lösta under den kommande sprinten. Det är viktigt att detta blir en diskussion där inte projektgruppen bara tar emot order från beställaren. Beställaren ska ha nytta utifrån projektets resultat i fokus men projektgruppen kan ofta visa på nyttoperspektiv utifrån genomförande av projektet. Även om beställaren vill ha krav nummer 4 under denna sprint och nummer 19 i nästa sprint så kanske projektgruppen ser fördelar med att lösa dessa krav parallellt under sprinten. Självklart ska den informationen upp på bordet för att diskuteras. Ett bra planeringsmöte är helt enkelt en bra förhandling mellan produktägare och projektgrupp.

Uppgifter och ansvar definieras De överenskomna kraven förs över till en sprintbacklogg och har nu övergått till att vara projektgruppens ansvar. När kraven för sprinten har beslutats om övergår krav till mål genom att projektgruppen definierar uppgifter som behöver utföras för att uppnå kraven. Gruppen kan även bestämma vem som ska ansvara för vilken uppgift. Vissa planerar för lite mer än en sprint utifall att gruppen arbetar snabbare än beräknat, men många tar istället ett extra "miniplaneringsmöte" med sin produktägare mitt i sprinten om det inträffar.

FÖRSTA HALVAN AV PLANERINGEN ■ Produktägare och grupp förhandlar om vilka krav/mål/användarhistorier som ska ingå i sprinten och definierar ett sprintmål. ■ Från produktbackloggen skapas en prioriterad sprintbacklogg som gruppen nu ansvarar för. ANDRA HALVAN AV PLANERINGEN ■ Gruppen åtar sig jobbet, definierar uppgifter utifrån krav/mål/användarhistorier i sprintbackloggen. ■ Gruppen definierar uppgifter utifrån krav/mål/användarhistorier i sprintbackloggen. Gruppen kan bestämma vem som gör vad, om de anser att det behövs redan nu.

Planering

119

Prioriteringen i sprintbackloggen avser i vilken ordning projektgruppen ska påbörja respektive arbete under sprinten. Det krav som står överst börjar gruppen arbeta med för att, när det kravet är uppfyllt, fortsätta med nästa krav. Projektgruppen såväl som produktägaren vet därmed arbetsordningen i sprinten. Det gör att produktägaren kan, om hen inser att krav 22 inte är särskilt viktigt inför kommande leverans, hinna dra i nödbromsen och be projektgruppen att exkludera krav 22 och istället se om projektgruppen kan inkludera krav 25 i den här sprintens leverans.

Låt stå, sprint pågår När den agila modellen Scrum lanserades (1995) tryckte man hårt på att man inte får göra på det här viset. Man menade att en beställare som mitt i sprinten förändrar kraven kan medföra kaos. En del av Scrums förespråkare håller fortfarande hårdnackat på att åtagandet absolut inte får ruckas på under en sprint (här att leverera krav 1 till och med 24). Tyvärr kan en så strikt syn på åtagande riskera att ge modellen dåligt rykte. Agil projektledning handlar trots allt om att vara förändringsbenägen. Med ständiga förändringar inne i sprinten finns visserligen risk att visst arbete läggs ner i onödan eller bara görs halvfärdigt, men förändringar i åtagande under sprintens gång bör tillåtas så länge produktägaren får klart för sig vad konsekvensen av beslutet innebär. Scrum har omarbetats flera gånger (senaste versionen hittar du på scrumguides.org) och nu uttrycker man istället att inga förändringar får göras som riskerar att sprintmålet inte går att nå, men att enskilda krav kan få förändras. Om produktägaren vill exkludera krav 22 och istället kräva att krav 39 ingår i leveransen kanske någon redan börjat titta på förutsättningarna för krav 22. Analystiden för krav 22 är därför tyvärr bortkastad tid och produktägaren måste förstå att hen måste betala för denna tid, trots att det inte bidrar till projektresultatet. Under tiden som gruppen arbetar i sprinten fortsätter produktägaren att ansvara för produktbackloggen och detaljerar, förändrar, inför, tar bort och omprioriterar krav ända fram tills nästa sprint ska planeras. Eftersom vi har en uppstartsdag vid varje ny sprint kommer därför produktbackloggen att ha förändrats vid varje sprintövergång. Det kan tyckas vara självklart men det är viktigt att poängtera att bara för att vi under första uppstartsdagen planerade in krav 1 till och med 24 i den första sprinten, så är det inte självklart att vi kommer att lösa krav 25 till 35 i nästa sprint.

120

Kapitel 5

Ofta behöver produktägaren ta hjälp av gruppen för att diskutera förändringar i produktbackloggen. Dessa möten kallas ofta förfiningsmöten (refinement meeting, storytime session eller backlog grooming) och många lägger dessa möten med kontinuitet löpande under arbetet, till exempel genom att använda två timmar varje måndag och torsdag morgon varje vecka. I beskrivningen av metoden Scrum (The Scrum Guide) lyfter grundarna fram att detta arbete är väldigt viktigt, inte minst för att nya krav inte ska komma som överraskningar vid nästa sprintplanering. De förordar att förfiningsmöten helst inte ska ta mer än 10 procent av sprintens tid i anspråk. Tyvärr är det fortfarande en del agila team som inte har förfiningsmöten över huvud taget, även om fler och fler inser fördelarna med det.

Ny sprint, ny sprintbacklogg Vid varje ny uppstartsdag skapas en ny sprintbacklogg utifrån eventuellt arbete som inte slutförts under sprinten och alla prioriterade krav i den uppdaterade produktbackloggen. Ett nytt planeringsmöte med samma förhandlingssituation sker vid varje ny sprint. Det är här styrkan i agila metoder ligger. Vi räknar med att prioriteringar, krav och mål förändras under hela vårt projekt och vi har ingenting emot att produktbackloggen har förändrats vid varje ny sprintstart. Produktbackloggen ska inte vara huggen i sten. Det här är några rubriker som kan behövas i en sprintbacklogg: ■ Kravnummer/användarhistorienummer (AN#) för att se en tydlig koppling mellan vilket krav i produktbackloggen som aktiviteten behövs för. Ibland måste vi utföra uppgifter som inte är direkt kopplade till ett krav (alternativt till flera krav) och då lämnar vi rutan tom. ■ Uppgiftsnummer/aktivitetsnummer- en numrering av varje uppgift (aktivitet) är bra för att enkelt kunna identifiera uppgiften. Ibland har olika uppgifter likartade namn och ett nummer förenklar det hela.

■ Namn - ett kort, enkelt namn som gör att vi kan identifiera uppgiften. ■ Ansvarig - namn på den projektdeltagare som ska ansvara för att uppgiften blir utförd.

■ Kommentar - eventuella påpekanden. ■ Tidsuppskattning - uppskattad tid i arbetstimmar för att slutföra uppgiften.

Planering

121

AH

Uppgift

Namn

Festivalbesökare AH1

ska kunna se liveband spela på scenen

Kommentar

Ansv Tidsuppskattn

överblivna

5 dagar

plankorna från

Ul

Spika ihop scenen

AH1

U2

Förbättringsmåla

Bortskavd färg

Personal ska kunna

Behöver enkla

se besökares biljetter

träbodar att

för att släppa in till

sitta i: köpa och

festivalen

inreda

M

AA

16 timmar

C

BB

16 timmar

2 dagar

AH2

U3

Flytta fram alla bodar

6 st, 2 per ingång

M

DD

8 timmar

AH2

U4

Inreda, koppla in el

Alla 6 bodarna

S

CC

4 timmar

Förutom de föreslagna kolumnerna i sprintbackloggen lägger många även till en kolumn som beskriver acceptanskriterier för varje mål. Acceptanskriterier är de kriterier som ett krav eller mål minst måste uppnå för att vara godkänd. Genom att definiera acceptanskriterier vet både produktägare och projektdeltagare vad som ska fungera efter att målet är nått. Kriterierna ska helst uttryckas i bara ett par meningar. Exempelvis skulle AH1 ovan (Festivalbesökare ska kunna se liveband spela på scenen) ha följande kriterier: 1) Scenen ska rymma fem musiker och deras instrument. 2) Scengolvet måste vara minst två meter över marknivå. Måste man ha en såhär tydlig lista för varje sprint? Det beror helt på typen av projekt. Vissa nöjer sig med att bara skriva själva uppgifterna på post-it-lappar medan andra behöver ha allt väldigt tydligt dokumenterat. Se detta som ett exempel.

Kapitel 5

Sven

förra året

Exempel på sprintbacklogg. Här utarbetas produktbackloggens krav till mål och uppgifter för projektgruppen.

122

Källa

Bygg av de

AH1

AH2

Prio

Inga

Prioritera krav Hur ska man prioritera krav i projektet för att få största möjliga effektivitet? Den agila principen lyder ju: "Börja med det nyttigaste först!"

Med nytta menas den funktionalitet och de krav som slutanvändaren av projektresultatet väntar mest på, det vill säga: har störst nytta av. Ett första steg är att göra en grov indelning, till exempel utifrån modellen i den agila metoden DSDM (Dynamic Systems Development Model) som har fått namnet MoSCoW. De versala bokstäverna i ordet står för: ■ Must have (Måste ha) ■ Should have (Ska ha) ■ Could have (Kan ha) ■ Won't have this time (Vill inte ha den här sprinten)

De två o:na har lagts till för att det ska bli ett ord som är enkelt att komma ihåg. Den här tekniken kan användas för att inte behöva höra "allt är viktigt" av sin produktägare. Bäst blir resultatet om gruppen beslutar att produktägaren som mest får tilldela M (Must have) till 50 procent av kraven, 25 procent S (Should have) och 25 procent C (Could have). Om projektgruppen mitt i sprinten diskuterar ett krav med produktägaren som hen inser inte längre är relevant eller inte behövs just nu kan produktägaren ändra prioriteringen till W (Won't have this time) för att markera att uppgiften inte ska utföras. Som jag påpekade tidigare, detta är ett bra första steg för att i nästa steg skapa en lista från högst prioriterad till lägst prioriterad. En annan fördel med prioritering är att vi även kan ange relationer, eller beroenden, mellan krav. Exempelvis kan vi markera att krav 1, 14 och 21 samtliga är "Must have"-krav och att leveransen inte är särskilt mycket värd om ett av dessa krav inte ingår i leveransen. Med en sådan tydlighet i prioriteringen vet vi inför slutet av sprinten vad vi måste prioritera om vi blir tveksamma. Även om krav 20 står för dörren enligt vår lista så vet vi att krav 21 hänger ihop med 1 och 14 och måste bli färdig för att det ska vara nytta med sprintens resultat.

Planering

123

Tidsuppskattning Ordet tidsuppskattning betyder olika saker i olika organisationer. I många organisationskulturer är frågan helt odramatisk där projektmedlemmar förutsätts tidsuppskatta vad de ska göra innan de påbörjar arbetet med sina aktiviteter men i andra organisationer finns inte vanan att tidsuppskatta över huvud taget. Oavsett vilken kultur som råder är det fruktbart att börja tidsuppskatta det arbete man sysslar med. Att tidsuppskatta är att lära sig av sina misstag, att få större insikt i såväl detaljer som helheten och ger ett naturligt tillfälle för reflektion.

Uppskatta återstående tid Ett agilt angreppssätt för tidsuppskattning är att varje dag stanna upp och fundera över hur många timmars arbete som återstår för att bli färdig med den uppgift man håller på med. Den siffra du kommer fram till ska sedan meddelas i det dagliga möte ni har i projektgruppen. Helst ska uppgiften dessutom vara nedbruten i så exakt detalj att tidsuppskattningen inte överstiger 16 timmar, alltså som mest två hela arbetsdagar. För somliga låter detta som en omöjlighet. "Den här rapporten kommer ju att ta minst en vecka att skriva så jag kan ju omöjligtvis uppskatta mindre än 16 timmar för det arbetet!" Men det är inte tidsåtgången som ska pressas utan istället aktiviteterna som ska brytas ned till mindre enheter, inte större än att de kan utföras på två arbetsdagar. Uppgiften att skriva en rapport, som i exemplet ovan, kan brytas ner i: ■ Skriva inledning - 4 timmar ■ Strukturera huvuddelen av rapporten - 12 timmar ■ Skriva huvuddelen av rapporten - 12 timmar ■ Granska och revidera huvuddelen - 12 timmar ■ Skriva avslutningen av rapporten - 8 timmar

Fördelen med att bryta ner aktiviteter är enkelheten i att följa upp hur mycket som är genomfört. Med längre perioder, exempelvis två veckor, som tidsuppskattning för en aktivitet kommer uppföljningen den största delen av tiden lyda: "jo, jag följer planen" tills 80 procent av projektets planerade tid har gått. Först då brukar många upptäcka att arbetet är försenat. Vissa elaka röster brukar säga att de sista 20 procenten av arbetet ofta tar ytterligare

124

Kapitel 5

80 procent av tiden. Det kanske är att överdriva men faktum är att med indelning i korta intervall blir aktiviteten enkelt greppbar och överskådlig. Att ha en överenskommen siffra för största tillåtna uppskattade tid för en aktivitet har också den goda bieffekten att en del diskussioner kan undvikas. Uppskattar man att aktiviteten kommer att ta mer än 16 timmar måste den brytas ned ytterligare, punkt slut. Självklart kan aktiviteter vara uppskattade till 4, 7, 14 eller vilket antal timmar som helst men den övre gränsen är bra att besluta kring. Se bara till att utvärdera siffran 16 i varje sprintövergång. Att arbeta agilt är att hela tiden försöka förbättra processen. Om projektgruppen anser att tiden är för lång eller kort byter man till en annan siffra att prova för nästa sprint.

Sashimi - god japansk mat Vad i all sin dar har japansk mat med agil projektledning att göra? Sushi, vet de flesta, är en bit rå fisk på en rulle av ris. Sashimi däremot är bara en bit rå fisk. Liknelsen med sashimi görs för att påtala ett vanligt misstag när det gäller tidsuppskattning nämligen att man ofta tidsuppskattar för mindre än hela den enhet som efterfrågas. Projektgrupper tenderar alltså ofta att fokusera på hur lång tid det tar att göra sashimi, när det i själva verket var sushi som efterfrågades. Beställaren kanske frågar efter en uppskattad tidsåtgång för att ta fram utbildningsmaterial med det outtalade antagandet att aktiviteten

MAGURO TUNA SASHIMI

Planering

125

även innebär utskrift av 15 exemplar, insatta i pärmar och färdiga att dela ut. När den utbildningsansvarige sedan talar om att utbildningsmaterialet är klart och beställaren undrar var pärmarna är blir svaret: "Men, det tog jag ju inte med i tidsuppskattningen! Jag menade bara tiden för att ta fram själva materialet elektroniskt, inte att skriva ut det och sätta in det i pärmar också!" Detta är ytterligare ett skäl för projektgrupper att bryta ned projektets aktiviteter så att det framstår tydligt vad aktiviteten innebär och så att gruppen får en bättre uppfattning om tidsåtgången för hela aktiviteten. För att vara tydlig med vad "utbildningsmaterialet är klart" innebär lägger många agila projektgrupper även tid på att beskriva en så kallad klardefinition (Definition of Done eller DoD på engelska). I det här fallet behövde man beskriva specifikt om aktiviteten "att skriva ut och sätta in materialet i pärmar" var en del av jobbet, men ofta har teamet nytta av en generell klardefinition, exempelvis att varje jobb ska vara testat, felrättat och dokumenterat för att kallas klar.

Fyra regler för tidsuppskattning Men hur gör man då för att tidsuppskatta saker på ett vettigt sätt? Hur ska man kunna veta hur lång tid det tar att göra en ritning av en ny soffmodell till exempel? Till att börja med kan man konstatera att det är svårt att göra korrekta tidsuppskattningar. Ibland ser man uttalanden som: "We want estimates instead of guesstimates". Det är en chimär att tro att man

EXEMPEL - SVÅRT ATT TIDSUPPSKATTA

'1.11.111"111911011

Under ett konsultuppdrag satte it-chefen tillsammans med andra itanställda samman en kravspecifikation för ett it-system. De ansåg att de gjorde ett gott och detaljerat jobb och skickade ut denna specifikation till olika it-leverantörer som gjorde uppskattningar på hur dyrt systemet skulle bli att bygga. Gruppen förväntade sig marginella skillnader i kostnadsuppskattningarna med tanke på den detaljerade kravspecifikationen. Den lägsta kostnadsuppskattningen var 2 miljoner kronor och den högsta 14,5 miljoner kronor. Förfrågan skickades till kompetenta och erfarna leverantörer, ändå hade de så olika syn på tid och komplexitet för att utföra uppgiften.

126

Kapitel 5

alltid kan gissa mer exakt genom att bara anstränga sig lite mer, men det finns tekniker som faktiskt gör att gissningar kan förvandlas till mer underbyggda uppskattningar. Trots svårigheten i att tidsuppskatta finns det några bra regler att ta till: ■ Tidsuppskatta i team När någon tidsuppskattar på egen hand finns det alltid en risk att personen inte tänker på hela problematiken. Genom att i ord formulera hur man tänker för någon annan och få återkoppling på sina tankar gör att man får större förståelse för uppgiften. ■ Mer information Genom att fråga efter mer information och jämföra med liknande uppgifter får vi en mer korrekt bild av det som ska göras. Projektgruppen måste då gräva efter uppgifter om liknande projekt där tidsuppskattningar gjorts. Det gör att tidsuppskattningen blir bättre. ■ Gaffling Gaffling är ett gammalt ord från artilleriet som innebär att man först skjuter ett provskott för att se hur långt ifrån målet man träffade. Om pjäsen slog ned 200 meter bortanför målet så måste vii nästa skott försöka skjuta kortare och på det viset så "gafflar" vi oss rätt till målet. I tidsuppskattning för projektaktiviteter går gaffling till på följande vis: Eva: 'Jag har ingen aning om hur lång tid det tar att spika upp ett staket!" Scrum master: "Tror du att du klarar av att genomföra det på en timme?" Eva: "Nej, det är alldeles för kort tid!" Scrum master: "OK, klarar du av det på två arbetsdagar, alltså 16 timmar?" Eva: "Oj, så mycket tid behöver jag inte!" Scrum master: "OK, vad sägs om fem timmar då?" fem timmar låter faktiskt rimligt." Eva: ■ Ansvarig får sista ordet Det är lätt att titta på en uppgift som någon annan ska utföra och säga: "Det där borde väl Kalle klara av på två timmar". Om det däremot är man själv som, med handen på hjärtat ska åta sig att göra ett jobb på ett visst antal timmar, blir det oftast en helt annan siffra.

Planering

127

Många ryggar tillbaka när de hör dessa råd av fruktan för att tidsuppskattning i sig tar mycket tid. Men faktum är att det här är en process som går lätt att få hög hastighet i så fort gruppen har kommit in i sättet att tänka. Som scrum master ska man undanröja hinder. Hindret att undanröja i detta steg är att inte lägga allt för lång tid på aktiviteten utan att driva gruppen till att hålla ett högt tempo. En utarbetad teknik för detta ändamål har på engelska fått namnet planning poker.

Planning poker Att tidsuppskatta med tekniken planning poker innebär att alla deltagare i projektgruppen får varsin kortlek med en lite annorlunda serie kort. Helst deltar även produktägaren vid denna tidsuppskattning för att kunna reda ut frågetecken.

0 1/2 1 2 3 5 8 13

20 40 100 ?

Hela serien av planning poker-kort.

Siffrorna representerar det antal timmar som deltagaren uppskattar att en aktivitet kommer att ta för att slutföra. En person ska vara utsedd till moderator, exempelvis scrum master. Processen går till såhär: 1.Den person som vet mest om aktiviteten berättar om den. Berättelsen ska fokusera på de detaljer som är viktiga för att kunna tidsuppskatta, såsom gränsdragningar kring vad som ingår och inte (exempelvis om utbildningsmaterialet från det tidigare nämnda exemplet ska skrivas ut och sättas i pärmar eller bara skapas elektroniskt). Det ska helst inte ta mer än ett par minuter. 2. Projektdeltagarna väljer ut ett kort från sin kortlek och visar baksidan av kortet för att signalera att de har bestämt sig. När alla bestämt sig uppmanar moderatorn alla att vända korten.

128

Kapitel 5

3. Alla vänder samtidigt sina kort och visar vilken siffra de valt för sin tidsuppskattning. Anledningen till att vänta in alla är för att inte den som bestämt sig först ska påverka de andra projektdeltagarnas gissningar. 4. Den person som valt lägst siffra berättar hur hen tänkt eller beskriver vilka moment hen antar ska ingår i arbetet. Därefter går ordet till personen som valt den högsta siffran så att även den personen får berätta hur hen har tänkt. I detta moment upptäcker projektgruppen ofta felaktiga antaganden och om produktägaren är med kan felaktiga uppfattningar redas ut direkt. 5. Nu gör alla en ny tidsuppskattning, alltså väljer varsitt kort och visar dem för varandra på en given signal. 6. Om värdet på siffrorna är ganska nära varandra kan nu moderatorn föreslå en siffa. Om exempelvis två personer i gruppen valt 8 och två har valt 13 kan moderatorn säga: "Kan vi enas om 10 timmar?". Om aktiviteten redan har en uttalad eller självskriven ansvarig så kan hen bestämma den slutliga siffran. 7. Om siffrorna är väldigt långt ifrån varandra, exempelvis då halva gruppen röstat 40 timmar och hälften 100 timmar, är det ett tecken på att aktiviteten bör brytas ned i mindre delar där varje del tidsuppskattas var för sig.

Varför den konstiga nummerserien? Den matematiskt intresserade läsaren ser kanske likheten med det som kallas Fibonacci-serien som innebär att varje siffra är summan av de två föregående sifforna (3 + 5 = 8, exempelvis). Anledningen till att den används är för att det är så långa hopp mellan varje steg vilket innebär att projektdeltagaren måste bestämma sig för antingen det ena eller andra värdet. Det gör att gruppen slipper långa diskussioner kring om 20 eller 22 är rätt värde eftersom den exakta siffran ändå inte går att

förutsäga. Det handlar trots allt om uppskattningar.

Planering

129

Det finns färdiga kortlekar som går att beställa på internet men gruppen kan lika väl använda papper att skriva på eller någon lämplig smartphoneapp. Sök bland appar efter "planning poker" så kommer du att hitta många varianter. Planning poker är ett snabbt och enkelt sätt för att tidsuppskatta där alla får komma till tals och hela projektgruppen får en ökad insikt i arbetet. Kortet med ett frågetecken kan användas för att signalera att man inte har en aning om tiden för en aktivitet. Om kortet används för flitigt är det bättre att ta bort det - tekniken är till för att lära sig mer om alla aktiviteter och alla ska uppmuntras till att försöka tidsuppskatta.

Räkna bananer Det är, som redan påpekats, svårt att göra bra tidsuppskattningar. Vi riskerar att fastna i resonemang kring "ja, det där kravet borde vi lösa på två dagar om allt löper på bra men om vi stöter på problem kan det lika väl ta oss fem dagar". För att hantera det här problemet utgår många istället ifrån poäng (User Story Points). Poäng kan bytas ut till punkter eller bananer eller vad man vill, bara det inte är en tidsenhet. Istället för att fundera över tid funderar man över kravens komplexitet. Frågan är då: Hur svårt är det här kravet att lösa jämfört med andra krav vi ska lösa? För att ha något neutralt ord att utgå ifrån bestämmer man sig för att komplexitet mäts i bananer, på en skala som börjar på ett. För att ha något att utgå ifrån kan det vara bra att titta på ett tidigare litet krav och bestämma, som grupp, att det kravet motsvarar två bananer och att ett krav som behöver dubbelt så mycket arbete för att lösa följaktligen är fyra bananer. Genom att enas om ett krav som motsvarar två bananer så har vi utrymme för krav som vi identifierar som ännu mindre komplexa (som vi kan ge en etta, helt enkelt). Gruppen enas om en gemensam siffra för varje krav med hjälp av exempelvis planning poker. Låt oss säga att de kommer fram till följande lista: Krav 1: Sex bananer Krav 2: Tre bananer Krav 3: Fyra bananer etc.

130

Kapitel 5

Inför den första sprinten uppskattar man hur många bananer man tror sig klara av på en sprint. Det här är väldigt svårt att uppskatta inför den första sprinten men någon gissning måste man göra. Till exempel "Vi uppskattar att vi klarar av ett antal krav av sammanlagt 40 bananers komplexitet". Det innebär att man åtar sig krav 1 till och med krav 9 om summan av dessa krav uppgår till 39 bananer. Om vi efter sprinten inser att vi endast klarade av de första sju kraven och att antalet bananer för dem uppgick till 32 bananer så kan vi inför nästa sprint veta att vi inte bör åta oss fler krav än att de sammanlagt uppgår till 32 bananer. Logiskt, inte sant? Att räkna bananer (eller poäng) är alltså ett sätt att lära sig hur mycket gruppen klarar av att prestera totalt per sprint, oavsett vem som gör vad eller vilka svårigheter som försvårar enskilda aktiviteter. Och det är ju

Planering

131

det som är poängen med det agila arbetssättet, att se och utveckla hela gruppens produktivitet. Om man är flera team som jobbar tillsammans kan det här bli en utmaning om man antingen behöver byta teammedlemmar mellan team eller om flera team planerar tillsammans. I ramverket SAFe, som är till för flera samarbetande team, lyfter man fram att dessa poäng behöver normaliseras för att alla team ska tänka på samma sätt. Normaliseringen går då till så här: teamet tittar på sina aktiviteter och enas om en aktivitet som de anser tar en arbetsdag att slutföra (såväl skapa som testa och dokumentera, alltså bli helt klar). När man sedan räknar ut hur många poäng teamet har tillgängligt för en sprint räknar man med fyra poäng per vecka per person. Är någon ledig en dag drar man av en poäng.

EXEMPEL PÅ BERÄKNING MED NORMALISERADE POÄNG

Projektgruppen som består av fyra personer har bestämt sig för att arbeta i två-veckors-sprintar. Den kommande sprinten behöver Anna vara ledig den första fredagen, i övrigt jobbar alla heltid. Med fyra poäng per person innebär det 16 poäng per vecka (4 personer * 4

poäng), alltså 32

poäng för hela sprinten (16 poäng * 2 veckor). Men

eftersom Anna ska vara ledig en dag dras en poäng bort (32 poäng poäng för ledig dag). Återstår att planera för är 31 poäng för nästa sprint.

Sammanfattning Vid agil projektledning är det viktigt att planera på rätt nivå. En bra utgångspunkt är att arbeta med fem nivåer av planering: 7. Vision 2. Färdplan 3. Leveransplan 4. Sprintplan 5. Daglig plan

132

Kapitel

5

Visionen tas fram under förstudien. Färdplan och leveransplan tas ofta fram under uppstartssprinten (som ofta kallas sprint noll). Leveransplan och sprintplan görs även löpande under projektets gång, liksom den dagliga planen. Genom att föra en produktbacklogg, som beställaren ansvarar för, finns en tydlig dokumentation över vilka krav som ska tillgodoses. Dessa definieras ofta som användarhistorier för att vara tydliga men ändå inte för detaljerade från start. För varje sprint utarbetas en sprintbacklogg baserad på produktbackloggen. Tidsuppskattningar är viktiga för att få en bättre uppfattning av projektets helhet och insikt i detaljerna. Ett sätt för att få allas röster hörda utan inbördes påverkan är att använda planning poker.

Övningar 1— Sprintens längd Tid för övning: 5 + 15 minuter Varje projektdeltagare beväpnar sig med en papperslapp. På denna papperslapp anger projektdeltagaren vad hen anser vore den optimala längden för varje sprint i projektet utan att motivera varför. Ge varje deltagare ett par minuters betänketid så att de kan motivera sina svar men utan att de skriver ned sin motivering på lappen. (fem minuter) Projektledaren skriver upp samtliga tider på ett blädderblock eller tavla och därefter är ordet fritt för att motivera längden på sprinten. Det är lätt att projektdeltagare som "dominerar" grupper sätter normen för hur projekt ska se ut. Genom att börja med enskilda lappar kan vi här ha en helhetssyn på individuella synpunkter innan argumentationen kring lämplig längd påbörjas. Den här övningen kan göras flera gånger under projektet. Kom ihåg att sprintens längd inte är något som ska vara skrivet i sten. Precis som allt annat agilt är det viktigt att prova, utvärdera och förändra löpande.

Planering

133

2—

Sprint noll

Tid för övning: 30 + 10 minuter

Planeringsfasen kallas ofta sprint noll eftersom det är steget innan genomförandefasen påbörjas. Ett av de viktigaste syftena med planeringsfasen är att få en effektiv start på genomförandefasen. Det åstadkommer gruppen bara om allt finns på plats som gruppen behöver för att kunna arbeta. Sätt er ned och diskutera vad gruppen behöver ha klart för att få en så effektiv start på projektet som möjligt. Använd gärna såväl förstudie- som planeringskapitlet i den här boken för att få inspiration. Låt gruppen tala fritt i 30 minuter och låt moderatorn föra anteckningar på whiteboard eller blädderblock. Använd sedan tio minuter till att prioritera till en lista i nyttighetsordning. Använd listan som underlag för diskussioner med produktägaren kring hur ni ser på behovet för sprint noll.

Övningsboken: I kapitel 3 finns flera övningar för att träna sig

Agil pojaktled.L. ÖVNINGSBOK

i att planera agila projekt. Där finns även scenarioövningar som visar kniviga situationer där du, eller hela din grupp, kan diskutera möjliga lösningsalternativ.

Tomas Guatarron

Genomförande

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 sprint 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.

136

Kapitel 6

Projekttavla 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 Alltför mycket stabilitet frågor för effektivare projektarbete, här benämnda praktikaliteter, som berörs i förhindrar framsteg. kapitlets 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 projektgruppens status under sprinten och den brukar innehålla följande tre

pp

kolumner: ■ Ej påbörjat ■ Påbörjat ■ Klart

Dagligt stå-upp-möte

Produktbacklogg

Sprint-

Erfarenhetsmöte

backlogg

och demonstration av sprintresultat

Genomförandeprocessen i agila projekt.

Genomförande

137

De detaljerade krav och aktiviteter, samt tidsuppskattningen i timmar eller heldagar, som skrivits ned i sprintbackloggen överförs till kort, notisar eller postitlappar och sätts upp i den första kolumnen, med titeln ej påbörjat. Lapparna tejpas upp enligt samma principer som i sprintbackloggen, 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 entren till scenområdet

Markera sträckan för gångbro

8 Ta emot och instruera leverantörer av gångbro 16 • Besökarna ska passera en och en vid biljettkontrollen

Fixa fållor utanför biljettstånd 12

Hyra spärrar 16

138

Kapitel 6

Klart

När sprinten börjar finns alla krav och aktiviteter i ej påbörjat-kolumnen för att visa att ingenting är genomfört i sprinten ännu. Projektdeltagare tar därefter en lapp från ej påbörjat-kolumnen, flyttar lappen till påbörjatkolumnen, och börjar sitt arbete. Om projektgruppen bestämde vem som skulle göra vad under sprintplaneringsmötet 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 "LI" 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.

Kör gruslasset till byggarbetsplatsen

XEE

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.

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

Genomförande

139

som jobbar på transportavdelningen för att få låna en lastbil och fått det burdusa svaret: "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.

Flytta den mobila

2020-09-0110.35-1Y Enligt Anders finns det inga lediga lastbilar förrän på fredag

På det här viset blir det tydligt för projektdeltagare, projektledare, produktägare, beställare och 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 inte Anders hunnit tala med chefen för transportavdelningen som istället 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 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.

140

Kapitel 6

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 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 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.

Genomförande

141

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 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. Men det finns fler skillnader mellan Kanban och de andra agila metoderna som jag ska återkomma till senare i det här kapitlet.

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. I ramverket 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å-uppmö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: i. 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, scrum mastern 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 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å sprintens mål? 5. Har ni lärt er eller beslutat något som gruppen har nytta av att få veta?

142

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 scrum mastern 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 behöver man beskriva hur det agila sättet att följa upp och stämma av görs inom agil projektledning. I kapitlet om roller beskrevs scrum masterns 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. Grundiden ä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 hen 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 aktiviteten

Genomförande

143

redan är klar för att visa att det var en korrekt tidsuppskattning. När detta spel väl påbörjats är det svårt att ta sig ur det. Om spelet sprider sig till andra i verksamheten innebär det att många aktiviteter i projektplanen innehåller luft och det blir väldigt svårt att göra effektiva uppföljningar och för människor att lära sig något av planerad tid kontra verklig tid.

Ny tidsuppskattning varje dag Det agila arbetssättet är att varje projektdeltagare, på det dagliga ståuppmötet, får frågan: "Hur mycket mer tid tror du behövs för att färdigställa uppgiften som du håller på med?" utan att ställa detta mot den initiala tidsuppskattningen. Man frågar alltså inte hur mycket planerad tid som återstår av den första tidsuppskattningen utan efterfrågar en ärlig uppskattning om mängden återstående arbete. Den nya tiden skrivs på projekttavlans aktivitetslapp. En uppgift, som initialt uppskattades till tio timmar, kanske plötsligt visar sig behöva ytterligare tjugo timmar för att färdigställas eftersom ökad insikt i uppgiftens natur visar att verkligheten var mer komplicerad än vad som antogs från början. Det är först när sprinten är avklarad som projektet kan sätta sig ned med de initiala uppskattningarna och jämföra med hur de verkligen föll ut i syfte att lära sig inför nästa sprints tidsuppskattning. Agil projektledning handlar om att lära sig och att anpassa sig, inte bestraffa.

144

Kapitel 6

En kort stund på stående fot Varför ska det dagliga stå-upp-mötet bedrivas stående? Jo, för att möten där alla sitter ned, tar en kopp kaffe med sig och börjar med att fråga laget runt om familjeförhållanden har en tendens att ta lång tid i anspråk. Plötsligt ifrågasätts det från ledningshåll varför det går åt så mycket tid till möten. Man beslutar då kanske att skära ned på antalet möten och är snart tillbaka i gamla kommunikationsproblem. Ett stå-upp-möte ska ha en i förväg bestämd tid. En beprövad och vanlig möteslängd i agila projekt har blivit femton minuter för hela gruppen. Somliga lägger något längre tid i början av ett projekt för att gradvis minska den. Andra gör uppdelningen per person, exempelvis två minuter per person som deltar. Med så korta möten gör det inte något att de genomförs varje dag. Stressade projektmedlemmar behöver inte tänka "Åh, nej, ett möte igen. Jag som har så mycket att göra!" utan får istället en kvarts avbrott i sitt arbete som dessutom främjar hela gruppens arbete. För att kunna hålla dessa möten korta är det viktigt att varje projektdeltagare inför mötet tänker igenom: "Vad är relevant att berätta för

UNDVIKA TIDSSPILL

minuter i början av mötet är att införa

Det är viktigt att alla som är på mötet

förseningsböter. Den som inte dyker

har en anledning att närvara och att

upp klockan 9.00 kan exempelvis

mötet innebär så lite onödig tidsspill

få lägga en guldpeng i den gemen-

som möjligt för varje projektdeltagare.

samma förseningsburken. Att använda

En viktig uppgift för projektledaren

den här sortens bötessystem är i hög

för att hålla sitt möte inom 15 minuter

grad en kulturfråga. Agil projektled-

är att behålla mötets fokus så att alla,

ning handlar inte om att bestraffa utan

eller så många som möjligt, är invol-

om att stötta och hjälpa. Det kan vara

verade i det som diskuteras. Projekt-

bra att diskutera och besluta inom

ledaren ska se det som sin uppgift att

gruppen om den här sortens system

avbryta eventuella diskussioner mellan

ska införas.

två personer i gruppen genom att till exempel säga: "OK, ni två diskuterar

Ett sätt att göra systemet mindre kontroversiellt är att bestämma ett

vidare efter att mötet avslutats. Nu tar

gott syfte för användningen av peng-

vi nästa punkt."

arna. Varför inte skänka dessa förse-

Ett sätt att inte tappa viktiga

ningsböter till en hjälporganisation?

Genomförande

145

hela gruppen av det jag har gjort, ska göra och de problem jag upplever?". Man utgår alltså ifrån gruppens behov. Tar alla denna fråga på allvar behöver inte mötet bli en tråkig dragning laget runt som känns irrelevant utan ett tillfälle för att diskutera och fatta beslut.

Anpassad mötesplanering För somliga kan stå-upp-möte låta som en utopi. Med oregelbundna arbetstider eller projektmedlemmar som jobbar 80 procent av sin tid i projektet kan det rent praktiskt vara väldigt svårt att åstadkomma ett möte varje dag. Är det omöjligt att jobba agilt då? Nej, självklart inte. Verkligheten sätter ofta den här typen av gränser och det viktiga är inte att projektgruppen ses varje dag men att man har en så god kontinuitet som möjligt. Ickn om varje-dag-kontinuitet utgick från projektgrupper där alla jobbar 100 procent av sin tid i en och samma projektgrupp. Om det rent praktiskt är svårt att åstadkomma dagliga stå-upp-möten kan gruppen prova att minska antalet möten till tre eller två per vecka. Genom att exempelvis bestämma tisdagar och torsdagar som stå-upp-mötesdagar bibehålls ändå kontinuiteten. Det viktiga är att uppmärksamma om det påverkar projektet negativt och i så fall hur mycket. Att hela tiden undersöka, utvärdera och förändra - det är de agila projektens melodi. En praktisk detalj i organisationer med flera samtidiga agila projekt är att schemalägga mötena så att projektledare och produktägare kan delta i flera möten. Man vill ha stort engagemang för att lyckas driva projekt effektivt och genom denna medvetna mötesplanering skapar vi förutsättningar för det. Exempel: Projekt A: Stå-upp-möte mellan kl. 9.00 och 9.75 Projekt B: Stå-upp-möte mellan kl. 9.75 och 9.30

Detta ökar naturligtvis även behovet av att hålla mötet inom de avsedda 15 minuterna.

146

Kapitel 6

Progressdiagram Förutom att stämma av de tre SIP-frågorna vid varje dags stå-upp-möte ska varje projektdeltagare alltså uppdatera återstående tid för sina aktiviteter i sprinten. Den summerade kvarvarande tiden visar hur mycket jobb gruppen har kvar att utföra för att sprintens alla åtagna aktiviteter ska vara färdiga. För att få en visuell bild av projektets framsteg kan detta ritas in i ett diagram. Varje dag under sprintens gång ritas den totala återstående tiden in som en punkt i diagrammet.

Timmar kvar 350 300 250 200 150 100 50

Dag

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Progressdiagram. Varje dag ritas en punkt in som anger hur mycket tid deltagarna uppskattar att de sammanlagt behöver för att fullfölja sprintens aktiviteter.

Det raka strecket visar återstående arbetstid i gruppen och det dras mellan två punkter. Utgångsvärdet (punkten på y-axeln) är summan av deltagarnas totala inplanerade arbetstid, alltså det antal timmar som finns tillgängligt när sprinten börjar. Linjens slutpunkt (på x-axeln) markerar det antal timmar som finns tillgängligt när sprinten är slut, nämligen noll. Detta är den enda siffran man kan vara hundraprocentigt säker på! Vid varje stå-upp-möte summeras den totala tid gruppen uppskattar att de behöver för att avsluta aktiviteterna i sprinten. Det är alltså summan av alla timmar som angetts på aktivitetslapparna i ej påbörjat- plus påbörjat-kolumnen. Denna tidsmängd ritas in i diagrammet på aktuell dag och man kan på så

Genomförande

147

sätt jämföra hur projektet förhåller sig till förväntad progress. I idealfallet hamnar den rakt på linjen. I sämre fall hamnar punkten över den raka linjen. Det är när medarbetarna inser att det behövs mer tid för att slutföra alla uppgifter i sprinten än vad som finns kvar. Hamnar punkten under den raka linjen betyder det att arbetet går bättre än väntat. Diagrammet ger hela tiden en indikation på hur gruppen ligger till i sprinten. På engelska brukar detta diagram benämnas burn down chart (för att beskriva hur man "bränner tid" allt eftersom aktiviteterna utförs i sprinten). På svenska kallas diagrammet progressdiagram men ibland också sprintgraf eller statusdiagram.

Nedlagd arbetstid

Ett skäl till att punkten hamnar över linjen, alltså att inte jobb hunnits med i den utsträckning gruppen uppskattat, kan ju vara att arbetstid stulits till något annat än projektet. I ett konsultföretag har projektledaren kanske fått veta att Anna ska jobba heltid i projektet och planerar därför in 40 timmar för den kommande veckan men inser när veckan är slut att Anna har lånats till ett annat projekt och varit på säljmöte under totalt fem timmar.

Timmar kvar 350 300 250 200 150 100 50 Dag

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

• Verklig nedlagd arbetstid för gruppen

Samma progressdiagram med även totalt nedlagd arbetstid inritad varje dag.

148

Kapitel 6

Förutom att det är frustrerande så ger det en felaktig bild av projektet om det i progressdiagrammet ser ut som om projektet inte hunnit så mycket som projektet hade planerat. Det är ju inte tidsuppskattningen det är fel på utan tillgången på arbetstid för Anna som har minskat. Det agila synsättet handlar om tydlighet och transparens. Ett bra sätt att visa upp den skevhet som uppstår av att arbetstid försvinner, är att lägga in ytterligare en kurva i progressdiagrammet som visar totalt, ackumulerat, utfört arbete i projektet. Genom att vid stå-upp-mötet varje dag lägga till frågan: "Hur många timmar arbetade du i projektet igår?" kan projektgruppen enkelt summera ihop antal timmar och sätta in en punkt i progressdiagrammet som visar totalt nedlagd projekttid. Frågan gäller alltså bara hur mycket tid som lagts i projektet, inte hur många timmar personen jobbade. Denna siffra ackumuleras dag för dag i projektet och visar alltså för varje dag hur mycket som gruppen arbetat totalt i sprinten fram till dags dato. Siffran kan gruppen sedan ha till åtminstone två saker: SYFTEN MED ATT MÄTA NEDLAGD ARBETSTID 1.Som underlag i erfarenhetsmötet för att diskutera hur felaktig tidsuppskattningen egentligen var. 2. Som underlag för att förhandla med närmsta chef kring varför gruppen inte får den tid som de lovats och vilka konsekvenser det får för projektet.

Presentation vid sprintslut Varje sprint ska avslutas med en presentation, eller demonstration om man så vill, för projektets intressenter. Gruppen visar där upp projektets delresultat för granskning från den avslutade sprinten. Eftersom detta görs vid varje sprintslut är det viktigt att det görs kort och effektivt för att inte ta för mycket av de inblandades tid i anspråk. En halv till en timmes presentation med maximalt två timmars förberedelse är en rimlig målsättning för detta möte.

Delresultat visas Presentationen ska, i största möjliga mån, visa upp det verkliga resultatet. Fokus ska inte vara på att ha ett vackert presentationsmaterial. Om sprintens

Genomförande

149

resultat är abstrakt och svårt att visa, exempelvis om gruppen utfört 400 marknadsintervjuer, berättar gruppen om det genomförda arbetet istället. Genomför gruppen ett byggprojekt hålls mötet på byggplatsen. Genomför de en omorganisation visas dokument och planer upp och gruppen berättar om delresultatet. Det viktiga är att visa upp resultatet på ett sådant sätt att projektgruppen kan få vettig återkoppling som hjälper dem att fortsätta producera nytta åt organisationen. SYFTEN MED TÄTA PRESENTATIONER 1.Gruppen motiveras - det är tacksamt att kunna visa upp färdigt projektresultat. 2. Obehagliga överraskningar undviks - intressenter som får se delresultatet efter varje sprint får veta exakt vad som kommer att levereras och ges möjlighet att i tid kunna påverka kommande projektresultat.

Under presentationen ska någon - exempelvis scrum mastern, men ansvaret kan cirkulera - agera som en moderator och försöka få intressenterna att ge så detaljerad återkoppling på resultatet som möjligt. Men bara för att det finns en utsedd moderator innebär det inte att hen ska hålla i hela showen. Tvärtom bör helst alla projektdeltagare visa upp delresultat som de varit inblandade i. Risken finns annars att projektdeltagare sitter passiva på dessa möten och upplever att de inte ger något.

Skilja på åsikter och krav Lika viktigt som det är att lyssna på allas kommentarer under detta möte, är det att klargöra beslutsfattandet. Hur rollerna är fördelade i projektet bör förtydligas på förhand, så att inga felaktiga förväntningar ska uppstå. Ett exempel: Om produktägaren är den ende som ska ha rätt att ställa krav bör övriga intressenter veta att deras åsikter är argument för att påverka produktägaren, men att deras åsikter inte nödvändigtvis kommer att få genomslag. Det finns nämligen en risk i att presentera delresultat och inhämta åsikter från ett antal intressenter om de drar allt för mycket åt olika håll. Deras åsikter kan i efterhand användas som försvar (eller gisslantagande, om man så vill) om projektresultatet inte blir som de tänkt sig. Presentationen bör vara skild från själva planeringsarbetet inför nästa sprint. Det är bra om produktägaren får möjlighet att smälta argument och

150

Kapitel 6

åsikter från en presentation innan hen tillsammans med gruppen planerar nästa sprint, helst redan nästa arbetsdag.

EXEMPEL PÅ SCHEMA UNDER SISTA DAGEN AV EN SPRINT: 13.00 -13.05: Ett extra stå-upp-möte för att ta upp eventuella sistaminuten-korrigeringar eller handpåläggning av presentationen. 13.05 -15.00: Moderatorn planerar hur sprintresultatet ska presenteras. Hen planerar även vilka punkter som är viktiga att få en diskussion kring och vilka intressenter som det är viktigast att få åsikter ifrån. Övriga i gruppen genomför eventuella sista justeringar eller förbereder det de ska presentera. 15.00 - 16.00: Gruppen och intressenterna träffas för presentation och demonstration av sprintresultat. 16.00 -17.00: Gruppen sätter sig ned och genomför ett erfarenhetsmöte kring vad de lärt sig under den gångna sprinten. 17.00 -19.00: Gemensam middag för att fira att sprinten är avklarad. Det är bra för motivationen att fira sina framgångar.

Erfarenhetsmöte Kaizen, som berörts tidigare, är en japansk filosofi som förespråkar en strävan att förbättras för varje dag som går. Filosofin innebär att man reflekterar över vad man gjort idag för att kunna utföra sina sysslor ännu effektivare i morgon. Inom agil projektledning anammas denna filosofi genom att man vid varje sprintavslut genomför ett erfarenhetsmöte med syftet att förbättra själva arbetsprocessen (kallas även sprintåterblick eller retrospective på engelska). Att löpande genomföra erfarenhetsmöten gör det möjligt att korrigera misstag under projektets genomförande. I många projektmodeller baserade på traditionella projektledningsmetoder föreslås erfarenhetsmöten som en aktivitet vid projekts slut. Detta erfarenhetsmöte har då ofta syftet att hjälpa organisationen att bli effektivare i att hantera projekt. Med löpande erfarenhetsmöten ges möjlighet att bli bättre medan projektet fortfarande pågår istället för att sitta ned efter projektets slut och säga: "I nästa projekt, DÅ kommer vi att göra helt rätt från början!".

Genomförande

151

Vad är bra, vad kan bli bättre? Ett erfarenhetsmöte bör hållas kort och effektivt. Eftersom det är något projektgruppen kommer att göra vid varje sprintavslut är det viktigt att det inte drar ut på tiden och blir en för stor belastning för projektets budget. Mellan 30 och 60 minuter är en möteslängd att sträva efter. Ett sätt att genomföra erfarenhetsmötet på är enligt följande: i. Två kolumner på väggen

Moderatorn som håller i mötet, vilket kan vara projektledaren eller ett roterande ansvar, ritar upp två kolumner på en tavla och anger följande rubriker för respektive kolumn: ■ Vad gick bra? ■ Vad kan förbättras?

2. Alla skriver individuella lappar Alla projektdeltagare får ett antal post it-lappar. Var och en skriver under tio minuter ned saker som gått bra och saker som kan förbättras, en per papperslapp. Att låta varje individ skriva sina upplevelser gör att gruppen undviker att endast åsikter från de mest verbala gruppmedlemmarna kommer fram. Allas röster ska höras. Några tips för att skriva på ett effektivt sätt är: ■ Var konkret.

Om svaret på frågan om vad som gått bra lyder "God kommunikation" kan det vara svårt att dra lärdomar av detta om det inte specificeras vad som var bra med kommunikationen. Mer givande är då: "God kommunikation eftersom alla projektdeltagare satt i samma rum" eller "God kommunikation eftersom alla använde tavlan för att visa vad de arbetade med" ■ Utse inte syndabockar inom projektet.

Att peka ut individers brister är inte ett fruktbart beteende i en grupp som vill kunna utvecklas och fungera bättre tillsammans. Snarare finns risken att samarbetet försvåras på grund av individuella motsättningar. Sök istället att finna anledningar till problem ur ett processperspektiv. Istället för att säga "Kalle klantade sig när han skulle ändra i databasen" så kan man, ur ett processperspektiv, peka på förbättringsmöjligheten. "Rutiner vid förändringar i databasen måste förbättras för att öka

152

Kapitel 6

säkerheten" är en mer konstruktiv formulering. Det är bättre att försöka hålla processen, inte individen, i fokus när gruppmedlemmarna skriver sina lappar. 3. Diskutera och besluta

Moderatorn klistrar upp lapparna i respektive kolumn, läser upp vad som står skrivet på varje lapp och tar bort eventuella dubbletter. Gruppen diskuterar sedan i tur och ordning innehållet på varje lapp och beslutar om vilka punkter under "Vad kan förbättras" som kan genomföras inför nästa sprint. Ett sätt att besluta vad som är viktigast att förbättra är att låta alla i gruppen rösta. Till exempel kan man låta en tuschpenna gå runt bordet och låta varje person med punkter pricka för de tre sakerna de tycker är viktigast (på engelska: dot voting). När gruppen sedan ser vilka problem som fått flest röster kan de börja diskussionen med det viktigaste problemet och beta av dem i fallande prioritetsordning. Moderatorn läser sedan lapparna under "Vad gick bra" och gruppen kan då diskutera hur dessa framgångar ska fortsätta att vara starka sidor för gruppen. Några saker att tänka på under denna diskussion:

Genomförande

153

■ Erfarenheter är alltid sanna.

Vad en projektdeltagare upplevt går inte att ta ifrån henne eller honom. Det som står på lappen är hur någon upplevt situationen i projektet och detta måste alla ta hänsyn till. Bara för att en person anser att kommunikationen var tydlig kan andra i projektet haft annorlunda förväntningar och upplevt verkligheten på ett annat sätt. ■ Diskutera orsaken till upplevelsen.

Sök överrensstämmelse kring vad som orsakat olika upplevelser i projektet och försök på det viset att se vilka delar som behöver förändras. Efter detta moment är erfarenhetsmötet färdigt. Se till att besluten nedtecknas och att dessa tas med till uppstartsdagen i nästa sprint. Ett bra sätt är att göra dessa anteckningar på ett stort blädderblocksblad som sedan kan fästas på väggen i gruppens projektrum. Efter ett antal sprinter kan gruppen kanske hitta mönster i vilka problem som återkommer och därefter ta ett större grepp kring förbättringar för dessa återkommande fel. Det här var ett sätt att genomföra erfarenhetsmötet på. Det finns många varianter på hur de kan genomföras och flera av dem är beskrivna i boken Agil projektledning Övningsbok.

Löpande riskhantering I agila metoder görs en löpande riskhantering då man arbetar med fråga nummer tre på det dagliga mötet: Vad kan hindra dig från att lyckas? Projektgruppen arbetar faktiskt aktivt med risker varje dag i och med denna fråga. I många projekt finns intentionen att aktivt och löpande arbeta med risker men man orkar sällan följa upp den tidigt utförda riskanalysen. Det blir istället ett vackert dokument i en pärm som står och samlar damm under projektet. Anledningen till att det i många projekt sällan sker ett aktivt riskarbete är mycket enkel: att arbeta med risker betraktas inte som ett produktivt arbete eftersom det inte på ett direkt sätt för projektet närmare slutmålet. För varje minut man lägger på att fundera över risker, skapar alternativplaner eller letar efter mindre riskfyllda, alternativa lösningar tillbringar vi en minut på en aktivitet som endast på ett indirekt sätt tar projektet närmare ett levererat slutresultat. Det gör att många projekt inte kan prioritera sitt riskarbete.

-154

Kapitel 6

För att verkligen arbeta aktivt med risker har därför de agila projekten brutit ned riskarbetet till en kort daglig aktivitet. I och med att det tar så lite tid och ger direkt nytta — eftersom risker hanteras samma dag som de uppmärksammas, är det lättare att prioritera riskarbetet. Längre och större aktiviteter för att hantera risker är svårare att se den direkta nyttan i, och det är därför de ofta inte blir av. Ramverket SAFe föreslår däremot en utökning av arbetet med att hantera risker. Under den två dagar långa planeringsworkshopen (PIplaneringen) får teamen även i uppgift att fundera över potentiella risker för hela projektet, risker som de inte kan lösa i sin egen grupp. Så fort en risk identifieras skriver teamet ned den på en post-it-lapp och lämnar den till moderatorn. I slutet av workshopen går alla scrum masters igenom lapparna och bestämmer en av fyra möjliga åtgärder som på engelska förkortas till ROAM. Bokstäverna står för Resolved (Löst - vi beslutar oss för något som gör att risken inte är en risk längre), Owned (Ägd — någon ansvarar för att följa upp risken), Accepted (Accepterad — vi kan helt enkelt inte göra något åt risken) och Mitigated (Minskad — vi planerar in en åtgärd som minskar riskens effekt på projektet).

700

procent felfritt?

Här kommer en klurig projektsituation: Låt oss säga att projektet under en sprint har tio krav som har brutits ned till 40 aktiviteter, vilka behöver utföras. När det är en vecka kvar av sprinten har gruppen lyckats tillgodose åtta av de tio kraven men samtidigt har testaren upptäckt ett antal fel. Två av dem är direkt kritiska fel, som gör att sprintens slutresultat inte kommer att bli användbart om inte felen åtgärdas. De fem övriga felen är "skönhetsfel", alltså enklare fel som inte omöjliggör användandet av projektresultatet. Vad ska projektgruppen prioritera att göra? Här följer några alternativ: TÄNKBARA ALTERNATIV NÄR FEL UPPTÄCKTS 1.Fortsätta att jobba med aktiviteterna för de återstående kraven. 2. Åtgärda alla fel, såväl de kritiska felen som skönhetsfelen, innan gruppen fortsätter med de återstående kraven. 3. Åtgärda kritiska fel men sedan fortsätta med de sista kraven (och därmed strunta i att åtgärda skönhetsfelen.)

Genomförande

155

Alternativ 1 bryter mot en agil princip. Risken med att bara köra på och vänta med att åtgärda upptäckta fel gör att gruppen skapar ett projektresultat med låg kvalitet. Det är dessa projekt som ofta drar ut på tiden i slutet eftersom projektledaren under projektets gång har sagt att: "Projektet ligger bra till i projektplanen men det är några fel kvar att åtgärda". Ofta inser projektgruppen att det var ett större jobb att åtgärda dessa fel än man först hade trott. Dessutom gör detta förhållningssätt att vi inte kan delleverera resultat löpande och få nytta av projektresultatet under vägen. Den som väljer alternativ 2 kan sägas ha rätt i teorin men fel i praktiken. Principen att alltid leverera felfritt projektresultat kallas ibland 100 procent felfritt. Med 100 procent menas då att gruppen inte lämnar ifrån sig ett projektresultat som har några fel kvar. Men - och här kommer problemet det finns även den agila principen som säger att man ska göra det nyttigaste för kunden först. Är det verkligen nyttigare att åtgärda varenda skönhetsfel om det innebär att kunden inte kan använda sig av resultatet från krav nio och tio efter denna sprint? Att välja alternativ 3 är en god kompromiss mellan att leverera ett användbart resultat och samtidigt följa principen kring att låta nyttan styra i projektprioritering. Avvägningen i exemplet ovan är dock inte helt oproblematisk. Anta att det här var den sista sprinten gruppen genomförde i ett it-projekt och att projektet levererar projektresultatet till fortsatt drift och förvaltning. Alla användare är glada för att de fick funktionaliteten för krav nio och tio men driftsorganisationen verkar inte lika glad. I det här it-projektet var de där "skönhetsfelen" tyvärr av en sådan art att projektresultatet blev mycket dyrare att använda. Ett av felen krävde åtgärder varje dygn - handgrepp som drifts- och förvaltningsavdelningen sluppit om projektgruppen åtgärdat alla fel. Och eftersom 85 till 99 procent av projektkostnaden för de flesta it-projekt ligger i själva driften av projektresultatet, så kan felen innebära att kostnaden för hela projektlivscykeln blir avsevärt dyrare än om projektet hade åtgärdat alla fel från början.

Produktägaren avgör Som synes är finns risker med alla valmöjligheter ovan. Men det finns faktiskt ett korrekt alternativ och det lyder: Det produktägaren väljer! Produktägaren behöver ge klara direktiv angående strategi kring upptäckta fel:

156

Kapitel 6

Strategi för 700 procent betyder att gruppen följer devisen 100 procent felfritt, vilket innebär att gruppen aldrig behöver stämma av hur allvarliga felen är utan hellre skjuter mål till nästa sprint än att leverera några fel. Detta alternativ gör att projektgruppen inte behöver störa produktägaren utan blir helt självgående. Det är då viktigt att produktägaren förstår att även små fel kommer att åtgärdas utan diskussion. Strategi från-fall-till-fall: Gruppen visar produktägaren vilka fel som upptäckts för att utifrån dessa avstämningar ta beslut om vilka fel som ska åtgärdas och vilka som ska läggas åt sidan. Denna strategi förutsätter att produktägaren är ordentligt engagerad och har möjlighet att stämma av och ofta ta beslut löpande under sprinten.

Mer om Kanban: att arbeta utan pulser Tidigare nämndes metoden Kanbans fokusering på en mer detaljerad projekttavla och att det blivit populärt i it-drifts- och förvaltningsmiljöer. Anledningen till populariteten inom dessa verksamheter beror på mer än själva tavlan. Kanban innebär nämligen att man jobbar utan de pulser, cykler eller sprintar som jag nämnt tidigare. Istället för en uppstartsdag där man planerar sprintens jobb så lägger produktägaren till krav löpande i "Ej påbörjat"-kolumnen allt eftersom de dyker upp. Varför det då? Jo, ofta beror det på att verksamheten inte kan detaljplanera inför framtiden. Ta till exempel en helpdesk-grupp. De vet kanske vilka jobb de ska ta tag i de närmsta två eller tre dagarna men sedan har de tyvärr ingen aning. Deras jobb uppstår när personer ringer in med sina ärenden. De kan inte planera in tre veckors jobb. En annan liknande situation har projektgrupper som arbetar i helt nya områden där de inte vet vad som kommer att hända. I forskningsprojektet kan vi kanske planera för de närmsta dagarnas experiment men utfallet kommer att sätta agendan för vad vi kan göra efter det. Att arbeta efter Kanban-metoden innebär alltså att bryta den typiska agila pulsen för att istället ha ett löpande, kontinuerligt arbete av nya krav och aktiviteter. Har ni en miljö där även den närmsta tidens planering är svår att få till är det värt att prova. Vissa skapar hybrider, till exempel genom att planera in hälften av den tillgängliga tiden under den närmsta sprinten och låta resten av tiden vara till för att fylla på löpande.

Genomförande

157

Många som arbetar enligt Kanban försöker ändå att få till fördelarna av pulstänket om än inte i samma beskedliga upplägg. De kanske träffar produktägaren en gång i veckan för att diskutera detaljer kring krav som lagts till, presenterar delresultat för intressenter varannan fredag och har erfarenhetsmöten sista onsdagen i varje månad. En viktig detalj för att få Kanban att bli effektivt är att produktägaren måste ha gott om tid för att arbeta med gruppen. Eftersom krav kan läggas till när som helst måste gruppen snabbt och ofta kunna sitta ned och diskutera och tidsuppskatta arbete med produktägaren.

Praktikaliteter För många projekt som befunnit sig i kris finns erfarenheter av att det ofta är de praktiska omständigheterna som avgjort effektiviteten och framgången. Praktiska arbetssätt och konkreta verktyg som effektiviserar arbetet kan med ett samlat namn kallas praktikaliteter. Praktikaliteterna rör den fysiska arbetsmiljön och är ofta små detaljer till stöd för gruppens

I agila skolexempel lokaliseras hela projektgruppen i ett rum med möblering enligt bilden ovan. Med stolar vända in mot mitten kan man alltid lyfta blicken och se varandra i ögonen när man samtalar.

158

Kapitel 6

arbete. De lyfts sällan fram i projektledningslitteratur eftersom många anser att de är på "för låg nivå". Tvärtemot den åsikten kan man hävda att det är just dessa små detaljer som ofta lyfter eller stjälper projekt. Djävulen bor som bekant i detaljerna. Ett exempel på praktikalitet är hur projektgruppen är placerad. En samlad projektgrupp har avsevärt bättre förutsättningar för kommunikation än en som sitter utspridd på olika adresser, lokaler eller våningar. En reservation kan dock vara på sin plats: praktikaliteternas effektivitet är inte någon universell sanning och de lämpar sig inte för alla typer av projekt. Grupper motiveras av olika saker och olika grupper har olika svårigheter. Det finns däremot ett antal praktikaliteter som stödjer det agila arbetssättet och som i de flesta fall har en motiverande verkan på projektgruppen. Så för att arbeta agilt är det en god i& att prova praktikaliteten under en sprint, utvärdera efter sprintens slut och besluta om praktikaliteten var användbar eller inte. Att vara agil är, som tidigare förklarats, att hela tiden försöka förbättra arbetssättet.

Lokal I agila projekt talar man om "bredbandskommunikation" vilket då inte har någonting med internet att göra utan innebär att alla ska kunna kommunicera med varandra utan svårigheter. Gruppen vill dessutom att alla ska kunna se varandras ögon, inte bara under det dagliga mötet utan i bästa fall även under arbetets gång. Den principen efterlevs genom att projektgruppen är liten och allra helst placerad i ett och samma rum. Om projektgruppen finns på en plats har projektdeltagarna ingen, eller i alla fall mycket kort väg att gå för att diskutera problem som rör projektet. Det kan tyckas att en korridors eller en vånings avstånd inte borde spela någon roll. Ändå är det inte sällsynt med kommunikationsproblem som uppstår när deltagare gör antaganden på grund av att man inte "orkade" gå och fråga. Elakt skulle man kunna säga att människan är lat av naturen eller så kan man konstatera att vi ofta optimerar vårt eget arbete till förmån för gruppens arbete. Människor avstår från att gå upp en våning och ställa frågan eftersom det tar av ens egen tillgängliga tid. Om projektmedlemmarna däremot vinner och förlorar lika mycket tid, vilket är fallet när man sitter i samma rum och kan ställa frågan direkt, kommer risken för kommunikationsproblem vara mindre.

Genomförande

159

SAMMA RUM ELLER INTE

diskussionerna ofta som en

Många vittnar om både goda

anledning för att slippa hålla

och dåliga erfarenheter av att

på med det tråkiga vardagliga

sitta i samma rum. I ett projekt

jobbet. De individer som inte

som växte ur sin lokal blev man

ingick i själva diskussionen

till slut tvungen att sitta på två

fick inte heller någonting gjort

olika platser. Trots chatverktyg,

eftersom de stördes av det ideliga

mejlkonversationer och många

pratet. Lösningen blev att man

telefonsamtal förlorade projektet

splittrade gruppen. Med varje

mycket av sin effektivitet. Det

person i var sitt kontor (men med

projektet hade mått väldigt bra av

många inplanerade möten) ökade

att ha alla projektdeltagare i en

effektiviteten igen.

och samma lokal. I ett annat projekt, med många

Så vad är rätt? I första hand bör gruppen sitta samlad i ett

vältaliga projektmedlemmar,

projektrum. I de allra flesta

tog den sociala aspekten över

projekt leder detta till högre

effektiviteten. För att uttrycka

effektivitet - de misslyckade

det på ett annat sätt: gruppen

exemplen är relativt få. Om detta

trivdes för bra med varandra

trots allt leder till problem så

men gillade projektet alldeles

kan projektdeltagarna splittras

för lite och snackade bort viktig

genom avskärmningar eller i sista

arbetstid. Diskussioner drog ut på

hand var sitt rum. Detta bör då

tiden, och trots att diskussionerna

kompenseras med fler tillfällen för

(oftast) rörde arbetet så användes

kommunikation.

Gruppregler Gruppregler kallas ibland ground rules och är överenskommelser kring hur gruppen ska samarbeta i projektet. I vissa projekt pratar man om gruppkontrakt — en samling regler eller värderingar som hela gruppen kan enas om att följa i arbetet som genomförs. Gruppregler handlar ofta om tider och normer. En uppsättning gruppregler kan se ut så här:

160

Kapitel 6

EXEMPEL - GRUPPREGLER ■ Alla jobbar i projektlokalen mellan klockan 9 och 16. ■ Telefoner ska vara inställda på ljudlös (endast vibration) i lokalen. ■ När någon ställer en fråga tar vi oss tid att besvara den, det tjänar hela gruppen på. ■ När någon stöter på problem ska det direkt påtalas för scrum mastern som har rätt att när som helst sammankalla projektgruppen till ett kort möte.

Gruppreglerna kan se väldigt olika ut. Projektledare gör klokt i att ta ett längre möte med projektgruppen tidigt i projektet för att diskutera vilka regler som ska gälla i gruppen och sammanställer reglerna till en lista som kan kompletteras under projektets gång. Om någon i gruppen vill diskutera en värdering bör den möjligheten ges — för att hela projektet ska bli effektivare och för att alla ska veta vad som gäller.

Projektvägg

Transparensen är viktig i agila projekt. En betydande praktikalitet är därför hur projektet åskådliggörs. Tidigare i kapitlet har projekttavlan och progressdiagrammet beskrivits. Det är en stor fördel om projektgruppen har en hel vägg avsatt för sitt projekt som kan användas till allt som ökar effektiviteten. Gemensamma regler, återkommande fel, risker, hinder eller beslut fattade från erfarenhetsmöten är några av de saker som kan skrivas ned på blädderblocksblad och fästas på väggen. Det finns många exempel på vad man kan ha på sin projektvägg som hjälper till att visualisera projektet. Jimmy Janln har skrivit en förträfflig bok (se referenslistan) med 96 olika visualiseringsexempel från olika agila team. Här kommer några exempel som delvis är självupplevda, delvis inspirerade från Jimmys bok:

Levande intressentkarta

Resultatet av intressentanalysen kan självklart användas under fortsättningen av projektet. Varför inte visualisera utestående frågor, beroenden

Genomförande

161

eller andra ärenden som har med olika intressenter att göra? Det kan dessutom vara bra att spara avslutade ärenden för att få en historik över vilken typ av beroenden projektet har med olika intressenter.

Team Blue

Edward

Avslutade Team Blue

MP"

Partner Z Role B"'

" Projekt •-•

Partner

Tool W

■

Process A 01% Role B

■

Edward

Process A

Tool W

Exempel på visualisering av beroendet till olika intressenter under projektet.

Visualisering av förbättringsarbete Projekttavlan är till för att visa upp produktägarens krav och gruppens arbetsuppgifter under sprinten. Så hur ska man visualisera förbättringsarbete, till exempel att produktägaren arbetar med att få fram nya verktyg från andra delar av organisationen eller styrgruppsmedlemmen Lenas arbete med att hitta användare från en annan målgrupp som kan ställa upp i referensgruppsmöten? Ett sätt är att skapa en egen horisontellt gående rad på projekttavlan och döpa den till "Förbättringsarbeten" och använda den för att sätta upp post-it-lappar för varje förbättringsarbete. Denna rad visar då arbete som utförs såväl av projektgruppens medlemmar som av andra intressenter, till exempel styrgruppsmedlemmar. Ett annat sätt är att göra en mindre tavla (med samma tre kolumner) som bara innehåller

162

Kapitel 6

■

förbättringsarbeten. Det kan ibland vara bra med en egen tavla avsedd för styrgrupp och produktägare. Kanske passar den bättre på en annan plats än i projektrummet, på produktägarens dörr eller om det finns ett rum som alltid används för styrgruppsmöten.

Återkommande hinder Blir ert projektarbete ofta stoppat av olika sorters hinder? Upplever ni att det är ett fåtal återkommande källor till dessa hinder, till exempel en annan grupp ni är beroende av eller en viktig leverantör eller intressent? Förutom att använda röda lappar i projekttavlan för att visa när aktiviteter blir hindrade kan det vara användbart att föra statistik över var hindren kommer ifrån. Då kan ni dessutom bestämma er för att göra en åtgärdsplan när antalet hinder från en källa har nått ett visst antal, exempelvis fem hinder.

Produktionschefen

Labbet

Leverantören

Team Beta

Exempel på att visualisera återkommande hinder med mätpunkter för när det är dags att agera.

Genomförande

163

POST-IT-LAPPAR Post-it lappar är ett på många sätt oslagbart verktyg för att planera och följa upp projekt. Att de är gjorda för att tillfälligt fastna på ytor gör dem flexibla och användbara - men samtidigt något opålitliga. Post-it-lappar som fallit ned på golvet låter kanske inte som något stort problem men kan vara oerhört frustrerande när de behöver plockas upp från golvet för femte gången. Här kommer två tips för att få de små rackarna att sitta kvar: 1.Köp post-it-lappar med bättre fästförmåga. De har ibland namn som "super sticky" eller "extra sticky" och är gjorda för att sitta fast längre. De är lite dyrare men väl värda investeringen. 2. Riv av dem från ena kortsidan till den andra för att de inte ska krulla sig. River man av en post-it-lapp genom att ta tag i den nedre långsidan och rycka av lappen från bunten kommer den ofta att krulla sig i överkanten där klistret finns.

Beslutslogg En och annan brukar känna oro över hur lite dokumentation agila metoder kräver och pekar på hur ofta det faktiskt blir problem i projekt för att människor inte vet vad som bestämts och sagts. Vill man koka ned problemen så brukar de flesta uppstå på grund av fattade beslut under projektets gång, det vill säga förändringar. Ofta kan dessa förändringar synas direkt i post-it-lappar på projektväggen men somliga beslut gäller under lång tid och kan därför ställa till det. Exempelvis kanske produktägaren Anna beslutat att projektgruppen alltid ska använda färgen Lagun Metallic för alla målerier och då vill naturligtvis Anna att denna information följer med projektet sprint för sprint resten av tiden. För den här typen av beslut är det praktiskt att ha en beslutslogg. En beslutslogg är helt enkelt en lista som ofta innehåller kolumnerna datum, beslut, beslutsfattare och eventuellt en kommentar.

164

Kapitel 6

Datum

Beslut

Beslutsfattare

Kommentar

Projektgruppen ska alltid 2020-10-15

använda Lagun Metallic

Produktägare Anna

för alla målerier

Exempel på beslutslogg.

Detta blir ett dokument som lever med projektet och som hela tiden växer och minskar. Det är scrum masterns uppgift att underlätta för projektet och därför ser en scrum master till att beslut som inte längre gäller plockas bort och att aktuella beslut finns kvar. Vissa sparar denna beslutslogg i en wiki som det går att läsa mer om nedan.

Genomförande

165

Digitala foton På projektväggen kan alla enkelt se projektets status, hinder, gruppregler, intressenter och andra saker som rör projektet. Men risken och nackdelen med detta manuella sätt att arbeta är att projektet riskerar att förlora historiken. En oinformerad städare som river ned störande papper eller chefens son på besök är konkreta risker för projektets dokumentation. När gruppen senare i projektet ska utvärdera eller förklara ett fattat beslut kan det visa sig svårt utan någon dokumentation att peka på. Ett enkelt sätt att kombinera fördelarna med att jobba utan datoriserade planeringsverktyg men att ändå behålla historiken är att dagligen fotografera projektväggen. På det viset kan projektet enkelt följa historiken i projektet och se ögonblicksbilder av projektet även bakåt i tiden.

Diskussionswebsida - Wiki Runt 2005 började en typ av programvara kallad wiki användas för samordning och sökning av information och med samma struktur som diskussionsforum. En väldigt känd wiki är såklart Wikipedia. Wikipedia fungerar som ett uppslagsverk skapat av alla som vill bifoga information ett lexikon uppbyggt av användarna själva skulle man kunna säga. En wiki inom ett enskilt projekt fungerar på samma sätt men med begränsningen att det bara är deltagarna i projektet som skapar denna kunskapsmassa och enkom för sitt eget användande. En wiki bygger på att en deltagare skriver en textsnutt i systemet som andra kan bygga vidare på. Exempelvis kan Anna skriva "Idag insåg jag hur svårt det är att tidsuppskatta aktiviteter för motordesign". När Kalle läser denna kan han vilja hjälpa till och lägger därför upp en egen sida i wikin som han döper till "motordesign". Kalle kan därefter länka sin sida till ordet "motordesign" i Annas text. Genom att bygga ut information om saker på det här viset blir hela wikin till ett spindelnät av referenser och kommentarer som alla kan ha nytta av. Rent praktiskt brukar projektgrupper använda sin wiki på ett sådant sätt att den speglar projektets upplägg. Exempelvis brukar varje leverans få sin sida och i varje leverans får varje sprint sin egen sida. Ofta brukar dessa sidor följa någon form av mall för att all grundläggande information för varje sprint ska finnas med. Bra exempel på sådan information är:

166

Kapitel 6

■ Gruppmedlemmar (vilka som deltar under sprinten) ■ Sprintens längd (start- och slutdatum) ■ Datum och klockslag för demonstration ■ Vad som ska demonstreras

Ovanstående är alltså att se som exempel. Som i all dokumentation i agila projekt måste gruppen och produktägaren hela tiden utvärdera om mallens innehåll är relevant och tillför projektet något. Jag har skrivit det tidigare men skriver det än en gång: det är lätt att fastna i ett "malltänkande" där projektet riskerar att känna att "följer vi bara mallen så har vi gjort rätt". Det viktiga är att alla förstår att mallen bara är ett stöd. Det är gruppen som måste skapa rätt och relevant dokumentation för projektet utifrån de behov och krav som finns.

Att jobba i par De flesta gillar att arbeta på egen hand, med ansvar för att slutföra sitt eget arbete och att tillåtas tillräcklig autonomi för att kunna planera sin dag utifrån eget tycke. Många moderna motivationsforskare (såsom Amabile och Kramer, 2011) har bevisat att autonomi är en oerhört viktig egenskap för att vara kreativ och motiverad på sin arbetsplats. Samtidigt finns det stora fördelar av att lösa arbetsuppgifter genom att jobba i par. Det är lättare att lära upp nya medarbetare, det skapar mindre behov av dokumentation eftersom två personer vet hur lösningen genomfördes och många initiala misstag undviks när det finns ett bollplank att testa sin i& på. Många agila grupper har därför skapat gruppregler kring pararbete. I it-världen kallas konceptet "par-programmering" och reglerna kring hur det görs är väldigt skiftande mellan olika grupper. Några programmerar faktiskt i par hela tiden, även om det är ovanligt (och riskerar dessutom att bli väldigt påfrestande och ansträngande). Vissa bestämmer att de parprogrammerar två timmar per dag, direkt efter lunch. Det gör att de kan spara extra kniviga uppgifter tills de har någon att diskutera det med. Andra jobbar bara i par när behov finns, när en uppgift upplevs som väldigt svår. Under morgonens stå-upp-möte bestämmer de helt enkelt att två personer får ansvaret för en uppgift, istället för en. Andra använder pararbetet som ett sätt att bredda kompetensen för hela gruppen och pararbetar därför efter ett rullande schema, så att alla får jobba med alla. Det är viktigt att inte

Genomförande

167

se pararbete som "antingen eller" utan att diskutera hur det skulle kunna gynna gruppens arbete utan att för den skull begränsa kreativiteten och motivationen hos gruppmedlemmarna.

Testa först För läsare som har stött på det agila arbetssättet i it-branschen är det möjligt att ni hört konstiga förkortningar varav en av dem är TDD. Det står för Test Driven Development och går helt enkelt ut på att testa innan man bygger något. Det kanske låter konstigt eller ologiskt men här kommer en kort förklaring av såväl tankesättet som dess ursprung: En stor utmaning i alla former av projekt där ett komplext projektresultat tas fram är att testa funktionalitet löpande. Tidigare beskrevs fördelen med att testa sprintvis så att projektgruppen i små steg ser att lösningen fungerar. Varje förändring av befintligt resultat riskerar potentiellt att saker som tidigare fungerade inte fungerar längre. Att testa tar tyvärr tid. Den vanligaste anledningen till att saker inte testas tillräckligt ofta är just för att det stjäl tid från att jobba med resultatet. Tidstjuven är inte bara själva testandet utan tolkningen av testresultatet som också kan ta upp mycket av tiden. Tolkningarna och missförstånden mellan testare och konstruktörer är tyvärr väldigt vanliga så vad kan man göra för att förhindra det? TDD innebär att sätta testandet i fokus på flera sätt. Dels börjar testare, gärna tillsammans med konstruktör/utvecklare/den-som-ska-bygga-grejen och formulerar själva testet. Det gör att konstruktören redan i detta läge förstår mer av hur testet sedan kommer att gå till så att misstolkningar slipper ske. Det test som skrivs ska vara väldigt litet. Så litet att det helst går att testa direkt efter att konstruktörens aktivitet är klar (som tidigare beskrevs ska aktiviteter helst vara så korta att de kan slutföras på en till två arbetsdagar). Nästa steg är att sätta upp själva testet så att det går att återskapa enkelt. Det här går tyvärr inte att appliceras i alla former av projekt. I it-projekt är det enkelt att återskapa tester eftersom det test som skapas blir en programsnutt som kan köras igen. Vid produktutveckling i andra, fysiska, miljöer innebär det att man måste bygga upp en testbänk eller labbmiljö som gör det enkelt att testa. Även om ert projekt inte har förutsättningen för att kunna återskapa tester som i it-projekt så är det värt att lägga energi på att se vad som går att göras för att förenkla testandet. Nu är det dags att köra testet. Självklart kommer testet att visa "Ej godkänt" — ingenting är ju byggt ännu!

168

Kapitel 6

Men nu kan konstruktören börja bygga och eftersom testet finns klart så kan hen när som helst testa igen. Till slut kommer testet att visa på ett godkänt resultat och då är det dags att tillsammans med testaren skapa nästa steg av testet. För många projektgrupper kanske detta arbetssätt upplevs som abstrakt om ni inte arbetar med it-utveckling där detta tillvägagångssätt är enkelt och billigt att åstadkomma hela vägen. Försök ändå att diskutera hur testandet skulle kunna sättas i fokus, hur exempelvis testfall skulle kunna skapas tidigt och vad som skulle kunna göras för att återupprepad testning skulle kunna gå att göra enklare.

Sammanfattning Genomförande i agila projekt innebär en cykel av ett antal återkommande aktiviteter där varje sprint har samma utseende: INNEHÅLL I VARJE SPRINT ■ Sprintplaneringsmöte med detaljering av krav, lösningar och aktiviteter för sprinten. ■ Dagliga stå-upp-möten under sprinten. ■ Demonstration/Presentation av resultatet för projektets intressenter. ■ Erfarenhetsmöte för gruppen där förbättringar diskuteras. Detta har blivit den vedertagna cykeln för att arbeta agilt men egentligen är inte processens utseende det viktigaste. Detta är föreslagna ramar att utgå ifrån för att arbeta effektivt på ett agilt sätt. Det viktigaste är att projektarbetet hela tiden utvecklas, då ständig förbättring är det mest centrala i det agila synsättet.

Genomförande

169

Övningar — Stå-upp-möte

1

Tid för övning: 15 minuter Diskutera i grupp hur projektgruppens stå-upp-möten kan bli mer effektiva. Den vanliga formen av stå-upp-möte innebär att man går laget runt med en fråga, men i olika grupper fungerar detta mer eller mindre effektivt. Vissa deltagare vill kanske prata länge och andra får tunghäfta. Det finns olika sätt att se till att allas röster blir hörda. Kanske bör man ha en tydligare mall än de tre frågorna? Kanske den som är pratsammast ska prata sist och att mötet avslutas efter 15 minuter, oavsett hur mycket den pratsamme har kvar att säga? Att dela in gruppen i två mini-grupper kanske är en tänkbar väg, i det fall projektmedlemmarna ändå jobbar med olika delar under en period? Även här gäller det att tänka fritt och diskutera möjligheter för att bli effektivare.

2 — Projektväggen Tid för övning: 5 + 25 minuter Låt alla projektmedlemmar fundera och göra egna anteckningar kring hur de vill att projektet ska använda sin vägg för att bli till största möjliga nytta. Låt dem ha några utgångspunkter som de funderar kring om det ska användas och i så fall hur, exempelvis: ■ Projekttavla Vilka kolumner ska användas? Räcker ejpåbörjat, påbörjat och klart eller behövs fler eller andra kolumnrubriker? Ska röda lappar användas? ■ Progressdiagram Vilka värden ska användas (Återstående arbetstid? Återstående uppskattad tid? Nedlagd arbetstid?) ■ Beslut från erfarenhetsmöten - som blädderblocksblad på väggen? ■ Gruppregler - som blädderblocksblad på väggen?

Fem minuter brukar räcka för att fundera för var och en. Använd sedan resten av halvtimman åt att diskutera och besluta hur projektväggen ska användas.

170

Kapitel 6

3 - Gruppregler Tid för övning: 30 minuter

Diskutera inom gruppen vilka gruppregler som ska gälla för arbete i det här projektet. Diskussionen kan ske helt förutsättningslöst men moderatorn kan även utgå ifrån vissa områden som känns relevanta att besluta regler kring. Här kommer några exempel på områden som kan vara bra att utgå ifrån: • Arbetstider. • Respekt för varandra. ■ Telefonanvändande. ■ Mötesregler, till exempel: Hur gör vi för att alla ska få komma till tals? Hur gör vi om någon/några tar upp för mycket av taltiden? Hur gör vi om någon/några inte är aktiva under möten? Listan kan göras lång beroende på vilken sorts problem eller effekter ni som grupp är ute efter. Den sista punkten ovan (mötesregler) handlar mer om att få en diskussion kring vilka värderingar var och en har i gruppen, snarare än regler. Dessa värderingsdiskussioner är väldigt nyttiga tidigt i projektet för att bättre förstå var och ens inställning till arbetet. Summera era gruppregler på en plats och synliggör dem för hela gruppen under hela projektet.

Övningsboken: I kapitel 4 finns flera konceptuella övningar där ni som grupp kan få uppleva utmaningar i genomförandefasen. Då många söker efter olika varianter för effektiva erfaren-

AglI polektledning

ÖVNINGS BOK

hetsmöten finns hela sju övningar som låter er prova olika format. Fyra diskussionsövningar handlar dessutom om viktiga principer för ett effektivt genomförande i agila projekt.

Genomförande

171

-12,r Ji.V_ • •

Avsluta projekt

Många klagar över svårigheten i att avsluta sina projekt. De vrider på sig bara man nämner ordet avslut och öser ur sig exempel på tillfällen då de slet och slet för att få en kund att acceptera att projektet var färdigt. Det har då oftast rört sig om projekt vars resultat ska förvaltas av någon annan. Den överlämnande och den mottagande parten kan ha olika syn på när projektet ska vara avslutat eftersom båda vill att den andra parten ska lösa återstående fel eller problem. Andra förstår inte alls att det skulle kunna vara svårt att avsluta projekt. Det är ofta personer inom verksamheter där projektet är ett evenemang som genomförs och sedan helt naturligt tar slut.

174

Kapitel 7

Att avsluta agila projekt Att avsluta projekt innebär i mångt och mycket samma sak för traditionella som för agila projekt. Men det finns en avgörande skillnad. Agila projekt är ofta mycket lättare att överlämna och avsluta eftersom de sprintresultat som skapas löpande, om och om igen i projektet, redan har kunnat stämmas av. Det gör att agila projekt sällan har några återstående överraskningar i slutet av projektet - allt projektresultat har ju redan visats under projektets gång.

Varje början år svår, pp speciellt på slutet. (Zarko Petran)

ATT AVSLUTA PROJEKT INNEBÄR OFTA TVÅ MOMENT: 1.Överlämning av projektresultatet - till någon som får ansvaret för att det används, utvecklas eller sköts om. 2. Efterarbete - såsom att lämna tillbaka resurser i form av både material och människor, samt rapportera slutsatser och erfarenheter från projektet.

Projektöverlämning När beslut fattats om att överlämna projektet måste ett antal aktiviteter genomföras. Vilka de är beror på hur projektet är upplagt och vilka avtal som gäller för projektet. Några exempel på aktiviteter som kan behövas är: ■ Avslutande test av användare (brukare). ■ Upprättande av och godkännande av protokoll från detta test. ■ Åtgärdande av de uppkomna felen i det avslutande testet. ■ Förhandling med intern mottagare. ■ Kontroll av de åtgärdade felen (att de verkligen är åtgärdade). ■ Hantera restpunkter efter denna kontroll. ■ Överlämning av dokumentation.

Aktiviteterna kring överlämning brukar för många projekt innebära att det blir hektiskt i slutet. I de allra flesta traditionella projekt ser behovet av arbete ut enligt följande modell:

Avsluta projekt

175

Arbetsmängd i traditionella projekt

Behov av arbete

Projektets tidslinje

Projekt är ofta arbetsintensiva i början och i slutet. Agila projekt strävar efter att ha få en jämnare arbetsbelastning över hela projekttiden. Oftast behöver alltså traditionella projekt intensifiera sitt arbete i början för att komma igång, och i slutet för att komma till rätta med alla detaljer. Orsaken till detta är ofta att projektet i ett antal månader har arbetat med ett projektresultat utan att göra delleveranser eller noggranna avstämningar löpande under projektet. Det är vanligt att projekt ser ut att följa tidsplanen fram till att överlämningen påbörjas men att många förseningar uppkommer då. När väl användare testar de olika delarna blir det helt enkelt merarbete för projektet eftersom ett antal saker inte fungerar som det var tänkt.

Löpande överlämning En orsak till att de agila projekten kan minska den stora arbetsbördan i slutet av projekten är att de försöker väva in många av de avslutande momenten löpande i projektet så att de slipper bli så "baktunga". Med många korta sprintar där intressenter löpande får se projektresultatet minskar projektet risken för överraskningar i slutet. För att ytterligare minska arbetsbördan kan projektet bestämma sig för att inte bara presentera och demonstrera utan även testa och godkänna delresultat löpande under projektet. På det viset kan det bli väldigt få moment som behöver göras under själva överlämningsfasen i agila projekt.

176

Kapitel 7

Genomförandefasen i agila projekt innebär en puls av sprintar. Varje puls innebär en detaljplanering, ett genomförande, en demonstration och ett erfarenhetsmöte. I varje sprint är fokus framåt till nästa sprint. Därför finns det också en viss risk för kortsiktighet i detta arbetssätt; att projektet bara tittar framåt så långt näsan räcker. Många som arbetat i längre, mer än årslånga, agila projekt berättar ofta att de i efterhand upplevde att de inte hade gjort tillräckligt stora förändringar i tid, trots att de ständigt försökt att förbättra sin process. Eftersom erfarenhetsmöten och detaljplaneringar är så korta kan det innebära mycket begränsade möjligheter att titta tillbaka i ett större perspektiv än bara den senaste sprinten.

Flera avslut Ett sätt för att komma runt det här problemet, i långa projekt, är därför att medvetet göra flera riktiga avslut som komplement till den löpande överlämningen. Vid varje sådant del-avslut genomförs då ett riktigt överlämnande och ett längre erfarenhetsmöte där projektgruppen och intressenter tittar på hela den period som projektet pågått - istället för bara den senaste sprinten.

FLERA

AVSI* PÅ BRITISH

tremånadersperioden gav worksho-

TELECOM

pen möjlighet för projektet att göra

Tidigare i boken beskrevs British

en riktig omstart var tredje månad.

Telecom där man upplevde många

Alla kunde reflektera kring hela den

problem med att driva projekt som

tidigare tremånadersperioden och dra

pågick under en allt för lång tid.

slutsatser inför den kommande perio-

Lösningen blev att, oavsett den

den. Tidigare misstag och felaktiga be-

tänkta projekttiden för hela projektet,

slut kunde helt rivas upp eftersom varje

planera för ett kvartal i taget. Varje

nytt kvartal innebar ett nytt projekt.

kvartalscykel innebar då att gruppen gjorde en större workshop inför det

Tidsuppskattningar kunde på det här viset bli ännu exaktare eftersom

kommande kvartalet där projektgrup-

varje tremånadersperiod inkluderad

pen, produktägare och intressenter

allt, inklusive rättningar vid slutbesikt-

låste in sig i en workshop som pågick

ning och slutdokumentation. Detta

under tre dagar. Förutom att det ska-

gav stor effekt på projekt som var

pade en tydlighet för den kommande

stora och drevs under en längre tid.

Avsluta projekt

177

Denna indelning är då medvetet gjord, det vill säga inte baserad på att exempelvis kunden vill ha något slutfört. Istället skapar projektgruppen en indelning av projektet för att få en möjlighet att titta på det delresultat som åstadkommits hittills, fatta nya beslut utifrån dem och lära av sina erfarenheter. Det handlar alltså inte bara om ett extra erfarenhetsmöte utan att skapa något helt klart som då kan testas och förstås bättre. Det här tankesättet är även centralt när man arbetar enligt SAFe, som beskrevs i planeringskapitlet. Strävan är att i varje kort intervall också göra något som är användbart, inte bara färdigställt. Det kallas ibland Minimal Viable Product (MVP), ett definierat delresultat som är användbart och som också kan ge oss värdefull återkoppling på vilken sorts funktionalitet som vi ska bygga vidare på (eller lägga ned).

Att överlämna eller inte - det är frågan Att kunna leverera något användbart efter varje sprint är en grundläggande ide i agil projektledning och något som berördes ingående i kapitlet om genomförande. Denna princip innebär ofta också att projektet, vid varje sprintavslut, har en möjlighet att göra en överlämning och ett avslut av hela projektet - alltså mer eller mindre i förväg. Projekt som syftar till ett visst slutresultat vid en på förhand överenskommen tidpunkt, som att sätta upp en konsert eller genomföra riksdagsvalet, har visserligen inte den möjligheten. Många projekt har möjligheten men utnyttjar den tyvärr ändå inte.

När målen nås i förtid I projekt med starkt fokus på mätbara mål kan man ofta med fördel överväga om tidigare avslut är möjligt. I det tidigare beskrivna exemplet Projekt Morotshår var målet att sälja 100 000 flaskor före årsskiftet och ett antal moment fanns inplanerade för att åstadkomma det tänkta projektresultatet. Denna typ av mål innebär att projektet skulle kunna avslutas i förväg. Vid varje sprintslut under hösten kunde projektet helt enkelt stämma av försäljningsstatistiken och eventuellt säga "Nu har vi uppnått 100 000 flaskor, det är dags att överlämna och avsluta projektet". Detta gör att agila projekt kan avslutas tidigare än planerat, vilket är ganska ovanligt i projektsammanhang. Tidigare avslut möjliggörs av de

178

Kapitel 7

täta avstämningarna under genomförandet, och att varje sprint förväntas innebära ett färdigt moment.

Ofrivilliga avslut Att på agilt vis arbeta med sprintvisa leveranser av projektresultat innebär även att risken i projektet minskar. Nästan alltid finns externa förutsättningar kring projekt som, om de av någon anledning försvinner, gör att projektet kan tvingas lägga ner i förtid. Det kan röra sig om nyckelpersoner som agerar beskyddare av projektet men som plötsligt byter tjänst, det kan vara avtal eller överenskommelser om finansiering som ligger till grund för projektet men som plötsligt hävs. Ägarbyten, politiska maktskiften, finanskriser och omorganisationer är några exempel på de många andra indirekta risker projekt står inför och som kan innebära tidigarelagda avslut. Det agila sättet att löpande leverera resultat innebär att både den ekonomiska och prestigemässiga förlusten kan bli avsevärt mindre i nedlagda agila projekt än i sedvanligt drivna projekt. Ingen anställd vill ha ett skrotat projekt på sin

Avsluta projekt

179

meritlista, ingen finansdirektör vill kasta pengar i sjön. Ofta har det agila projektet hunnit leverera värde under sin livstid vilket blir något som både de ekonomiskt ansvariga och de enskilda projektdeltagarna i efterhand kan ta fasta på, i såväl CV som årsbokslut.

Vem beslutar om avslut? Vem avgör när det är tillåtet att överlämna och avsluta? Produktägaren? Scrum mastern? Eller borde det vara gruppen, med tanke på den agila iden om att gruppen tar beslut och att gruppen är autonom? Tidigare beskrevs det beslutsmandat som produktägaren ska ha kring alla frågor som handlar om vad. Det vill säga vad som ska byggas, göras eller levereras. Till detta hör naturligtvis även beslut kring överlämning och avslut. Beroende på hur projektet är sammansatt kan en produktägare ibland behöva ta hjälp ovanifrån för dessa beslut, från kunden eller överordnad projektbeställare om sådan finns. Men även från den roll som benämnts intern mottagare. Däremot lyssnar självklart en bra produktägare på sitt team och ett bra team är transparent och påtalar om de anser att fortsatt arbete med projektet skulle ge för lite och att det är bättre att avsluta projektet i stället.

Förhandlingar kring överlämning Överlämnandet kan vara väldigt olika formaliserat beroende på projektkultur. I vissa miljöer räcker det med ett beslut om överlämning från en överordnad chef. I andra fall kan överlämnandet innebära ett förfarande med granskning och testande av slutresultatet som följs av förhandling kring när och hur projektresultatet ska överlämnas. I tekniska projekt kan exempelvis en besiktning av projektresultatet visa att fyra allvarliga fel och åtta mindre fel har upptäckts. Förhandlingens utfall kan då bli att projektet inte får överlämnas förrän alla allvarlig fel och hälften av de mindre felen åtgärdats. I en sådan mer komplicerad situation kan den sista sprinten bli en så kallad öppen sprint som innebär att projektgruppen arbetar under en obestämd tid fram tills att resultatet är uppnått. Detta är förvisso inte någon särskilt agil lösning eftersom den bryter mot principen kring time boxing. En annan lösning kan vara att gruppen får en sprint på sig för att lösa så många fel som möjligt och att sprintens slutdatum markerar slutet på projektet, oavsett antal åtgärdade fel.

180

Kapitel 7

Beslut om överlämning

Sprint

Sprint

Sprint

Sprint

12

13

14

15

Öppen sprint

Beslut om överlämning

Sprint

Sprint

Sprint

Sprint

12

13

14

15

Fast sprint

Öppen sprint kontra fast sprint efter överlämning.

De återstående problemen ansvarar därefter den interna mottagaren för. Om projektet exempelvis innebär ett husbygge är det alltså den interna mottagaren, exempelvis chefen för vaktmästeriet, som ansvarar för att ta hand om eventuella problem såväl som för att planera för fortsatt skötsel av huset.

Avsluta projekt

181

Projektavslut När överlämningen av projektet genomförts, inklusive handskakning med intern mottagare, återstår endast för produktägaren att avsluta projektet. Ofta behövs formella åtgärder som att be ekonomiavdelningen att stänga det konto som kostnader för projektet bokförts till, men förutom det är det produktägarens ansvar att föra kunskap om projektet vidare inom organisationen.

Slutrapport Under ett väl genomfört agilt projekt har gruppen genomfört erfarenhetsmöten vid varje avslutad sprint och förhoppningsvis sparat de beslut som fattats vid dessa möten. Vid projektavslutet bör produktägare tillsammans med gruppen göra en samlad bild av de erfarenheter som gjorts i projektet. Dessa erfarenheter brukar nedtecknas i ett dokument som kan kallas slutrapport, white book eller testamente. Oavsett namn är syftet att hjälpa verksamheten att lära sig av de erfarenheter som projektet fått genom att sammanfatta och dra slutsatser för hela projektet. Somliga genomför detta arbete inom gruppen (med teammedlemmar och scrum master) men det är en fördel om även produktägaren kan delta för att nyansera de iakttagelser och slutsatser som har dragits under projektets gång. Slutrapporter kan se väldigt olika ut. Ofta blir de allt för omfångsrika och läses inte av någon. Den agila värderingen att fokusera på projektresultat och dess nytta framför omfattande dokumentation talar för att man bör hålla denna dokumentation så kort som möjligt. Det är därför viktigt att i styrgrupp eller med beställare kritiskt diskutera exakt vad som behöver nedtecknas, i vilket syfte och vem den tänkta läsaren är. Det gör det tydligare för projektet att formulera sig rätt. FÖRSLAG PÅ INNEHÅLL I EN SLUTRAPPORT ■ De tre viktigaste erfarenheterna av hela projektet. ■ Erfarenheter i det löpande projektarbetet. ■ Tidstjuvar i projektet. ■ Viktiga händelser och beslut utanför projektet som påverkat resultatet. ■ Åtgärdsförslag inför kommande projekt.

182

Kapitel 7

Oavsett vilka punkter projektet väljer att ha i sin slutrapport så finns det en sak som är viktigare än allt annat — att den blir använd. Använd, inte bara distribuerad, för det är tyvärr inte samma sak. Det betyder att projektgruppen kanske ska samla hela avdelningen i lunchrummet och presentera sin slutrapport istället för att skriva ut och dela ut rapporten för att hoppas att den ska bli läst. Det kan innebära att projektgruppen publicerar slutrapporten på intranätet istället för att bara sätta in den i den pärm som man brukar göra i verksamheten. Om en slutrapport inte blir använd är framtagandet av den bara ett slöseri med tid.

Sammanfattning Att avsluta projekt handlar om två saker: att överlämna projektresultatet till någon som tar över ansvaret, samt visst efterarbete såsom att lämna tillbaka resurser och att förmedla sina erfarenheter. Även om projektavslut är något som görs sist i projekt så kan man i agila projekt på förhand planera in flera riktiga avslut. Det passar i längre projekt som på så vis kan stanna upp och dra slutsatser kring hela den period som projektet pågått. I agila projekt görs ofta erfarenhetsmöten i slutet av varje sprint, men de fokuserar ofta endast på den sprint som varit och den som komma ska. Med flera projektavslut får projektet en möjlighet att dra slutsatser för ett längre tidsperspektiv. Att slutrapporten blir använd är viktigt. Skrivs den kort och koncist eller presenteras muntligt är det större chans att någon drar lärdom av den.

Övningar Malt för bättre överlämning Tid för övning: 1 timme + 10 minuter Samla projektgruppen samt representanter från den mottagande organisationen. Sätt er ned runt en tavla eller blädderblock och diskutera vilka saker ni tycker bör finnas i en överlämningsmall för projekt. Utför övningen utan några stöd från mallar eller litteratur kring projektarbete. Diskutera i såväl stort som smått vad som bör finnas i mallen. (1 timme)

Avsluta projekt

183

Formalisera punkterna i ett dokument som ni sedan avser att använda under överlämningen. Om det finns en mall sedan tidigare stämmer ni för säkerhets skull av era punkter mot denna fôr att se så att ni inte missat något väsentligt. Oavsett om ni idag har en standardiserad mall för överlämning eller inte går övningen ut på att hitta bästa lösningen för er just nu. Mallar är bra att utgå ifrån men blir slöa verktyg om de slentrianmässigt används i alla situationer utan reflektion kring dess lämplighet.

Agil projektledning

ÖVNINGSBOK

Övningsboken: I kapitel 5 finns sex praktiska övningar som tränar er både för överlämning och för avslutsfasen. Diskussionsövningarna fokuserar på utvärderingsalternativ och möjligheten att få nytta av projektets erfarenheter.

184

Kapitel 7

När passar agila metoder?

Vad än säljare av certifieringar för agila metoder säger, så är det fullt möjligt för en organisation att använda vissa agila principer, och strunta i andra. Det finns egentligen bara en enda agil värdering som inte är förhandlingsbar: att projektet hela tiden ska sträva efter att vara bättre imorgon än det är idag. Men trots de agila metodernas anpassningsbarhet kan man urskilja några situationer och projekttyper där den agila metoden är mindre fruktbar, och några situationer då agil projektledning lämpar sig särskilt väl. Rätt verktyg för rätt problem brukar hantverkare säga, och samma sak gäller för projektledningsmetoder och projekt.

186

Kapitel 8

Goda förutsättningar för agila projekt Många typer av projekt passar för agil projektledning, särskilt med tanke på att vissa principer kan anpassas och att man inte behöver dra alla till sin spets. Det finns dock situationer då det agila sättet att arbeta i korta, avgränsade steg lämpar sig särskilt väl.

Otydlig kravbild Ett projekt med otydliga krav eller där kraven inte finns helt uttalade och specificerade från början brukar, i icke-agila organisationer, ofta innebära att projektet inte får påbörjas. Verksamheten upplever ofta att projekt som inte är tillräckligt definierade innebär för stor risk att starta och vill minska denna risk genom att förtydliga kraven tills riskerna känns som om de är under kontroll. Med ett agilt arbetssätt kan verksamheten istället säga: "Tio krav är tydliga men trettio krav behöver förtydligas. Projektgruppen kan påbörja arbetet med de tio kraven så reder vi ut fler Var inte rädd för det långsamma krav under tiden". framåtskridandet, var bara rädd Självklart finns det risker för stillaståendet. även med detta. Kanske (Kinesiskt ordspråk) skapas från början ett resultat som man sedan inser, efter att ha fördjupat sig i detaljer kring övriga krav, att man inte har någon användning av. Detta är självklart ett ställningstagande som får göras från fall till fall. Några projekt torde ha blivit lidande av att de startats för tidigt och det är en fara att ha i medvetande. Men många projekt har tvärtom misslyckats på grund av en för sen start som gjort att konkurrenterna kunnat leverera sin produkt först - vilket ett agilt angreppssätt kunnat förhindra.

pp

Föränderlig situation Många upplever att de inte får någon nytta av de traditionella projektledningsmetoderna när de arbetar i projekt där förutsättningarna ständigt förändras. De brukar tala om att de fick bra stöd under planeringsfasen men att dessa planer inte var till stor hjälp under resterande del av projektet. Ofta

När passar agila metoder?

187

vill ledningen i sådana situationer påpeka att ytterligare planering hade behövts. Men, som Dvir och Lechler (2003) såg i sin undersökning, så äts ofta nyttan av detaljerad och fördjupad planering upp av de förändringar som nästan alltid sker i projekt. Att planera mer innan projektet får startas är sällan lösningen i projekt där man i förväg kan förutspå att målet sannolikt kommer att förändras under projektets gång. Många entreprenörer och småföretagare vet att förutsättningar för hela deras verksamhet kan förändras väldigt snabbt på grund av en ny stor kund eller ett nytt uttalat behov från marknaden. De har då stor nytta av att hela tiden slutföra varje liten del som de genomför i sina projekt eftersom det gör det enklare att byta riktning. Med många halvfärdiga resultat finns det risk att verksamheten inte får någon nytta av någonting, i det fall ändrade krav inträder.

Komplexa projektmål Ibland är det svårt att förklara hur projektmålen ska se ut trots att de långsiktiga, övergripande målen är väldigt tydliga. När en amerikansk president på 60-talet basunerade ut att USA skulle bli först med att placera en människa på månen fanns ingen otydlighet kring det långsiktiga målet. Men hur projektets mål skulle se ut var inte lika lätt att definiera. Innebar projektmålen en raket med möjlighet att landa och starta på månen? Eller en raket som släpper ifrån sig en kapsel som ska landa på månen, kunna lyfta och sedan docka med raketen som tar den tillbaka till jorden? I alla situationer där själva lösningen är svår att definiera finns en fördel i att jobba i korta steg där varje steg blir en naturlig beslutspunkt för nästa steg. De första stegen i projekt där projektmålen är komplexa blir ofta ett framtagande av någon sorts prototyp eller modell som ger möjlighet att definiera projektmålen tydligare. I exemplet med månlandningen fanns dessutom en betydande sannolikhet att projektet inte ens skulle gå att genomföra och varje kort sprint innebar då även ett affärsbeslut kring om projektet ska få fortsätta eller läggas ned. Det agila sättet att arbeta underlättar denna typ av affärsbeslut eftersom det finns ett ordentligt avslut efter varje sprint, då det också är naturligt att fatta beslut om fortsättningen. I många andra projekt blir tyvärr affärsbesluten något som bara blir formalia eftersom projektet varken har gjort något färdigt eller står inför att påbörja något nytt.

188

Kapitel 8

I alla situationer där det kan vara svårt för projektbeställare och projektgrupp att tydligt se hur slutresultatet kommer se ut har man nytta av att ta små steg i början, då prototyper och modeller ger vägledning och en möjlighet till förhandstitt på slutresultatet.

När snabbt resultat behövs Projekt som av tidspress behöver få snabbt synliga och användbara resultat får bra stöd av det agila arbetssättet. Om exempelvis verksamheten ser ett plötsligt tillfälle på marknaden som borde utnyttjas gynnas projektet av att i korta steg kunna leverera något användbart.

Sämre förutsättningar för agila metoder Det finns situationer där agil projektledning inte lämpar sig särskilt väl. Det är projekt där vissa grundläggande agila värderingar inte går att följa på grund av yttre begränsningar eller värderingar i verksamheten. Ibland kan de ändå gå att justera till att passa för agil projektledning, åtminstone i delar av projektet. Men de förutsättningar för projekt som nämns nedan är typiskt svåra utmaningar för att få agil projektledning att fungera effektivt.

När passar agila metoder?

189

Skilda kulturer Om en agil projektgrupp är beroende av en annan projektgrupp som vägrar att befatta sig med att leverera i korta överenskomna steg, blir det svårt att samarbeta effektivt. Den agila projektgruppen kommer att skapa saker i korta steg som ändå inte kan användas till någon nytta på grund av den andra gruppen. Samma risk finns om den agila projektgruppen är beroende av en underleverantör som inte arbetar agilt. En annan sorts krock är då gruppen vill arbeta agilt men beställare eller inköpare kräver ett traditionellt projektarbetssätt. De kommer då att ha väldigt olika syn på vad som är viktigast att prioritera: De traditionella kommer att förorda längre tid för planering och specificering medan de agila troligtvis vill komma igång med en första prototyp. Problemet med skilda kulturer och synsätt är utan tvekan den största utmaningen för agila projekt idag. Det betyder inte att det är omöjligt att arbeta sida vid sida eller att alla projekt och verksamheter måste bli agila — det betyder bara att det är viktigt med gränssnitt. Med andra ord; man måste vara medveten om i vilka avseenden man är beroende av varandra. Gränssnittet mellan projektgrupp och beställare måste redas ut så att de kan enas om en samarbetsform på dessa områden. Kringliggande projekt eller leverantörer kan vara icke-agila och det agila projektet bör planera med en strävan att ha så få beroenden som möjligt, så att de kan arbeta så självständigt som möjligt. De gränssnitt som ändå måste finnas måste definieras och kommuniceras tydligt för att inte störa det agila projektet.

EXEMPEL - GRÄNSSNITT MOT ICKE AGIL LEVERANTÖR Om byggprojektet Nya Simhallen arbetar agilt och behöver ha färdiga väggmoduler från TryggBygg AB som aldrig arbetat agilt, är det allra bäst om TryggBygg kan acceptera att träffa Nya Simhallen-projektet vid varje sprintstart och sprintslut för att se när och vilka väggmoduler som behövs vid olika tillfällen. Om de inte kan leva upp till det måste istället Nya Simhallen-projektet ställa krav på vid vilka tidpunkter väggmoduler måste vara levererade för att de inte ska störas eller vara beroende av TryggBygg AB för sitt eget arbete.

190

Kapitel 8

Hög kostnad för förändring I ett projekt som handlar om att föreslå en ny organisationsplan kostar en förändring inte mer än tiden för att sudda ut och dra nya streck på ett papper. I ett infrastrukturprojekt där asfalt redan har lagts på en vägsträcka blir en förändring naturligtvis oerhört kostsam. I den sortens projekt, där kostnaden för förändring av redan levererade delresultat är mycket stor, blir det svårt att i praktiken vara särskilt föränderlig. Projektet får helt enkelt inte ut all den nytta som skulle kunnat åstadkommas, om förändringen i sig inte är möjlig att genomföra till rimlig kostnad. I den här sortens projekt är det därför viktigt att, om man ändå vill arbeta agilt, dela in projektet i olika faser där vissa faser är agila och andra inte. Arbetet fram till en färdig plan kan till exempel genomföras i korta föränderliga steg. Projektgruppen i ett asfalteringsprojekt kan arbeta i korta steg vilka avslutas med ett möte där förändrade arbetsrutiner diskuteras trots att själva vägsträckan inte är möjlig att förändra. Det går med andra ord att få nytta av delar av det agila arbetssättet trots att hela projektet inte är lämpligt för agil projektledning.

Fasta kontrakt När ett fast kontrakt har upprättats där allt har specificerats i minsta detalj, finns det inte heller möjlighet att förändra och omprioritera delar av slutresultatet löpande i projektet. Det är i själva verket mycket vanligt att projektbeställare vid uppstart av projekt lever i den fasta övertygelsen att projektet kommer bli exakt enligt specifikationen. Att många beställare beställer projekt på det här viset är för att de ibland tror att projekt är att likställa med en produkt. Att beställa en ny bil med dess olika färg- och utförandealternativ kan utan svårighet göras i extrem detalj. Beställaren i bilutställningshallen kan direkt se hur bilen kommer se ut med kromade detaljer på backspeglarna. Tyvärr kan verksamheten sällan på förhand förutse det exakta resultatet av ett projekt. Förändringsönskemål dyker upp längs vägen i de flesta typer av projekt. Att många avtal mellan kund och leverantör har en fast och detaljspecificerad form, beror dessutom ofta på att kunden är orolig över om de ska få vad de betalar för. Generellt kan man säga att situationer som, avtalsmässigt eller regelmässigt, omöjliggör flexibilitet och förändrade lösningar längs vägen, är situationer där agila metoder har svårt att ge

När passar agila metoder?

191

samma nytta. Exempelvis kan proceduren kring offentliga upphandlingar vara en begränsande situation för agila metoder, eftersom lösningen som det beslutats om ofta är detaljerat beskriven från start. Betyder då detta att projekt aldrig kan drivas med agil projektledning om de grundas i ett fast avtalskontrakt? Nej, lyckligtvis är det inte så.

Fasta avtal i agila projekt Det finns ändå sätt att få de fasta avtalsprojekten att fungera och gynnas av ett agilt arbetssätt. Projektet kan exempelvis delas in i kortare delar, till exempel tre månader, där varje del är fast. Det gör att både beställare och leverantör har en viss risk men öppnar för att förändra projektet vid varje sådant delprojekt. Ett annat sätt är att förändringarna kan ske precis som vanligt, med korta agila cykler av arbete, men att kostnaden för dem är något som projektledaren och kunden skriver upp på en restlista, precis som vid traditionella projekt. Det kräver lite mer administration eftersom projektledaren och kunden för varje förändring måste avgöra om det är kunden eller det agila projektet som ska stå för kostnaden av förändringen — vilken ur projektets perspektiv då alltså betraktas antingen som ett tillägg till ursprunglig beställning eller som en miss i planeringen. Svårigheterna med att kombinera fasta avtal och agila projekt kan man läsa om i både litteratur och på diskussionsforum på nätet, där också ytterligare lösningar på problemet presenteras. Se till exempel agilakontrakt.se som har återkommande konferenser om agilt arbete vid offentlig upphandling.

Agila metoder i stora projekt Vikten av att ha små och effektiva grupper i agila projekt har redan poängterats. Antalet gruppmedlemmar ska helst inte överstiga tio personer. Men innebär det att agila metoder inte lämpar sig för stora projekt? Innan svar ges kan man begrunda ett exempel: Svenska soldater i FN-tjänst är tränade för att agera i små, effektiva grupper. I grupper om fem till åtta personer löser de sina uppgifter med stöd av vissa rutiner, viss träning och viss utrustning. De har med andra ord en modell som fungerar i en liten, effektiv grupp. Ger det faktumet skäl att misstänka den militära modellen för att fungera dåligt i stora insatser, stora projekt eller stora krig? Det

192

Kapitel 8

skulle nog få hålla med om. Den militära organisationen innefattar ju också rutiner och ramverk för hur de enskilda enheterna interagerar och koordinerar sina insatser.

Behålla småskaligheten Konstigt nog verkar många, när man talar om agila metoder, anta att en modell som fungerar väl i små grupper inte skulle fungera i ett större sammanhang. De agila metoderna är till sin struktur väldigt avskalade ramverk av såväl process- som rollbeskrivningar. Den självklara frågan är därför: "Vad ska förändras för att få det agila projektet att fungera när vi växer?" Det enkla svaret är: Så lite som möjligt. Projektet ska fortsätta att arbeta i små grupper och i sprintar kortare än en månad vardera. Tessem

När passar agila metoder?

193

och Maurer (2008) visar i sin forskning att det viktiga för att få ett stort agilt projekt att fungera är att bibehålla de agila värderingarna kring självstyrande små grupper som själva kan slutföra sina åtagna uppgifter. Det blir med andra ord frågan om att bryta ned stora projekt till många små underprojekt. Styrkan med de agila metoderna är att de gör arbetsprocessen i någon mån självgranskande. Eventuella svagheter i projektets framskridande lyfts fram, eftersom man hela tiden har dagliga avstämningar och ser på projekttavlan vad som sker. Detta kan göras oavsett storleken på projektet. Däremot kan verksamheten behöva tillföra något till den agila metodens avskalade ramverk när projekten växer. För att samordna undergruppernas projekt kan till exempel ytterligare mötesformer behövas. Några av dem omtalas längre fram i detta kapitel. I stora projekt krävs också en större medvetenhet om den rådande organisationskulturen, vilket är betydligt svårare att få till i stora grupper jämfört med en enskild liten projektgrupp. Samtidigt är det viktigt att inte underskatta utmaningen i att koordinera flera projektgrupper. På senare år har därför ett flertal metoder dykt upp med fokus på koordinering såsom det tidigare beskrivna och mest utbredda SAFe (Scaled Agile Framework). Flera andra storskaliga ramverk har också fått spridning såsom LeSS (Large-Scale Scrum), Spotify-modellen och DAD (Disciplined Agile Delivery). Framför allt lyfter dessa metoder fram vikten av en gemensam planering. Att samla alla team, produktägare och andra intressenter för att tillsammans skapa en plan för att få en överblick över vilka beroende som finns, vilka potentiella risker som finns vid förseningar och för att se till att det löpande går att leverera färdiga delresultat. I planeringskapitlet visades hur en programtavla från SAFe-ramverket visualiserade beroenden mellan team. Denna tavla tas fram under den planeringsworkshop som kallas PI planering som i SAFe följer den standardiserade agenda som visas i figuren nedan.

194

Kapitel 8

Dag 2

Dag i

8:009:0o

Verksamhetens status och hur det kommande projektresultatet stöttar verksamheten

8:009:00

Eventuell justering av planen

9:0o10:30

Vision för produkten/ projektet

9:0011:00

Fortsatt teamplanering

10:3011:30

Vision för arkitektur och utvecklingsarbetet

11:0013:00

Varje team presenterar sin plan och därefter lunch

11:3013:00

Planeringsguidning och därefter lunch

13:0014:00

Genomgång av risker

13:0016:00

Team planering

14:0014:15

Gemensam röstning: tror vi på planen?

16:0017:00

Varje team presenterar sin preliminära plan

14:15??

Eventuell justering av planen

17:0018:00

Ledningsöversyn av planen

Erfarenhetsmöte för planeringsdagarna

Agenda för PI-planering fritt översatt från www.scaledagileframework.com.

Kulturen krossar Inom företaget Ford genomfördes ett stort förändringsprojekt med namnet Way Forward. I deras projektrum hängde en inramad skylt med orden "Culture eats strategy for breakfast". Innebörden är förstås att alla planer och strategier som görs upp hotas om andra motstridiga värderingar råder i projektorganisationen. Med andra ord: I stora projekt blir de agila principerna lätt hajmat i käftarna på den förhärskande organisationskulturen.

När passar agila metoder?

195

När företag i sina projekt försöker anamma det agila synsättet hamnar de lätt i diskussioner om detaljer kring verktyg och process: Ska vi ha en fysisk projekttavla eller en digital projekttavla? Hur långa sprinter ska vi ha? Den här typen av detaljer är självklart viktiga men ofta glömmer organisationen den övergripande frågan: Hur ska vi förändra vår kultur? För innan verksamheten har lyckats förändra sin kultur kommer förändringen inte att bli genomgripande och verktygen kommer inte att användas på rätt sätt. Skogshuggaren kommer att stå och riva bladet på sin ostartade motorsåg mot trädet och undra varför den fungerar så dåligt.

Att förändra kulturen En kulturell förändring måste till för att få stora agila projekt att lyckas. Anställda som inte anammat de agila värderingarna kan inte plötsligt, som i ett trollslag, bli agila i det nya stora projektet. För att få en agil kultur måste verksamheten börja i liten skala med att lära sina anställda de agila värderingarna. Först då är verksamheten rustad för att ta sig an ett större projekt med ett agilt angreppssätt. Alla måste inte ha omvänts till den nya religionen men om de agilas skara är i minoritet kommer verksamheten att få stora problem. Alla som har försökt vet att det är svårt att förändra kulturen inom en verksamhet. Det är dessutom omöjligt att ändra allt, så prioriteringar måste göras. De två processer som är viktigast att förändra för framgångsrika agila projekt är hur man fattar beslut och hur man kommunicerar.

Beslutfattande i gruppen När det gäller beslutsfattande är det oerhört viktigt att varje grupp inom ramen för ett stort projekt har anammat de agila värderingarna kring självstyrande grupper. Om den kulturen saknas riskerar avsaknaden av beslut ovanifrån att lamslå aktiviteten i respektive grupp. Varje grupp måste känna att de inte bara får vara en del av beslutsfattandet utan att också varje projektdeltagare förväntas ha åsikter för att fatta beslut. Somliga ser de agila metoderna som något mjukt och inte så strikt eftersom de ofta saknar många omfattande dokument - men det är på sätt och viss precis tvärt om. I agila projekt är kraven på disciplin och förväntningar på gruppmedlemmarna höga då verksamheten förväntar

196

Kapitel 8

sig aktivt deltagande utan möjlighet att gömma sig. Varje projektdeltagare blir en del av besluten och måste stå för dem. För att fatta bra beslut behövs dessutom en attityd av öppenhet från projektdeltagarna. De måste känna sig trygga med att dela med sig både av kunskap och av problem de stöter på. Det är därför viktigt att försöka skapa team som arbetar tillsammans under en längre tid, eftersom förtroende för varandra i gruppen behöver byggas upp över tid. Utan denna förståelse i projektet kommer verksamheten troligtvis inte lyckas. Verksamheten kan finslipa och förändra ledningsstrukturen tills de storknar utan att få särskilt god effekt om inte synsättet med självstyrande grupper har anammats. Genom att få ned beslutsfattandet i gruppen frigör verksamheten beslutskraft uppåt i organisationen - chefer högre upp i organisationen får helt enkelt mer tid för att göra nyttigare saker. Det går dessutom att vara betydligt större som projekt om verksamheten lyckas med detta. På Google beskriver en ansvarig chef att han som mest hade 160 systemutvecklare i grupper med färre än tio deltagare direkt under sig. En så platt organisation kan bara fungera om varje grupp är självstyrande i väldigt hög utsträckning.

Flera grupper, en produktägare Som beskrivits i kapitlet om roller bör man eftersträva att inte dela rollen som produktägare mellan flera personer. Det är en viktig princip som fungerar utmärkt för en enskild projektgrupp. Hur gör man om man har flera grupper då, inom ramen för ett stort projekt? Innebär det att man måste ha en produktägare för varje projektgrupp? Det rätta svaret är: det beror på. Om teamen klagar på att produktägaren inte ger dem tillräckligt med tid för att hjälpa dem behövs en produktägare per team. Organisationen har däremot ofta nytta av att få samma person som produktägare för två eller kanske tre team, om de arbetar med samma lösning. Det gör det enklare att koordinera uppgifter och att få ut det mesta av teamen. Tidigare, i den agila världens barndom, var oftast lösningen den senare, att produktägare hade hand om flera team. Tyvärr upptäckte många team, för sent, att de inte fick tillräckligt mycket tid för diskussioner med produktägaren längre och det försvårade möjligheten till snabba beslut. Många strävar därför idag istället åt att ha en produktägare per team, bara för få mer tillgänglig tid tillsammans med produktägaren.

När passar agila metoder?

197

EXEMPEL — PRODUKTÄGARE I TVÅ GRUPPER Det stora projektet Super-Ubåt 2000 har en fantastisk produktägare i Lisa som kan allt om exakt navigation i en ubåt och vet exakt vad som behöver göras. Produktägaren Lisa kan ha startat med en liten grupp men inser allt eftersom attgruppen behöver delas. Ofta kan man då inte dela upp arbetet mer än att grupperna ändå måste ha mycket med varandra att göra: Exempelvis måste kanske Anna i första gruppen få funktionen X42 färdigställd av Ingvar i andra gruppen, för att hon ska kunna påbörja sitt arbete i nästa sprint. Då är det idealiskt om Lisa ansvarar för vad som ska tas fram i båda dessa grupper, det vill säga agerar produktägare för båda. Hon kan då prioritera krav för båda grupperna så att ingen behöver vänta. Med varsin produktägare hade en synkning av krav försvårats. Men om Lisa upptäcker att hon får svårt att hinna med att svara på frågor måste hon kanske tänka om. Eftersom tillgänglig tid är avgörande för att få en produktägare att arbeta effektivt med sin grupp måste hon kanske lära upp någon annan som kan ta jobbet som produktägare för ett av teamen. I så fall måste hon bestämma hur ofta de ska träffas och hur de ska samarbeta, kanske tre en-timmas möten per vecka.

Produktägarteam eller meta scrum Givetvis finns en övre gräns för hur många grupper en ensam produktägare kan vara delaktig i. Om projektet består av tio grupper kommer inte en delad produktägare att bli särskilt effektiv. Praxis för antalet möjliga grupper för en produktägare har sjunkit år för år och många organisationer sätter en maxgräns på två eller tre grupper. En produktägare kan behöva hjälp med att vara produktägare, vilket redan omtalats i kapitlet om roller. För att lyckas med flera produktägare eller andra intressenter som hjälper produktägaren behövs ett forum där de kan mötas. Larman och Vodde (2008) kallade först denna gruppering för meta scrum men har i sin tidigare nämnda metod LeSS döpt om det till produktägarteam, ett namn som anammats av de flesta större agila verksamheter. Ett produktägarteam kan exempelvis träffas en gång per vecka och fatta beslut som påverkar det övergripande projektet. Projektgrupperna arbetar precis som vanligt i sina sprinter och om de är en månad långa så har projektets produktägarteam

198

Kapitel 8

hunnit ha fyra möten, inför varje nytt sprintlaneringsmöte, där de finjusterat kraven i det som kallas förfiningsmöten (refinement meeting) inför såväl den kommande sprinten som för resten av projektet.

Scrum of scrums På det dagliga stå-upp-mötet har projektgruppen sin dagliga avstämning, då också problem inom gruppen kan redas ut. Så hur gör projektet då det är så stort att det finns flera grupper? Har de separata möten så riskerar ju projektet att missa viktig information för en grupp som även berör en annan grupp. Slår man samman gruppernas möten blir det omöjligt att ha den effektiva och detaljerade avstämning det dagliga stå-upp-mötet syftar till. Patentlösningen på problemet, vilken beskrevs för första gången av en av scrum-metodens grundare Jeff Sutherland, kallas scrum of scrums. Det innebär ett möte med representanter från olika projektgrupper som har ett eget dagligt möte där frågor som berör flera grupper diskuteras.

När passar agila metoder?

199

Konceptet scrum of scrums är inte helt trivialt. Hur det ska göras effektivt i varje unik organisation kräver viss laborering. Flera erfarna metodkännare, exempelvis Larman och Vodde (2008), pekar på typiska fel vid införande av scrum of scrums. De varnar exempelvis för risken med viskleken. Om varje projektgrupp skickar sin scrum master för att representera gruppen finns det risk att de svar som framkommit sedan inte görs begripliga för de projektdeltagare som behövde ha informationen. Det är därför viktigt att det inte blir till ett ledningsgruppsmöte utan ett möte där de människor som behöver information deltar. Ett sätt att minska behovet av dessa scrum of scrums är att odla en kultur där det inte bara är tillåtet utan uppmuntras att delta i andra enskilda gruppers stå-upp-möten. På det viset kan antalet scrum of scrums-möten hållas nere. Det viktiga är att projektet provar sig fram för att hitta rätt. Scrum of scrums kanske ska kompletteras med att man då och då har stormöte — något amerikanerna kallar town hall meeting — med alla projektdeltagare.

Lämpliga projekttyper Lämpar sig vissa projekttyper mer för agila projekt än andra och på vilket sätt? Det finns förmodligen lika många sätt att dela in projekt i typer som det finns projektledare. Alla har sin definition och sina erfarenheter av vad som fungerar i olika typer av projekt. Några som har lagt ned mycket arbete på att försöka hitta en fungerande gruppering för att dela in projekt i är forskarna Tomas Jansson och Lennart Ljung (2009), som i sin bok Hemligheten med projektledning klassar projekt i fem olika typer och beskriver vad som är viktigt för varje typ. 1. Produktutvecklingsprojekt är projekt för att utveckla det utbud av

varor eller tjänster som ska erbjudas kunderna. I produktutvecklingsprojektet fokuseras på frågor relaterade till själva varan eller tjänsten: Vilka egenskaper är viktigast, hur ska den framställas och levereras? 2. Interna förändringsprojekt syftar till att förändra hur man bedriver

arbetet i verksamheten. Ledningen av ett internt förändringsprojekt fokuserar på förändringsmotstånd, drivkrafter, beteenden men också möjligheter till effektivisering, besparing och expansion.

200

Kapitel 8

3. Marknadsprojekt syftar till att påverka efterfrågan på våra produkter

eller tjänster. De viktiga ledningsfrågorna handlar om de externa relationerna: Vilka är kunderna, våra partners och våra konkurrenter? Hur tänker de, vad gör de, vad tycker de är viktigt? 4. Kundorderprojekt levererar enligt avtal med en viss kund. Projektet

har lovat en leverans och projektet går ut på att skapa och lämna över det man kommit överens om. Relationen med kunden är den naturliga utgångspunkten för ledningen av projektet. 5. Evenemangsprojekt handlar om att skapa och genomföra ett

evenemang. Först vid leveransen får man veta om det fyllde behoven och förväntningarna. I evenemangsprojekt beror framgången av att man lyckas förbereda sig väl. Leveransen är en aktivitet som man inte kan göra om eller komplettera i efterhand. Den självklara utgångspunkten för ledningen av projektet är förberedelserna inför evenemanget. I de flesta projekt i verkligheten kan man se drag från två, tre eller ännu fler av projekttyperna. En kampanj för en ny produkt (marknadsprojekt) innebär exempelvis också att befintliga rutiner måste förändras (internt förändringsprojekt) för att man senare ska kunna hantera beställningar och avsluta med en stor mässa (evenemangsprojekt).

Agila metoder i olika projekttyper Det behövs mycket mer forskning för att ge svar på frågan om vilka projekttyper som lämpar sig för agil projektledning, men några resultat har redan framkommit. Agila metoder har uppstått ur produkt utvecklingsprojekt. Det är i den typen av projekt som grupper sett det stora behovet av att kunna göra snabba justeringar utifrån förändrade krav som uppstått sent i processen. Många interna projekt handlar om förändringar av en organisation och i en del fall med it-system inblandade i förändringarna. Det agila sättet att arbeta kan i vissa delar vara väldigt lämpligt att utgå ifrån men för kategorin interna förändringsprojekt i dess helhet kan det innebära svårigheter.

När passar agila metoder?

201

Exempelvis bör stora förändringar internt kommuniceras ytterst tydligt och ofta är kommunikationen svårare än själva förändringen för att få ett lyckat resultat. Detta kräver ofta noggrannare och mer detaljerad planering långt i förväg och att sätta upp mål i korta cykler kan vara kontraproduktivt. Att däremot, när den stora kartan är lagd, bedriva utvecklingen av it-systemet agilt har inte dessa nackdelar. I kundorderprojekt genomförda med agil projektledning visar undersökningar att kunden genomgående har varit mer nöjd med det levererade slutresultatet (Ambler, 2008). Som beskrevs tidigare i kapitlet avgör däremot avtalsformer hur lämpligt eller enkelt det kan vara. Fasta avtal kan försvåra och förminska nyttan av att arbeta agilt men idag använder många leverantörer agil projektledning som säljargument för att driva projekt effektivare mot sina kunder. En forskningsartikel presenterad under IPMA-konferensen 2010 (Gustavsson & Rönnlund, 2010) som skrevs efter undersökningar av en evenemangsprojektledarutbildning, visar hur agil projektledning har använts med stor framgång i evenemangsprojekt. För det första är själva datumet ofta orubbligt i projekt som syftar till att skapa ett evenemang, och för det andra så förändras ofta förutsättningarna kraftigt under projektens livslängd vilket gör också dem lämpliga att drivas med agil projektledning. Förhoppningsvis kan fortsatt forskning om de agila metodernas lämplighet för olika projekttyper ge oss ytterligare kunskap på detta område. För få undersökningar är gjorda för att ännu ge en exakt bild av vilka förutsättningar som måste finnas. Vissa tendenser kan dock skönjas och det är de som har lyfts fram här.

Arbete på distans Många av de verktyg och deras användning som jag skriver om i den här boken är enkla och fysiska saker som lappar på en tavla och stående möten. Det kan ge intrycket att förutsättningen för att arbeta agilt är att finnas fysiskt på samma plats. För många projektgrupper ser inte verkligheten ut på det sättet. Grupper formeras ofta med deltagare som sitter på kontor i olika städer eller olika länder runt om i världen. Vissa projektgrupper formeras dessutom på detta sätt för att utnyttja tidsskillnaden världen över, så att projektresultatet utvecklas dygnet runt. Faktum är att antalet projekt som arbetar tillsammans

202

Kapitel 8

på distans har ökat i väldigt hög grad de senaste åren. I en årlig undersökning av företaget VersionOne (2016) fick ett stort antal företag som arbetar agilt frågan: "Har ni projekt i er verksamhet som bedrivs på distans?". Den senaste undersökningen med svar från 3 880 respondenter visade att 82 procent av företagen hade det. Tre år tidigare var siffran bara 35 procent.

Behålla lokala enheter Med projektdeltagare i Sverige, Indien och Mexiko kan alla dygnets timmar utnyttjas. Men hur gör man då om man vill arbeta agilt? Att alla exempel i boken visar på tillfällen när gruppdeltagarna finns på en och samma plats beror på att det är det effektivaste sättet att arbeta på. Många företag som har projektmedlemmar utspridda över världen försöker i första hand att skapa egna enheter, det vill säga egna projektgrupper, på varje plats. Enligt exemplet ovan skulle det innebära att projektgrupperna i Sverige, Indien och Mexiko skapar var sitt eget projektrum med en egen projektvägg och blir så effektiva som möjligt i varje grupp.

Överbygga avstånd med teknik Men om det inte är möjligt att ha lokala undergrupper inom projektet (exempelvis om bara en person sitter i Indien, två i Mexiko och ytterligare fem i Sverige) så behöver problemen med brist på fysisk närhet överbryggas med teknik. Exempelvis finns det webbaserade projektväggar som tillåter exakt det utseende som projekttavlan visar. Dessa produkter utvecklas (respektive dör bort) i hög hastighet men några av dem som funnits länge är Projectplace och Trello. Även tyngre verktyg, som stödjer ännu mer dokumentation och möjlighet att koordinera även många grupper är Jira (Atlassian) och VersionOne. För att ha stå-upp-möten kan utspridda agila grupper använda sig av grupptelefonsamtal eller digitala lösningar som Skype eller Zoom. Vissa av dessa verktyg tillåter även möjligheten att dela dokument. Under arbetstid kan chatverktyg användas för att hela tiden kunna kommunicera inom gruppen. Med alla tekniska prylar som idag finns tillhanda så finns det inga hinder för att arbeta agilt även om projektgruppens medlemmar sitter på olika platser i världen. Tekniken är en förutsättning för att agilt distansarbete kan fungera, däremot är den ingen garanti för att det kommer fungera bra.

När passar agila metoder?

203

EXEMPEL - AGIL DISTANSKOMMUNIKATION Ett litet företag med anställda i tre olika svenska städer bedrev ofta projekt på distans. När ett projekt genomförde sina stå-upp-möten via grupptelefonsamtal hade alltid moderatorn Awan en lista med alla gruppmedlemmarnas namn framför sig. På den kunde hon enkelt pricka av namn för namn, och såg på så vis till att alla kom till tals. Awan lärde sig också snabbt att alltid adressera sina frågor, eftersom det annars lätt blev så att deltagarna pratade i munnen på varandra. Projektgruppen ökade även tiden för sina dagliga stå-upp-möten till 30 minuter, då de insåg att många fler frågor behöver stämmas av när deltagarna inte satt nära varandra.

Anpassa gruppreglerna Det som gör att projektgrupper där medlemmar arbetar på distans blir effektiva, är små justeringar av processen vilka bottnar i de värderingar som agil projektledning står för. Agila projekt strävar efter ständig, tvåvägs- och bredbandskommunikation. I distansprojekt måste ofta regler upprättas för att denna obehindrade kommunikation ska kunna uppnås. Gruppregler blir alltså ännu viktigare när agila projekt drivs på distans. Utgångspunkten är att komma så nära "att sitta i samma rum" som möjligt. Det har gjort att vissa infört regeln att en projektdeltagare måsta svara på ett meddelande via chatt. De gör följande liknelse: om någon kommer in på ditt kontor och ställer en fråga skulle du naturligtvis svara på frågan. Det skulle annars bli en väldigt konstig social situation om du bara stirrade vidare in i skärmen utan att svara något. Men det är precis det du gör om du struntar i att svara på ett chattmeddelande. Av samma anledning förbjuder vissa distansprojektgrupper användande av mejl annat än för att skicka material. Deras regel är att all kommunikation ska utgöras av tvåvägskommunikation och därför godkänns endast chatt eller telefonsamtal. En kort summering: det går utmärkt att arbeta med agil projektledning på distans även om det effektivaste sättet är att sitta samlat. Det är denna arbetssituation som ska eftersträvas och förutsättningarna finns med hjälp av modern teknik. Det som ger effektivitet är däremot regler och arbetsprocess, det vill säga användandet av tekniken, inte tekniken i sig.

204

Kapitel 8

Sammanfattning Agila projekt passar i väldigt många sammanhang men lämpar sig särskilt väl när kraven är otydliga, verksamheten är i en väldigt föränderlig miljö, när målen är komplexa och när snabba resultat behövs. Agila projekt är inte så lämpliga i en miljö där förändringar i sig är för kostsamma, då genomfört projektresultat är för dyrt och svårt att förändra och när regler och avtalsformer gör att anpassningsbarhet inte innebär någon fördel. Trots att många tror att det agila arbetssättet inte lämpar sig för stora projekt finns flera exempel på lyckade tillämpningar där det viktiga är att fortfarande behålla småskaligheten genom att organisera det övergripande projektet i delprojekt. Oavsett storlek på projekt blir det inte effektivt genomfört om inte varje liten projektgrupp fortsätter vara självgående.

När passar agila metoder?

205

Lu-j.

• Maliar och checklistor

Strävan mot att varje dag förbättra sitt arbete bör naturligtvis också omfatta de dokument organisationen använder. Något som brukar vara svårt vid övergången från ett traditionellt till ett agilt arbetssätt är att hitta rätt nivå på dokumentationen. Även om den agila projektledningen strävar efter mindre formaliserad dokumentation så betyder det inte att arbetssättet är dokumentations fientligt. Det finns mycket att vinna på att dokumentera - om det görs på ett sätt

som hjälper både projektarbetet och förvaltningen av projektresultatet.

208

Kapitel 9

Dokument till stöd I det här kapitlet visas ett antal mallar och checklistor som kan vara till god hjälp för att starta en agil verksamhet. De här dokumenten, i just den här utformningen, ska inte betraktas som något absolut måste. Det viktiga är att hitta rätt nivå på dokumentationen - och det gör man genom att aktivt testa sig fram. Om man redan har en vedertagen och fungerande dokumentationsstandard bör den inte nödvändigtvis kastas ut genom fönstret eller helt och hållet ersättas. Förmodligen har ens befintliga dokument tagits fram av erfarna människor som anpassat dem till just den egna verksamheten. Däremot är det en bra ide att jämföra befintliga dokument med de mallar som presenteras här och att föra en diskussion om huruvida dokumenten saknar något, om de kanske innehåller for mycket detaljer eller om något annat kan förbättras. Att ta ansvar för att själv ta fram de bästa möjliga dokumenten för sitt projekt - det är att vara agil. I det följande presenteras fyra checklistor som kan hjälpa det agila arbetet. Samma sak gäller för de här listorna som för dokumentmallarna. Om projektet har befintliga checklistor så kan man föra en diskussion om förbättringar utifrån dem. På bokens hemsida www.sanomautbildning.se/agil finns samtliga mallar och checklistor, samt även annat presentationsmaterial för nedladdning.

Mallar och checklistor

209

Checklista - Passar agil projektledning? I det tidigare kapitlet När passar agila metoder beskrevs olika situationer för när agil projektledning fungerar bra och när det fungerar mindre väl. Man kan också få hjälp med att bedöma om det specifika projektet passar, genom att stämma av några punkter. Här kommer därför en checklista där helst svaret på alla punkter ska vara ja för att agil projektledning ska fungera så effektivt som möjligt.

Checklista - passar agil projektledning för projektet? ❑ Förstår och accepterar ledningen agil projektlednings värderingar, principer och tekniker? ❑ Om projektet har en extern leverantör: har leverantören förstått och accepterat agil projektlednings värderingar, principer och tekniker? ❑ Finns en uttalad intern mottagare till slutresultatet? ❑ Får projektbeställare/produktägare avsätta tillräcklig med tid för projektet enligt gruppens önskemål? ❑ Kommer projektgruppen att få ta egna beslut kring hur de ska lösa sina uppgifter? ❑ Är det möjligt för projektgruppen att få tillgång till användarna/ brukarna genom hela projektet? ❑ Har projektgruppen tillräcklig kompetens för att lösa sina uppgifter?

210

Kapitel 9

Checklista - Frågor att ställa sig

Frågor att ställa sig när man sätter igång med agil projektledning

❑ Passar det agila

Försvårande omständig-

arbetssättet för mitt 1 - projekt?

projektet bygger på fasta

Se kapitel 8.

heter kan vara om avtal eller om förändringar är dyra att genomföra. Varje projektgrupp bör

❑ Kan projektgruppen

idealiskt sett vara mellan

göras lagom stor och rätt

fem och nio personer och

sammansatt?

helst innehålla en bredd

Se kapitel 3.

av kompetens så att den kan slutföra det mesta av projektarbetet på egen hand utan att behöva för mycket hjälp från andra delar av organisationen. ❑ Funkar ett agilt projekt

Gynnsamma

Se kapitel 3 om

för mina leverantörer och

omständigheter är

Roller och

andra berörda?

exempelvis att projektet

Kapitel 4 om

har komplexa mål och

Intressent-

att dess omvärld är

analysen.

förändringsbenägen.

Mallar och checklistor

211

Checklista - Produktägare Här följer en checklista över vilka krav man måste kunna ställa på rollen projektbeställare eller produktägare. Om det visar sig att en individ inte kan leva upp till kraven bör man efterfråga ytterligare individer som ska fungera som kravställare. Även om denna roll måste delas mellan flera är det bäst för projektet om en individ får projektbeställarens yttersta mandat, det vill säga rätt att besluta i frågor som projektgruppen har. Det är då extra viktigt att man upprättar ett dokument för vilka områden som respektive kravställare får ställa krav på för att kunna ha tydliga gränser för beslutsfattande i projektet.

Checklista - Krav på produktägare ❑ Jag har god insikt i verksamhetens mål och förväntningar på projektet. ❑ Jag vet vilken nytta projektresultatet förväntas innebära för organisationen. ❑ Jag kan prioritera mellan olika krav utifrån nyttan av projektresultatet. ❑ Jag kan prioritera mellan olika delresultat och ge svar på när saker behöver levereras. ❑ Jag kommer att delta vid varje demonstration och granskning av sprintresultat och där ge åsikter och feedback på det genomförda arbetet. ❑ Jag kommer att delta vid varje sprintplaneringsmöte som genomförs vid start av varje ny sprint. ❑ Jag kan ställa krav på projektresultatet på detaljnivå.

212

Kapitel 9

Checklista - Komma igång med agil projektledning G Utse projektgrupp och dess roller.

0 Scrum master 0 Produktägare

0 Testare 0 Kund

Ska några roller de/as eller rotera

mellan projektdeltagare? G Klargör styrgruppens roller.

G Intern mottagare G Resursägare 0 Produktägare 0 Eventuellt scrum master

.1~

0 Projektbeställare 0 Eventuellt kund

0 Planera in workshoptillfällen för får-studie och planering. G Genomför förstudien.

0 Intressentanalys El Visionsdokument 0 Kommunikationsplan

D Beslut om projektet? 0 Utse ett projektrum. G Utse projektets referensgrupp. O Genomför planering.

0 Produktbacklogg G Färdplan G Leveransplan G Sprintplan/Sprintbacklogg

k: Q Planera in delleveranser.

D Erfarenhetsmöten 0 Demonstrationstillfällen 0 Överlämningar

G Schemalägg stå-upp-möten. I3 Skapa projektverktyg.

G Burn-down-chart G Projekttavla

G Wiki

G Definiera gruppregler.

Mallar och checklistor

213

Mall - Projektanalys I mallen för projektanalys nedan används ett exempel från det fingerade evenemanget Skiddag för hela familjen i den lilla nystartade skidanläggningen Tvetabacken.

Datum

Namn på projekt

2020-09-20

Tvetabackens "Skiddag för alla"

Leverabler

Effekter

D Tävling: startbod, målfålla

Kortsiktiga effekter

D

tidtagningsutrustning D Mässa: Nya skidmodeller (mässa) D Galamiddag: mat, dryck, dukning och scen med högtalar-

Öka intresse för skidåkning i nystartade Tvetabacken

D Varumärket: Visa kreativitet, mer än bara en skidbacke

D Nöjda besökare

utrustning

Långsiktiga effekter D Få fler skidåkare att upptäcka Tvetabacken D Ökad bokning av stugor

Övergripande aktiviteter

D Reklam/marknadsföring (tidigt) D Knyt upp nya sponsorer D Öppna förhandsbokning

214

Kapitel 9

Mall - Färdplan En färdplan (road map) ska ge en bild av hela projektet och när vilka delar av projektet kommer att genomföras. Den ska helst inte ge exakta datum utan en fingervisning om när saker kommer att ske - för att förbereda och informera utan att ge för tidiga åtaganden om tidpunkter i projektet.

Datum

Färdplan

Namn på projekt

När

Mål

Marknadsfört produkten, Kvartal 3 2020

Kvartal 4 2020

design av produkten

Tillverkat den första serien, knutit kontakt med försäljare

Säljer via alla återförsäljare, Kvartal i 2021

Kvartal 2 2021

återkoppling från 100 köpare Design av version 2, slutit avtal med ytterligare 3 återförsäljare

Hallar och checklistor

215

Mali - Övergripande leveransplan Det här ska vara en enkel lista som visar vilka garanterade datum projektet har, avseende delresultat, milstolpar, eller leveranser i projektet.

Leveransplan

Datum

Namn på projekt

Leverans

Startdatum

Slutdatum

Status

i

2020-08-01

2020-09-25

Avslutad

2

216

Kapitel

2020-10-01

2020-12-20

Pågående

Mål

Marknadsföring färdig

Första serien producerad

Mall - Detaljerad leveransplan I den detaljerade leveransplanen visas vilka inplanerade sprinter som hittills finns i projektet samt målet med varje sprint fram till respektive leverans. Även status kan anges och uppdateras löpande i projektet.

Sprint-plan

Datum

Namn på projekt

Sprint

Start

Dagar

Slut

Status

1

2020-08-01

14

2020-08-14

Avslutad

2

2020-08-15

14

2020-08-28

Avslutad

Mål

Form och layoutbeslut

Färdig annons och radioreklam Producerat TV-reklamfilm

3

2020-08-29

14

2020-09-11

Avslutad

Leverans 1 Marknadsföring färdig Utrullning i

4

2020-09-12

14

2020-09-25

Avslutad

5

2020-09-26

14

2020-10-09

Påbörjad

Första prototyp

Ej

Testprodukt med

6

2020-10 -10

14

2020-10-23

påbörjad

försöksfamiljer

reklamkanaler

Mallar och checklistor

217

Mall - Produktbacklogg En produktbacklogg visar hela listan av de krav som projektet ska tillgodose. De kan, som i detta exempel, anges som mål men kan även definieras som användarhistorier. Kolumnen "Nytta/Prio" är till för att ge ett värde kring hur viktigt målet är ur ett affärseller nyttoperspektiv. Det kan anges som en siffra där höga tal betyder högt nyttovärde. Genom att tillskriva olika värden kan man jämföra nyttan mellan olika mål eller funktioner. I en värld utan begränsningar skulle en perfekt produktbacklogg ha målet eller funktionen med högst tal överst i listan och sedan resterande mål i fallande ordning. Men ofta finns många begränsningar som gör att saker måste genomföras i en viss ordning.

Produktbacklogg

Datum

Namn på projekt

Nummer

Mål

Tid

Nytta /Prio

Kommentar

Hur demonstrera?

Källa

Skiss på färg i

och typsnitt

4 dagar

100

3 dagar

80

3 dagar

80

Visa på A4

till annons

2

Prototyp till annons

Manus till 3

218

radioreklam

Kapitel 9

Inte färdig, bara skiss

Visa på A4

Läs upp vid demo

Åsa

Anna

Projektledare berättar

I det här kapitlet återges tre intervjuer som genomförts med tre olika agila projektledare från skilda branscher. Projektledarna berättar om för- och nackdelar som de upplevt med det agila arbetssättet, hur det fungerat i var och en av projektens olika faser och vilka utmaningar och lärdomar de tyckt varit särskilt stora. Intervjupersonerna och deras organisationer är anonymiserade.

220

Kapitel 10

Sven på ett it-konsultföretag Sven arbetar som agil projektledare på ett it-konsultföretag och har precis avslutat ett projekt som pågått under ett och ett halvt års tid där man byggt en stor del av ett it-system åt en statlig myndighet. Det här var det första agila projektet som Sven arbetat i. Sven har varit scrum master i projektgruppen och ansvarat för kundkontakten gentemot myndighetens projektledare.

Vilka fördelar har agil projektledning? För mig som projektledare har de täta kontakterna, tack vare dagliga avstämningar inom gruppen fungerat oerhört bra. Det har varit viktigt att inte tumma på det dagliga mötet för att behålla insynen i alla detaljer. Det är annars risk att man som projektledare, framför allt i längre projekt, tappar lite av kontakten med detaljerna kring svårigheter och problem. Vi beslutade att begränsa mötena till 15 minuter. Det tog i början lite tid att hitta rätt kring hur djupt vi skulle gå i diskussioner men efter en första tröskel har allt fungerat bra. Ju längre projektet har gått desto kortare har mötena blivit och arbetet har fungerat bättre och bättre.

Projektledare berättar

221

Erfarenhetsmötena har gett oss väldigt mycket. Det har varit en trygghet att veta att dessa återkommande möten är en del av metodiken. Alla har känt att vi faktiskt gjort något åt problem som dykt upp - inte bara pratat om dem. Att jobba i korta sprintar som varit tre veckor långa och med avstämningar mot kunden (som sitter i en annan del av staden) har skapat en trygghet kring det projektresultat vi skapat. Vi har även involverat kundens projektledare i vår planering inför varje ny sprint och det har varit ett stort stöd. Problem och funderingar har vi rett ut direkt.

Vilka nackdelar har agil projektledning? Nackdelar upptäcker man om kunden, på olika nivåer, inte har insikt i hur det agila arbetssättet fungerar. En beställare som vill veta exakt vad de får till ett visst pris kommer inte att få alla fördelar med att arbeta agilt, upplever jag. Alternativet är naturligtiPis att vi som leverantörer garanterar ett fast pris men det tar ofta väldigt mycket kraft för diskussioner och utredning kring vad som ingår och inte. Jag förstår beställarens dilemma kring att de har en budget och vill veta exakt vad de får. Det är samtidigt viktigt för beställaren att förstå att man inte kan förutse allt och att man har en mycket bättre insikt i detaljerna ett par månader in i projektet. Den insikten hade man inte fått bara av att planera mer - den kommer av att ha fått igång tekniken och sett hur systemet beter sig.

Hur fungerar agil projektledning under förstudie- och planeringsfasen? Vi genomförde förstudiefasen som ett eget projekt som egentligen inte var agilt eftersom vi inte arbetade i korta sprintar utan genomförde det från start till slut för att få ett godkännande om att få påbörja projektet. Under planeringen riktade vi in oss på att komma i gång med projektet och fokuserade mer på teknikval än de exakta kraven. Det fick vi senare viss kritik för eftersom kunden inte hade samma agila syn på projektledning som vi hade. Vi gjorde en enkel tidsuppskattning kring projektet och var tydliga i vår kommunikation kring att detta var endast en första preliminär uppskattning. Vi tyckte åtminstone att vi var tydliga - men de människor som gav oss kritik var inköpare och beställare högre upp i organisationen.

222

Kapitel 10

De ifrågasatte oss senare i projektet eftersom våra uppskattningar inte stämde. Den direkta kontakten med den interna projektledaren var hela tiden god men eftersom anställda högre upp i myndighetens hierarki inte var insatta i det agila, uppstod en del diskussioner kring vårt tillvägagångssätt. För att projektet skulle blivit friktionsfritt skulle naturligtvis anställda högre upp i hierarkin behövt insyn och insikt i agil projektledning men det var tyvärr inget som vi kunde råda över.

Hur fungerar den agila projektledningen under genomförandefasen? Eftersom vi endast utvecklade en del av ett system som myndigheten arbetar med var vi tvungna att synkronisera oss med det övriga systemutvecklingsprojektet. Det innebar svårigheter för resursplaneringen eftersom vi inte fick "springa för fort". Vissa delar av systemet som vi var beroende av var inte alltid färdigt i tid och det gjorde att vi var tvungna att justera antalet deltagare i gruppen löpande under början av genomförandefasen. Det löste sig genom att vi hade en extern konsult till vår hjälp som vi hade ett väldigt flexibelt avtal med. Vi kunde få noll till hundra procents hjälp beroende på vilken sprint vi fanns i. Flexibiliteten som den enda personen innebar räckte som buffert för att hantera problemet. Ett par månader in i projektet hade vi däremot lyckats synkronisera vårt och kundens arbete så detta problem upphörde efter hand. Vi har hela tiden haft en produktbacklogg som både vi och kunden kunnat ändra i. Det har verkligen behövts när vi var beroende av att revidera baserat på behovet av synkronisering mellan oss och dem. Ibland har det däremot inneburit problem eftersom de som skrivit i dokumentet har haft olika sorters bakgrundskunskap. Ibland har vi varit tvungna att enas om en definition som båda parter kan acceptera även om den inte varit helt perfekt för någon av oss. Tidsuppskattningar är alltid svårt och det får man ännu större respekt för när man arbetar agilt. Uppskattningarna blir bättre och bättre löpande under projektet och det blir väldigt tydligt i projektet hur mycket tidsuppskattningarna förändras med ändringar. Ibland tror kunden att förändringar inte tar så mycket tid men när de är involverade i detaljerna ser både de och vi hur lång tid olika saker tar. Förståelsen för komplexitet och detaljer ökar för båda parter när alla har fingrarna i projektet.

Projektledare berättar

223

Hur fungerar den agila projektledningen under avslutningen? Under slutet av projektet inser vi, tyvärr, hur viktigt det är att löpande i projektet stämma av och testa så att varje del fungerar. Vi har försökt att få till det under projektet men inser ändå att vi kunde varit ännu duktigare eftersom det lätt blir en stor hög av testningar som behövs i slutet. Jag antar att det är något man måste jobba en del på för att få det riktigt bra. Något som fungerat väldigt bra har däremot varit tydligheten kring upptäckta fel och brister löpande i projektet. Både vi och kundens projektledare har hela tiden kunnat registrera och dokumentera fel som uppkommit och det har därför kunnat lösas tidigare än vi är vana vid från projekt som inte är agila. Själva avslutet har krävt att både vi och kunden haft viss flexibilitet kring vad som ska vara klart eftersom det alltid går att göra små ytterligare tillägg och justeringar av projektresultatet. Det kräver att kunden är strukturerad och inte önskar "bara lite till". Det agila arbetssättet gör ju det både lätt och möjligt så det krävs att både kunden och vi har disciplin nog att avsluta. Vi hade ett längre möte kring detta och löste avslutet genom en sista sprint där vi kom överens om att två av våra projektdeltagare blir deltagare i myndighetens förvaltningsgrupp och fortsätter hos dem så länge som de behövs.

Elin som driver evenemangsprojekt Elin har under ett år ansvarat för många korta evenemangsprojekt som en del av en utbildning för att bli evenemangsprojektledare. Projekten har handlat om allt från att genomföra en turne med seminarier för gymnasieskolor till att anordna konserter.

Vilka fördelar har agil projektledning? Framför allt tycker jag att det ger mindre magont och sömnlösa nätter! Ett av de längre projekten vi skulle genomföra, ett kortegetåg genom stadens centrum, innebar magont från första stund. Bara att se allt arbete som skulle behöva göras skulle ha skrämt vem som helst. Men genom att dela in projektet i korta sprintar visste alla i gruppen att: "Visst, det är tusentals saker som ska göras men vi behöver bara fokusera på en sorts arbete under den här sprinten".

224

Kapitel

lo

Vilka nackdelar har agil projektledning? Jag tycker inte att jag sett några nackdelar. Eller, om vi vänder på det, det agila arbetssättet tycker vi har fungerat jättebra ända fram till slutet inför själva evenemanget. Under större delen av projektet kan vi prioritera om och stryka sånt som inte är tillräckligt viktigt. Men de sista veckorna, den sista sprinten inför evenemanget, blir det ofta svårt att stryka något eftersom de sista detaljerna måste bli bra för att evenemanget ska bli bra. Istället har vi jobbat nästan dygnet runt. Jag vet att detta är att bryta lite mot det agila sättet att jobba men med ett stort viktigt evenemang i slutet av projektet måste vi oftast tumma lite på "reglerna" för att det ska bli bra.

Hur fungerar agil projektledning under förstudie- och planeringsfasen? Klockrent! Det viktigaste under förstudien tycker vi är att bestämma deadlines för projektet. Det enda datumet som är givet är naturligtvis själva evenemanget så det viktiga är att vi bestämmer när vi måste ha gjort klart material för marknadsforing, när marknadsföringen ska vara ute och så vidare.

Projektledare berättar

225

Hur fungerar den agila projektledningen under genomförandefasen? Här tycker jag att skillnaden mellan traditionell projektledning och agil projektledning blir så tydlig. Jag älskar tavlan på väggen! Allt blir genast så oerhört tydligt och enkelt att få överblick på. Vi planerar ofta hela projektet på två olika väggtavlor: en som visar hela projektet med alla sprintar, som vi kallar projektplanen och en arbetstavla för sprinten med de tre kolumnerna som visar ej påbörjat, påbörjat och klart.

Projektplan

• Mål •

•

•

•

Människor

Resurser • Erfarenheter

Tidslinje

Sprint i (3 v)

Sprint 2 (2 v)

Exempel på upplägg för en projektplan.

226

Kapitel 10

Sprint 3 (3 v)

Sprint 4 (4v)

Vi har provat många varianter av arbetstavlan beroende på hur projektet ser ut. Ibland, om vi haft väldigt olika uppgifter, har vi haft en tavla per person. Det är inte lika bra för samarbetet men gör att varje person har bra koll på sitt jobb. Ibland har vi haft en tavla per del, exempelvis en tavla för innehållet i en föreläsningsserie vi gjorde och en tavla för förberedelserna till själva turnn. Ofta har projekten innehållit så många olika sorters moment så vi har hellre använt oss av flera tavlor än en enda. Det har gjort det mycket tydligare. Stå-upp-mötena har varit guld! Vi har kanske slarvat lite när alla suttit inne på kontoret, men när vi behövt rodda runt och många varit iväg för att ordna saker har det varit oerhört bra att samlas vid en tidpunkt varje dag för att stämma av detaljer. Mötena försöker vi hålla korta även om vi inte strikt hållit dem till femton minuter. Eftersom projekten är så olika i sin intensitet beroende på vilken fas man befinner sig i, har det varierats väldigt mycket. Vi löser det genom att projektledaren får styra mötestiden. Alla får respektera om projektledaren säger: "Vi lägger ned den diskussionen, det är annat som är viktigare".

Hur fungerar den agila projektledningen under avslutningen? Evenemangsprojekt har sällan problem med sin avslutning. När evenemanget är över så är det avslutat, inget mer med det. Det sker inga egentliga överlämningar mer än att vi själva gör en ordentlig slutrapport som vi kallar ett testamente - där vi skriver ned erfarenheter och bra saker inför kommande projekt.

Projektledare berättar

227

Peter som jobbar på ett calIcenter Peter har sedan ett och ett halvt år tillbaka arbetat med agil projektledning och inslag av Lean för de kundprojekt som företaget ansvarar för. Projekten handlar ofta om att via telefon sälja produkter under en viss tid med i förväg uppsatta försäljningsmål. Men de kan även innebära telefonsupport åt företag som säljer programvara. Projekten är ofta bara några månader långa. Företaget strävar efter att få värderingarna från Lean att genomsyra arbetet.

Vilka fördelar har agil projektledning? Den största fördelen med att arbeta agilt är att det är transparent, det gör att inga problem hamnar mellan stolarna. Det ger dessutom en ökad teamkänsla där alla försöker att tillsammans hitta lösningar på problem som uppstår. Vi använder scrumtavlan (projekttavlan) med sina tre kolumner vilket gör att arbetet blir väldigt tydligt och det blir enkelt för alla att ta till sig tankarna kring det agila och Lean. De som inte redan är frälsta får genast se fördelarna och det är viktigt för att vi ska följa Leanvärderingarna. Vi

228

Kapitel lo

kan inte trycka ut förbättringsarbete, projektdeltagare måste själva vilja förbättra sin arbetssituation. Det agila sättet att arbeta ger helt enkelt förutsättningar för ett effektivare förbättringsarbete. Genom att få gruppen att samarbeta och se kraften och effekten av det kan man även ändra på inpräntade "sanningar" i verksamheten. Tidigare har vi till exempel alltid haft "sanningen" att sommaren är alldeles för svår för att man ska kunna gå med vinst i våra kundprojekt. Det är svårt att sälja via telefon på sommaren och eftersom folk kommer och går på semester blir det inte lika fokuserat arbete. Men med det agila arbetssättet i åtanke sade vi: "Tänk om vi skulle kunna vara lika effektiva under sommaren som under övriga året? Tänk om vi kunde ha samma effektiva gruppdynamik även om människor byts ut under sommarmånaderna - vad skulle det innebära?" Istället för att tänka enligt den gamla "sanningen" så arbetade vi disciplinerat i tydliga sprintar med tydliga mål och aktiviteter och gjorde förra sommaren vinst varenda sommarmånad. Det är första gången det har hänt. Det roliga med agil projektledning är att man ändras även privat eftersom man ändrar sitt tankesätt. Istället för att se misstag som att man gjorde fel så ser man dem som möjligheter till att lära sig för att göra rätt nästa gång istället.

Vilka nackdelar har agil projektledning? Jag skulle inte vilja påstå att det agila har några nackdelar i sig men det finns svårigheter i att införa det på ett bra sätt. Den största svårigheten ligger i att få gruppmedlemmarna att komma in i tankesättet. Man vill inte att en chef eller projektledare ska vara den som driver på varje förbättring utan att de enskilda anställda som sitter i telefon ska se att genom att samla gruppen och hjälpas åt så kan de själva skapa förbättringar som löser deras problem. Sättet att arbeta agilt är enkelt att lära ut och även förstå, men det som tar tid är att anamma tankesättet så att man inser att man själv måste föreslå och skapa lösningar istället för att vänta på att någon annan ska göra det. Medarbetarna måste inse att det inte handlar om att följa någon mall utan att själva skapa sig en mall som hela tiden blir bättre och bättre för varje projekt. Mycket handlar om hur man i organisationen ser på ledarskap. En organisation som inte tillåter att individer gör fel kommer inte att bli agil. Ledarskapet får aldrig handla om att skälla ut eller offentligt hänga ut någon.

Projektledare berättar

229

Hur fungerar agil projektledning under förstudie- och planeringsfasen? Nu för tiden startar våra projekt på följ ande vis: En produktionsansvarig (som ansvarar för att sätta samman en grupp inför ett nytt uppdrag) samlar alla i ett rum. Det är då gruppdeltagare, en team manager (som fungerar som scrum master) och den säljare som sålt in projektet till en kund. De träffas veckan innan projektet ska startas upp och har en workshop där projektet planeras. Eftersom många projekt har liknande utseende har vi med oss en projekttavla som visar de lappar som satt på ett tidigare liknande projekt för att jämföra med. Vi frågar oss därför vad som är specifikt med det här projektet och skriver lappar utifrån det. Eventuella frågor reds ut direkt med den ansvarige säljaren. Ingen lämnar rummet förrän det är färdigplanerat och det ger gruppen en oerhört effektiv start. Alla vet genast vad som är viktigast att börja med, vilka mål som är uppsatta och hur det ska gå till. Innan vi började arbeta på det här sättet var det ofta en team manager som gjorde den här grundplaneringen själv och då fick projekten ofta en väldigt långsam start. Frågor som hade behövt rätas ut tidigt blev ofta liggande och få projektdeltagare var engagerade eftersom de själva inte fått säga något om hur arbetet ska gå till.

Hur fungerar agil projektledning under genomförandefasen? Här vet jag att vi kan bli bättre eftersom vi inte alltid lever som vi lär. Dagliga avstämningar blir inte alltid av då alla i projektgruppen inte finns på plats samtidigt. Vi ser alltid att det får väldigt bra effekt när de genomförs men det är inte lätt att få den disciplinen i varje grupp att fungera. Sprintarna skulle dessutom kunna vara kortare, för när man väl startar upp varje ny sprint efter att ha gjort den detaljerade planeringen ser man vilken effekt det genast får. Alla eventuella konflikter eller problem i gruppen blir ofta lösta eftersom hela gruppen är delaktig och hjälps åt för att detaljplanera och hitta lösningar. Problemen med för långa sprintar uppstår både när försäljningen går bra och när det går dåligt. Går det dåligt blir gruppen ofta peppad av den nya sprintstarten. Går det bra har gruppen kanske blivit lite "mätta och nöjda" och därför inte fokuserat tillräckligt, så då blir sprintstarten också en

230

Kapitel 10

uppryckning. I vissa grupper jobbar de med tydliga veckosprintar där varje vecka har sin uppstart och avslut - och dit strävar vi med alla projekt. Vi upptäcker nämligen att gruppen hinner med så mycket mer bara genom att ha ett kortare fokus. Förut, när det var ett enda helt projekt från start till slut tyckte vi att en vecka var alldeles för kort för att hinna med särskilt mycket. Men i och med veckosprintarna upptäcker vi att en grupp kan hinna göra stora förändringar på bara några dagar.

Hur fungerar den agila projektledningen under avslutningen? Egentligen är det inte något specifikt arbete för att avsluta projekt inom vår verksamhet. Vi har helt enkelt inga speciella procedurer eller överlämningar att genomföra för att kunna slutföra projektet. Vi skulle däremot behöva bli bättre på att utvärdera och se framåt från projekt till projekt. Idag skriver vi bara en avslutsrapport till kunden men för att bli ännu mera transparent borde vi analysera, och även i den rapporten visa, vilka problem vi haft och vad vi ska göra för att bli bättre.

Sammanfattning Bland utmaningarna som de intervjuade projektledarna vittnade om fanns att kunden och andra i ledande position ibland inte har tillräcklig insikt i hur det agila arbetssättet fungerar, och svårigheten att förändra tankesättet i projektgruppen så att den blir ännu mer självgående och inte efterfrågar mallar eller färdiga lösningar. Upplevda fördelar med agil projektledning var att hela tiden ha närhet och insikt i detaljerna i projektet, att arbetssättet innebär mindre oro och sömnlösa nätter eftersom alla fokuserar på att göra klart en del i taget. Att arbeta med såväl kortsiktig som långsiktig visuell planering, framhölls också som en styrka i metoden, då det ger kontroll på projektets status. En projektledare vittnade om att han noterat hur projektgruppen utvecklades i positiv riktning genom att arbeta agilt. Detta tack vare att deltagarna känner ansvar och ser att de själva kan lösa sina problem genom att hela tiden samlas och diskutera lösningar.

Projektledare berättar

231

Litteratur Amabile, T. & Kramer, S. (2011). The Progress Principle: Using Small Wins to Ignite Joy, Engagement, and Creativity at Work. Harvard Business Review Press Ambler, Scott W. (2008), Has Agile Peaked?, Dr Dobbs Journal June 2008 Belbin, M. (1993), Management Teams, Goteborg Benefield, G. (2007), Rolling out Agile in a Large Enterprise (PDF), Scrum Foundation Dvir, D. & Lechler T. (2003), Plans are nothing, changing plans is everything: the impact of changes on project success, Science Direct Cohn, M. (2006), Agile Estimating and Planning, Prentice Hall Coplien, J. & Harrisson, N. (2006), Organizational Patterns of Agile Software Development, Prentice Hall Edmonds, E. A. (1974), A Process for the Development of Software for Nontechnical Users as an Adaptive System, General Systems XIX Evans, I. (2006), Agile adoption at British Telecom, Methods and Tools, ISSN 1661-402X, (http://www.methodsandtools.com/mt/download. php?summer06) Gareis, R. (1990), Handbook of management by projects, Manz Vienna Gustaysson, T. & Ronnlund, P. (2010), Agile project management in public events, Conference paper IPMA 2010, Turkiet Janlen, J. (2015). Toolbox for the agile coach: 96 visualization examples - how great teams visualize their work. Crisp Publishing. Jansson, T. & Ljung, L. (2004), Projektledningsmetodik, Studentlitteratur Jansson, T. & Ljung, L. (2009), Hemligheten med projektledning, TUK Forlag Katz, R. (1982). The effects of group longevity on project communication and performance. Administrative Science Quarterly, 27, 81-104 Kniberg, H & Skarin, M. (2010), Kanban and Scrum - Making the Most of Both, Lulu.com

232

Litteratur

Larman, C. (2004), Agile & iterative development - a manager's guide, Pearson Education Larman, C. & Vodde, B. (2008), Scaling Lean & Agile Development, Addison-Wesley Professional Lynn, G.S. & Reilly, R. (2002), Blockbusters. The Five Keys to Developing Great New Products, HarperCollins Poppendieck, M. & Poppendieck, T. (2003), Lean Software Development, Addison-Wesley Schwaber, K. & Beedle, M. (2001), Agile Software Development with Scrum, Prentice Hall Schwaber, K. (2004), Agile project management with Scrum, Microsoft Press Takeuchi, H. & Nonaka, I. (January-February 1986), The New New Product Development Game (PDF), Harvard Business Review Tessem, B. & Maurer, F. (2008), Job Satisfaction and Motivation in a Large Agile Team, XPU Conference Tonnquist, B. (2016), Projektledning, Sanoma Utbildning VersionOne (2015). 9th Annual State of Agile Development Survey. http://info.versionone.com/state-of-agile-development-survey-ninth.html Wenell, T. (2001), Wenell om project, Uppsala Publishing House

Litteratur

233

It

Bildförteckning Sid 12: ©Corbis / Johnér Sid 21: ©Patrik Engquist / Johnér Sid 29: ©Juan Silva / Getty Images Sid 36: ©Seth Resnick / Getty Images Sid 45: ©Jonathan Larsen / iStockphoto Sid 50: ©Radius Images / Getty Images Sid 84: ©Eric Van Den Brulle / Getty Images Sid 101: ©Hans Bjurling / Johnér Sid 125: ©Justin Sullivan / Getty Images Sid 131: ©Ashok Sinha / Getty Images Sid 144: ©Lorcan / Getty Images Sid 153: ©Jonas Ingerstedt / Johnér Sid 165: ©Per Magnus Persson / Johnér Sid 179: ©Johan Ödmann / Johnér Sid 189: ©Science & Society Picture / Getty Images Sid 193: ©Carl Roessler / Getty Images Sid 199: ©Barry Z Levine / Getty Images Sid 209: ©L Ancheles / Johnér Sid 221: ©Corbis / Johnér Sid 225: ©Ingemar Lindewall / Johnér Sid 228: ©Corbis / Johnér Baksida: ©Niklas Wegdell

Bildförteckning

235

Sakregister 12 agila principer 36-37 acceptanskriterier 122 HR 70 ...Agile 31 -ansvarsdiffusion 47 `-användarhistorier 114 arbetscykel 35 .avslut 17, 173-184 ayslutsfas 19 -beslutslogg 164 --beslutspunkt 19 -beställare 57-58, 65 -buffertsprint 106 --bum down chart 144, 213 - chefens roll 69 —Crystal Clear 31 -4claily scrum 142 —delmål 16, 99 delresultat 34, 68, 149 'Demingcykeln 33 •••• det agila manifestet 32-35 T31)7Pd--. 97 --detaljplanering 97, 118 -diskussionswebsida 166 -..distanskommunikation 204 .a-DSDM (Dynamic Systems Development Model) 123 -erfarenhetsmöte 151 .4.evenemangsprojekt 201, 224 expertfunktioner 45 '-eXtreme Programming, XP 11, 31

236

Sakregister

'aser 17 *Tasta kontrakt 191 155 f ärdplan 99, 103, 215 ...förändringsprojekt 195, 200 .gaffling 127 ,,,Gantt-schema 105 ..genomförande 17, 135 • genomförandefas 18, 223, 226, 230 ...ground rules 160 • gruppregler 160, 171 ,...,gränssnitt 46, 190

•

agil 70

.-inkrement 29 printeraktioner 32-33 Pi-intern mottagare 64, 71 intressentanalys 78, 83, 93 ...intressentkarta 161 ...iterationer 29 'ICaizen 28, 151 ,lKanban 141, 157

-klardefinition 126 4.-kommunikationsplan

78, 87-90, 94

konflikt 52 ...kontraktsforhandling 34 -krav 47, 59, 71, 112, 123, 187, 212 es kritiska linjens princip 25 ►kultur 190 .‘kundorderprojekt 51, 64, 201 4--kundsamarbete 32, 34 -Lean 26-30, 228 -.ledtid 25 leveransplan 104, 216 -leverantörer 68 ,logiska nätverk 25, 101

Sakregister

237

,....marknadsprojekt 201 meta scrum 198 --moderator 92 temål 188 -Organization Breakdown Structure, OBS 67 -parallellisering 25 "PDCA-cykeln 33 -planeringsfas 18 ...planning poker 128 -post-it-lappar 164 o-praktikaliteter 158 'Product Breakdown Structure, PBS 99-101 produktbacklogg 112, 218 produktutvecklingsprojekt 200 -..produktägare 57-62, 197, 212 -progressdiagram 147 =Project Management Institute, PMI 14 ..projektayslut 182 -projektbeställare 57 projektledare 10, 48-51, 219 projektmodell 17 projektplan 226 .projektrum 81 +projekttavla 137, 162 -.-projekttriangeln 14 r. projektvägg 161, 170 ,projektöverlämning 175 "-Rapid Application Development, RAD 30 Rational Unified Process, RUP 30, 114 ...referensgruppen 67 '-"resursägare 65 --riskhantering 154 rullande närzonsplanering 118

238

Sakregister

---Schwaber, Ken 31, 43 .6scope creap 58 Scrum 11, X, 43 , scrum master 48-56 •- scrum of scrums 199 scrum team 31 ArSIP-fragorna 142 sjaivstyre 43 .fislutrapport 182 sprint 16, 105-107 sprintgraf 144 sprintplan 107 • sprintbacklogg 118 p.statusdiagram 148 styrgrupp 63-66 —sti-upp-mote 142, 170 - Sutherland, Jeff 31 •-fitestare 46-47 • tidsuppskattning 124 —timeboxing 13 • town hall meeting 200 —Toyota Production System, TPS 26-29 • tvarkompetens 44 ---use cases 114 'vision 78, 83-87, 99 —visionsdokument 78, 84, 87 4.Wilci 166 Vork Breakdown Structure, WBS 25, 100 .workshop 76, 91 och Y-teorin 51 -°X1) (eXtreme Programming) 11, 31 4.13verlamning 17, 175 .-Overlamningsfas 18

Sakregister

239

VARFÖR BLIR så många projekt både längre och dyrare än planerat? Måste det bli dygnet-runt-arbete i slutet av projekt, och måste man som projektledare 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. I FJÄRDE UPPLAGAN presenteras utmaningarna med att skala upp det agila arbetssättet i större organisationer. Ramverket SAFe (Scaled Agile Framework) beskrivs för att visa hur planering och genomförande kan genomföras när flera team samarbetar i större projekt. Den nya upplagan innehåller dessutom uppdaterade begrepp som har spikats av den svenska versionen av scrum-guiden.

Tomas Gustavsson undervisar i projektledning vid Karlstads universitet, är certifierad scrum master och har arbetat med agila metoder sedan 2002. Hans tidigare bok utsågs till Årets projektledarbok av Svenskt Projektforum.

sa noma utbildning www.sanomautbildning.se

ISBN 978-91-523-5836-8

9 789152 358368