Projekters foranderlige verden – en indføring i scrum
Strengt taget findes der to strategier til at håndtere usikkerhed i projekter. Enten kan man forsøge så vidt muligt at eliminere usikkerheden igennem planlægning, eller man kan gøre sig tilstrækkelig åben for usikkerheden og lære at håndtere den bedst muligt. Udfordringen med den første strategi er, at den negligerer usikkerheden i konteksten eller omverdenen, som er et grundvilkår i projekter. Projekter kan se perfekte ud på papiret, men hvis omverdenen undervejs i processen taber oplevelsen af mening i projektet, er det et fejlet projekt (Kreiner og Christensen, 1996). Sætningen at operationen var en succes, men patienten døde, understreger pointen om at succesfulde projekter ikke nødvendigvis er dem, der udføres korrekt med rationelle metoder. Et succesfuldt projekt er et projekt, der formår at skabe værdi, og som opleves som meningsfuldt og brugbart for omverdenen og interessenter. Udfordringen med strategi nummer to: at være tilstrækkelig åben for usikkerheden og lære at håndtere den bedst muligt har tidligere været, at der ikke fandtes metoder eller tilgange, som var tilstrækkelig elegante (Kreiner og Christensen, 1996). Det var indtil agil tænkning og dynamisk projektledelse så dagens lys. Denne artikel handler netop om dynamisk projektledelse. Inden jeg præsenterer scrum som et bud på en arbejdsmetode til dynamisk projektledelse, vil jeg imidlertid tydeliggøre behovet for nytænkning yderligere.
Wicked problems
Agil tænkning og praksis er et fint bud på, hvordan man kan løse problemer eller projekter, som ikke lader sig indfange eller løses på konventionel vis. Problemer af den art får på engelsk benævnelsen ”wicked problems”. Det vil sige problemer, der ikke kan defineres klart. I modsætning til ”wicked problems” står det, man kan kalde ”tæmmede” problemer. Her menes problemer, man i princippet kan definere. Med tæmmede problemer er det oplagt at anvende rationelle metoder fra den klassiske værktøjskasse (Rittel og Webber, 1973). Forsøger man derimod at løse ”wicked problems” med rationelle metoder, kan projektet tit ende kaotisk. Mange projektorganisationer har stadigvæk en klippefast tro på, at den rationelle tilgang vil beskytte mod usikkerhed og kaos, men desværre udebliver den ønskede effekt som oftest med forfejlede projekter til følge. Et væsentligt argument der taler for at favne agil tænkning, er det, man kalder planlægningsparadokset (se figur 1 øverst, Christensen og Kreiner, 1996). I sin essens handler paradokset om, at mange og måske især vigtige beslutninger tages ved projektstart, hvilket unægtelig har stor betydning for projektets videre liv. Problemet er, at projektorganisationen tit ikke har tilstrækkelig viden og information til at træffe særlig kvalificerede beslutninger ved projektstart. Der træffes således vigtige beslutninger på et meget spinkelt vidensgrundlag, og det kan have uheldige konsekvenser i projektet. Senere i projektforløbet betyder beslutningerne mindre og mindre, da færre beslutninger skal tages, og fordi man bedre ved, hvad projektet skal levere. Der ligger således et kæmpe læringspotentiale i at holde igen med at træffe alt for mange vigtige beslutninger indtil senere i projektforløbet, hvor mere viden og information er tilgængelig. Med disse indledende perspektiver kan man sige, at organisationer og projektledere står over for ganske vigtige overvejelser både i forhold til metodevalg, og hvordan et projekt grundlæggende kan gribes an. Projektet kan tilmed ændre karakter undervejs i forløbet, således at der i ét og samme projekt på forskellige tidspunkter er brug for værktøjer fra forskellige tilgange og grundtænkninger. At ændre metoder, tilgang og kurs er slet ikke en nem opgave og kan blive en temmelig langsommelig affære, hvis projektet har mange interessenter, som skal koordinere deres handlinger i forhold til projektets skiftende logikker. At arbejde med projektarbejde kalder således på, at projektorganisationen er god til at håndtere en evigt foranderlig verden, hvor det handler om at være hurtig og metodisk fleksibel, således at det er nemmere at improvisere og bidrage med ukonventionelle løsninger, hvis det skulle blive nødvendigt. ‘Hurtig’, ‘fleksibel’ og ‘ukonventionel’ er præcis de nøgleord, der har været afgørende for den bølge af succes, som agil eller dynamisk projektledelse har redet på de sidste to årtier.
Scrum udfoldet
Én af de agile metoder hedder scrum. Den metode skal vi se udfoldet nu. Scrum er et begreb hentet fra sportsgrenen rugby og henviser til den måde spillet sættes i gang, hvor holdet samles og står skulder ved skulder på banen i en klynge – eller i et scrum som det hedder. Derefter går teamet samlet ind i opgaven for at vinde bolden og flytte den frem på banen i et såkaldt ‘sprint’. Japanerne Nonaka og Takeuchi, der er kendte forskere inden for organisationsudvikling, strategi og marketing var de første, som sidst i 80-erne fik øje på parallellerne imellem produktudvikling i flere store organisationer og bevægelsen på rugbybanen imellem ‘scrum’ og ‘sprint’. Den afgørende forskel på grundtænkningen i scrum og den klassiske tilgang skal ses i den måde, man tænker om projektforløbet. I klassisk projektarbejde ligger styrken i at dele projektet op i adskilte sekventielle faser, hvor en fase går i gang, når den forrige fase slutter. Tilgangen kaldes ofte vandfaldsmodellen og henviser til, at faser logisk set følger hinanden som vandet i et vandfald, og at man i princippet ikke kan ”gå imod strømmen” og genbesøge eller korrigere i tidligere faser. Tilgangen er perfekt i veldefinerede projekter, som skal løse et tæmmet problem, hvor leverancen er relativt klar, og hvor det er indlysende, hvilken metodisk tilgang projektet kalder på. Hos NASA så Nonaka og Takeuchi, at de arbejdede med produktudvikling på den traditionelle sekventielle faseopdelte måde, hvor et specialistteam færdiggør opgaven i én fase, hvorefter et andet specialistteam overtager opgaven og tager projektet ind i næste fase. Faseopdelingen minder lidt om et stafetløb, hvor pinden overleveres fra en løber til den næste. Til sammenligning lægger scrum op til, at det tværfaglige team er samlet hele tiden og står distancen sammen. Bevægelsen fra en klassisk til en agil måde at tænke og arbejde med projekter på ligger altså i opløsningen af logikken om, at man afslutter en fase inden næste fase påbegyndes. I stedet for overlapper eller smelter alle faserne sammen i scrum, og de klassiske faser foranalyse, design, gennemførelse og evaluering foregår samtidigt. Med andre ord er projektteamet samlet igennem hele forløbet, og bolden kan kastes frem og tilbage. I bund og grund betyder det, at man i scrum sagtens kan arbejde med at designe nye ting sent i projektforløbet, hvis det er dét, som skaber værdi for kunden. Projektplanen bliver således ikke det vigtigste referencepunkt, men snarere fokuseres kontinuerligt på mantraspørgsmålet: Hvad skaber værdi for kunden? Nonaka og Takeuchi observerede, at man i FujiXerox og i endnu højere grad hos Canon og Honda arbejdede på denne facon, hvor flere faser overlapper hinanden. Fordelen ved skiftet fra den lineære fasetilgang til en mere integreret tilgang er, at mange sæt forskellige specialistøjne har et samtidigt blik på projektet. Det skaber en mulighed for mere pingpong og improvisation i temaet, fordi alle relevante aktører og fagligheder er til stede og gør, at det ikke nødvendigvis er den første og bedste løsning, der vælges. Effekten af det er hurtighed og fleksibilitet i projektarbejdet, og man kunne endda argumentere for, at processen understøtter kontinuerlig nytænkning og innovation i det daglige arbejde.
To roller
I midten af 90-erne tog amerikanerne Sutherland og Swaber japanernes idé om scrum ind i udviklingen og ledelsen af IT-projekter. Senere er scrum også begyndt at blive brugt som generel tilgang til projektarbejde og udviklingsarbejde inden for en lang række brancher. Med ‘sprint’ og ‘scrum’ lægges der op til et trinvist projektforløb, hvor kontinuerlig dialog og feedbackprocesser med interessenter skaber grundlag for hele tiden at få respons på, om projektet er meningsfuldt og opfylder kundens behov. I scrum er den klassiske projektlederrolle død og erstattet af to andre roller hhv. en product owner (produktejer) og en scrum master. Mens produktejeren har fokus på kundens behov og har forretningsblikket i forhold til projektet og markedet, skal scrum masteren lede og have fokus på projektteamet. Man kan sige at produktejeren agerer udenrigsminister i forhold til projektet, mens scrum masteren er indenrigsministeren. Produktejerrollen kan i øvrigt sagtens besættes af kunden selv. Den sidste funktion er scrum teamet, som typisk består af syv plus/minus to deltagere. De vigtigste karakteristika i teamet er, at de er selvorganiserende, og som en væsentlig motivationsfaktor selv vælger deres arbejdsopgaver ud fra den arbejdsliste som produktejeren har udfærdiget.
Backloggen
I et scrum-projekt samles input fra interessenter og evt. slutbrugere af projektets leverancer til en såkaldt backlog, som er en liste over de ønsker, kunden har, og som på nogle måder ligner den klassiske kravspecifikation. Den afgørende forskel fra kravspecifikationen er, at backloggen genbesøges hver måned og kan ændres undervejs i projektet. Hver måned har produktejeren prioriteret, hvilke opgaver der er vigtige for kunden og meddeler dette til scrum masteren, som bringer den prioriterede backlog til teamet. En nem og intuitiv måde at prioritere opgaverne er at anvende trafiklys som metafor med farverne grøn, gul og rød. Grøn er opgaver med topprioritet, som skal køre først, gul er opgaver, der kan vente, og rød er opgaver, der stoppes og parkeres for en stund eller evt. stryges af backloggen. Teamet skal nu sammen med scrum master planlægge, hvad de vil nå fra den prioriterede backlog på 2-4 uger, hvilket typisk er den anbefalede længde på et sprint i IT-verdenen. I andre brancher giver det måske mening med andre sprint-længder. Til at estimere opgavernes kompleksitet eller tidsforbrug anvendes metoden ‘planning poker’, der er et sæt spillekort med forskellige talangivelser på. På et planlægningsmøde inviteres teamet til at byde ind på, hvor kompleks en opgave er angivet i værdien story points. Det allerførste teamet gør, er fælles at fastsætte værdien af tallene på kortene. 1 svarer måske til en meget nem opgave, mens 100 er en yderst kompleks opgave. Det vigtigste er, at alle ved, hvad tallene refererer til, således at alle kan byde kvalificeret ind, når nye opgaver fra backloggen skal estimeres. Planning poker foregår helt praktisk således, at scrum masteren tager den første grønne opgave og spørger teamet, hvad de vurderer opgaven til at være, hvorefter alle teammedlemmer melder ud samtidigt med hver deres kort. Derefter spørger scrum masteren typisk ind til de højeste og de laveste værdier og hører teammedlemmerne begrunde deres estimat. Et lavt estimat kan indikere, at én i teamet er spidskompetent på præcis det felt, og et højt estimat kan indikere, at man ikke kender feltet godt nok. Et lavt kan også betyde, at man blot mangler idéer til at løse opgaven, mens et højt kan betyde, at man har idéer til, hvordan teamet sammen kan løse opgaven. Efter første runde melder alle teammedlemmerne ud på ny, da tanken er, at snakken om den første udmelding bevæger teamets tankegang og gør alle klogere på, hvad det er for en opgave, teamet står overfor. På den måde ændrer deltagerne måske estimat efter at have hørt de andres estimater og begrundelser. I anden runde ser man, om estimaterne har ændret sig, og scrum masteren spørger endnu engang ind til begrundelser for teamets forskellige udmeldinger. Planning poker kører typisk i to til tre omgange per opgave, og i sidste omgang lægges alle tal sammen og divideres med antallet af teammedlemmer, hvilket giver opgavens estimat enten som grad af kompleksitet som kan omregnes til tidsforbrug.
Sprint
Efter planlægningsmødet starter sprintet, og det betyder, at teamet får fred til at arbejde i en måned med de opgaver, der er overført fra backloggen til månedens sprintlog. I scrum taler man om, at én af scrum masterens fornemste opgaver er at skærme teamet for diverse forstyrrelser, således at de kan få arbejdsro uden afbrydelser. Dette kan måske give rigtig god mening i IT-udvikling, men er et aspekt ved scrum, der måske skal tilpasses i andre faglige miljøer. Ét af de centrale elementer i scrum-tilgangen er selve scrum-møderne, som er daglige møder à 15 minutter. Disse holdes stående ligesom rugbyspillerne gør det på banen og ligger typisk om morgenen eller sent på formiddagen, hvor scrum masteren hver dag stiller alle i teamet de samme tre spørgsmål: 1: Hvad nåede du i går? 2: Hvad skal du nå i dag, og 3: hvilke forhindringer er der? Forhindringerne logges, og det er scrum masterens ansvar at sørge for, at de bliver fjernet. Scrum-mødet er per definition ikke et langt møde. Derfor afholdes det også stående, og scrum masterens opgave og udfordring er at holde mødet på de 15 minutter. Det kan kræve noget træning i starten at holde denne disciplin, og scrum masteren må måske stoppe spirende diskussioner og dialog, men disse bør så vidt muligt stoppes og parkeres til andre typer møder, da diskussion, dialog, udvikling etc. hører hjemme i andre møder end scrum-mødet. Mødet er således et dagligt statusmøde på projektet og intet andet. Fordelen ved den rene version af scrum er tit, at teams bliver bedre til at tildele passende overskrifter og ditto spilleregler til deres forskellige møder.
Evaluér arbejdet
Efter en måneds arbejde holdes der et sprint review, hvor scrum master og scrum team inviterer produktejer og eventuelt andre interessenter ind til at se en demonstration af månedens arbejde. I scrum er det afgørende, at der foreligger en leverance hver eneste måned, som kan demonstreres og give projektets interessenter en idé om, hvad der er i gang. I IT-branchen er leverancen typisk en form for funktionsdygtigt software, og i andre typer projekter kan det fx være protypiske produkter eller servicer. Sprint review giver anledning til, at produktejer og interessenter kan omprioritere backloggen og overveje, om projektet skal justeres og ændres, hvis præsentationen af månedens arbejde har givet anledning til nye og bedre muligheder og løsninger. Reviewet lægger således ikke op til en evaluering af, om scrum teamet er lykkedes eller ikke i det forgangne sprint, men snarere at produktejer og interessenter skal komme med indspark og idéer til forbedring, som kan medfølge en ændring af backloggen. Mens der i sprint review ene og alene er fokus på produktet, er der et andet møde, hvor fokus ene og alene er på teamets arbejdsprocesser. Dette møde kaldes sprint retrospective. Her kigger teamet tilbage på månedens arbejde og reflekterer over, hvordan de er blevet klogere på hinanden og selve arbejdsprocessen.