Scrum på udebane

Denne artikel er en sammenskrivning af 3 indlæg på dansk Magisterforenings projektlederblog i februar og marts 2011

Af: Pia Petersen og Henrik Sternberg

Er I klar til at slippe kontrollen? - Scrum som projektledelsesværktøj

Lad os starte med at sige, at vi ikke ser Scrum som et vidundermiddel. Det er ikke en standardmetode, der med ét løser vores problemer med at projekter meget ofte overskrider deadlines og budgetter. Men der ligger i Scrum og lignende metoder et stort (og endnu uforløst) potentiale til at forandre organisationer og skabe bæredygtige projektmiljøer, hvor der hersker trivsel, tilfredshed og skabes overskud for alle interessenter.

Ophavsmændene til Scrum metoden (se f.eks: Ken Schwaber, Jeff Sutherland) lover uden at rødme en 8-dobling af et projektteams effektivitet, hvis blot de følger 3 simple Scrum regler: ”DONE means DONE”, ”READY means READY” and ”SELF-ORGANISING TEAMS!”.

Det er derfor ikke mærkeligt, at mange ledere har sagt ja til forsøg med Scrum projekter i deres organisation, og at Scrum indenfor IT verdenen er blevet det, vi kalder en ikonisk succes. Scrum, som vi kender det i dag, bygger bl.a. på generelle antagelser om organisering af hyper-effektive udviklingsteams, beskrevet af Nonaka og Takeutchi. Scrum metoden har vundet indpas i IT verdenen, men der er intet til hinder for, at den kan tages i anvendelse i andre typer af projekter.

Vi vil i denne artikel kigge ind i Scrum verdenen fra en projektledersynsvinkel: Hvad ligger bag ved Scrum? Hvad er erfaringerne med brug af Scrum? Og hvordan kan vi udnytte de opnåede erfaringer med brugen af Scrum i IT projekter, udenfor IT verdenen?

Man kan se og forklare Scrum og elementerne i Scrum fra mange perspektiver, og dette afspejles også i de mange forklaringer, der findes på hvad Scrum er. Et perspektiv er ”at Scrum er en samling af praktikker, der genererer selvorganisering og simultant reducerer risici og usikkerhed” et andet er ”at Scrum er en deltager-orienteret empirisk proces, der understøtter, at alle deltageres viden og erfaring hele tiden er i fokus og at beslutninger bedst træffes med udgangspunkt i de konstante forandringer, der er et vilkår i vores verden” et tredje er ”at Scrum er et sæt af (team/samarbejds)mønstre”.

Det tredje syn vil vi gerne udfolde lidt, da det er vores oplevelse, med de erfaringer vi kender i dag, at det er værd at sætte lidt fokus her. Mønstrene er i sig selv uafhængige, og angiver en bestemt teknik eller praktik. Eksempler på mønstre kan være 1) daglige, korte stå-op-møder (såkaldte Daily SCRUMS) , 2)brug af visuel ledelse, (f.eks. Scrum boards) og 3)selvorganiserende teams. Mønstrene er hver især glimrende, og mange har gode erfaringer med disse. Men den egentlige kraft til hyper-produktivitet kommer fra den måde man sammensætter mønstrene på. (se bl.a. : Coplien, J., Organisational Patterns, der siger at Scrum består af i hvert fald 33 mønstre). Så selvom der er mange gode erfaringer, der understøtter, at Scrum møder og Scrum tavler er gode, så betyder det ikke, at de to enkeltteknikker udgør en kraftfuldt Scrum implementering og markant forbedrer effektiviteten.

En af de praktikker eller mønstre, som Sutherland peger på er ”selvorganiserende team”. Det er en praktik, som i de fleste Scrum implementeringer bliver udeladt. I Scrum er der som udgangspunkt ingen projektleder, hvilket jo godt kan være svært at forholde sig til som projektleder, for nogle af os ligefrem angstprovokerende, for ”hvem skal så sørge for at projektet bliver færdigt til tiden? og Hvem er det, der har det store overblik?” bare for at nævne nogle af de udsagn vi hører.

Projektledelsen er overladt til teamet selv, med en Scrum MASTER(et mønster), der hjælper teamet med at fjerne forhindringer. Det stiller naturligvis store krav til teamets organisering. Årsagen til at denne praktik ofte bliver udeladt er, for os at se, overvejende kulturelt betinget. Det er den almindelige opfattelse i vores del af verden, at (projekt)ledelse bl.a. handler om, at en leder skal have overblik og ansvar, skal kunne fortage analyser og lave diagnoser for projektets tilstand, sammensætte projektholdet og uddelegere opgaver til hver enkelt.

Men kraften i Scrum kommer bl.a. af en erkendelse af, at projektledelse i langt højere grad er et spørgsmål om synliggørelse. At skabe gennemsigtighed i projekter og deres omgivelser, så hver enkelt deltager kan påtage sig sit naturlige ansvar og i forening med resten af teamet træffe beslutninger om, hvem der skal gøre hvad på baggrund af en fælles viden om projektets visioner, betingelser og tilstand. Det helt fundamentale mønster i mønstersproget Scrum hedder ”TILLID”. Et godt spørgsmål vi kan stille os selv som projektledere er ”Er jeg parat til at slippe kontrollen?” For uden det mod, så er der formentlig ingen, der kan mønstre markante effektivitetsforbedringer, selvom de laver synlig ledelse og holder daglige møder.

Hvad blev der af projektlederen – er du klar til en ny ledelseskultur?

Når man dykker ned i karakteristika ved et Scrum projekt, er noget af det første man lægger mærke til som projektleder, at der ingen projektleder er. På den anden side ER der faktisk mange, der IKKE lægger mærke til det i praksis, og går ud fra at ScrumMaster bare er et navneskift og et par ekstra coaching opgaver. Men Scrum mener faktisk, at der IKKE skal være en projektleder tilknyttet et Scrum projekt. ScrumMaster rollen er en helt ny rolle med andre og nye opgaver og ansvarsområder.

Projektlederen som klassisk rolle anses af Scrum for at være en forhindring for at projektet kan blive effektivt. Scrum ønsker ikke en projektleder, der uddelegerer opgaver, laver risikolister og forhandler ressourcer og scope med linieledelsen/styregruppen. Den type projektledelse bliver i et Scrum projekt en integreret del af projektteamets arbejde og ansvar. Man kan sige at Scrum på en måde overflødiggør den klassiske projektleder men bestemt ikke projektledelse som disciplin. Denne ledelse udøves af teamet.

Målet – og en af de vigtigste, om ikke den vigtigste pointe – er det selvorganiserende team for at fremme effektivitet. Ingen i teamet har specifikke roller udover Scrum Master og Product Owner. Det er Product Owner, der har ansvar for, at den overordnede vision og de krav projektet skal indfri bliver beskrevet og prioriteret. Det er teamets opgave og ansvar at udvælge, estimere, nedbryde, prioritere, fordele og udføre opgaver fra den opgaveliste, som Product Owner vedligeholder. Dermed opnår teamet større og større fortrolighed med sig selv og sin formåen. I korte afgrænsede tidsforløb kaldet sprints (á f.eks. 2-4 uger) forhandles mål, delmål og indhold mellem teamet og Product Owner for det, der skal arbejdes med i det kommende sprint og resultaterne måles og vurderes efter hvert sprint i forhold til den overordnede vision.

Tanken er, at selvorganiserende teams, der har ansvar for sine egne fælles beslutninger i langt højere grad end traditionelle grupper er i stand til at håndtere den enorme kompleksitet, der kendetegner mange moderne projekter og at det at have dette ansvar er stærkt motiverende. Fastholdelse af specifikke roller og ansvar begrænser teamets evne til at udnytte hinandens kompetencer og skabe leverancer, der er koordinerede og uden overflødigt indhold.

En projektleder som rolle er således overflødig, hvorimod projektledelse bliver en tydeligt integreret del af projektarbejdet. Men hvad er der så tilbage til Scrum Masteren?

Pearce(1999) arbejder videre med Wittgensteins tanker om ”Kommunikation og situationer imellem mennesker forstået som sprogspil” og arbejder her med begrebet GameMaster. En GameMaster har en overordnet forståelse for, hvornår spillet(projektetarbejdet) behøver en ændring og hvordan man skaber nye variationer og nye spil. Man kan sige at ScrumMasteren er Gamemaster og teammedlemmerne er gameplayers. Man kan også sige at ScrumMasteren er en slags systemisk proceskonsulent der 1)har til hensigt at skabe fremtiden, 2) hjælper mennesker med at lære, 3)involverer alle og 4) skaber gradvise forbedringer ved bl.a. at tænke i samskabelse, relationer, kontekst og cirkularitet og dermed gør det nemt for teamet at gøre det der skal til for at opfylde visionen for deres arbejde.

Scrum Masteren har vigtige opgaver: At beskytte teamet, at fjerne forhindringer og at coache teamet. De 2 førstnævnte opgaver handler om at sikre at teamet i løbet af de enkelte sprints får arbejdsro fra velmenende kunder, der ”lige” vil ændre kravene, sælgere der ”lige” vil have flere og andre krav med, og linieledere, der vil omrokere ”ressourcerne” til mere pressende opgaver. Det er opgaver, der kræver politisk tæft, for der følger ikke automatisk kompetence med. Den sidstnævnte opgave handler om projektledelse i en helt ny dimension: teamledelse gennem coaching.

For at det kan lade sig gøre at varetage sit ansvar som ScrumMaster kræves en høj grad af gennemsigtighed hvad angår fælles viden om betingelser, vision og tilstand. I starten af et sprint vil det være Scrummasteren, der sørger for at kontrakten for det kommende sprint er klar: at målet med processen, arbejdsform og tid er forhandlet på plads. Undervejs afholdes ’Daily Scrum’ møder. Korte møder, hvor der spørges ind til forhold som : er vi på rette kurs? Skal vi justere emner, arbejdsform, tempo? Hvem gør hvad hvornår? Er der nogle forhindringer, jeg skal få fjernet? Disse møder sikrer at beslutninger træffes på baggrund af nyeste viden. I slutningen af hvert sprint afholdes et retrospective, hvor der spørges ind til konklusioner på arbejdet, hvilke arbejdsformer skal tages med videre frem, hvad skal justeres etc. I disse kontekster kan vi se ScrumMasteren som facilitator.

Erfaringsmæssigt er det svært at komme til den erkendelse og handling at aflive den klassiske projektlederrolle. Det er formentligt kulturelt betinget: styregrupper/projektdeltagere kan have et ønske om at kunne placere ansvar, ligesom projektledere kan have ønske om at bevare den prestige og autoritet, der kan følge med jobbet. Det er fuldt forståeligt, men ikke desto mindre en barriere for effektivitetsforøgelser ifølge Scrum.

Dit team har brug for dig!

Et af de vigtigste og mest kraftfulde principper bag Scrum, er princippet om selvorganiserende teams. Tanken er, at teamet ved selv at indgå forpligtende aftaler med ”kunden”- repræsenteret af en ”product owner” - for en overskuelig tidshorisont, i langt højere grad end via en projektleder, er i stand til at håndtere den store kompleksitet, der findes i de fleste moderne projekter.

Men udover kraftfuldt er princippet erfaringsmæssigt også vanskeligt at implementere. Vi har skrevet om de kulturmæssige forhindringer, og vil her pege på mere konkrete udfordringer, nemlig organiseringen og understøttelsen af de selvorganiserende teams. Et team bliver ikke selvorganiserende af at blive kaldt et Scrum team. Ligesom en projektleder ikke bliver team coach af at blive kaldt Scrum master. Det ligger i Scrum masterrollen, at han/hun er ”beskytter” af teamet, og dermed ikke har direkte handlemuligheder i forhold til opgavefordeling eller arbejdets tilrettelæggelse. Derimod skal der iscenesættes en læreproces, der kan føre til, at gruppen går fra at være en gruppe til at blive et effektivt team, der af sig selv behersker projektledelsen og Scrum masteren må spille en særdeles vigtig rolle i denne udviklingsproces i rollen som team-leder. Det første en teamleder må gøre er at erkende, at teamledelse handler om at skabe de bedst mulige betingelser for, at teamet kan udfolde sine kompetencer og (for)blive effektivt og højtydende.

En væsentlig betingelse for succes er, at forståelsen af ledelsesansvaret er klart. For en gruppe, der endnu ikke er blevet et team, kan en tydeliggørelse af spillereglerne være afgørende. Eksempler på spilleregler er f.eks. at mål og visioner for projektet skal være bredt og fælles forankret, projektets rammer og betingelser i organisationen skal accepteres og respekteres, og projektets samlede ansvars- og beslutningskompetence skal indarbejdes i teamets arbejdsform. Efterhånden som gruppen først etableres som team og efterhånden bliver funktionelt ændres Scrum masterens rolle fra meget ledelse og lidt coaching hen imod mere og mere coaching af det selvorganiserende team.

Som teamleder er man forankret i moderne motivationsteori. Et funktionelt eller effektivt team får en ikke ringe del af sit brændstof fra den motivation, der ligger i at være selvorganiserende. Det er i høj grad de indrestyrede motivationsfaktorer, der gør teams højtydende. Faktorer, der understøtter vores behov for at bidrage til noget, der er større end os selv, at have indflydelse på eget arbejde og at øge vores kompetencer på områder, der giver mening. (se f.eks Dan Pink på Ted-talk) Ydrestyrede motivationsfaktorer som individuel præmiering, ros og bonusordninger virker kun præstationsfremmende ved aldeles rutineprægede jobfunktioner. Scrum bygger på indrestyring.

Scrum som metode er opbygget meget enkelt, med få roller, få produkter og få principper. I IT branchen er Scrum blevet meget populær, og mange projekter har taget den til sig –især delvist, og accepterer at den delvise implementering ikke giver overbevisende effektivitetsforbedringer. Der ligger et umådeligt stort potentiale for effektivisering af projektarbejde gemt i Scrums enkle, men komplekse struktur, der kræver en genfortolkning af projektledelse som disciplin, fra command-and-control ledelse til ledelse af selvorganiserende teams.

Så, lad os lige til slut kaste et blik på, hvordan vi bedst udnytter erfaringerne fra IT-verden, når vi gerne vil anvende Scrum på udebane:

Tag tanken om selvorganiserende teams alvorlig og opløs projektlederrollen
Sørg for at forankre forandringen opad og nedad i organisationen. At indføre Scrum som projektledelsesmodel kæver en ændret organisering af kommunikationen mellem projektet og forretningen om visioner og krav, mellem Styregruppe/BusinessCase manager om risici og værdiskabelse og ikke mindst en ændret organisering af kommunikationen internt i teamet. Som projektleder kan du være den, der starter dialogen og peger på forbedringsmuligheder.
Sørg for, at der igangsættes uddannelse hele vejen rundt – fra linieledelse over styregruppe til teamleder som teamdeltager. Uddannelse i betydningen af metodens bagvedliggende filosofi som i praktisk træning i praktikker og teknikker. Et godt princip er, at uddannelse sker bedst i projekterne og ikke alene på kurser.
Sørg for at organisationen understøtter dig som projektleder i bevægelsen væk fra den klassiske projektlederrolle hen imod teamlederrollen. Vær udfarende og gør opmærksom på, hvad du har brug for af kompetenceudvikling for at kunne løfte din nye rolle.
Tænk det, at gå fra projektleder til teamleder, som en dynamisk proces over tid. Det er en bevægelse, hvor den gruppe, der skal gå fra at være en gruppe til at være et team, kræver forskellig grad af støtte og styring alt afhængig af gruppens modenhed og kompetence. Få dig gerne en mentor til hjælp.
Gør dig klar til at gøre op med individuelle belønningssystemer, hvis du vil opnå hyper-effektive teams.
Hent folk udefra, der har erfaring med metodeudvikling med Scrum.

Scrum implementering er en forandringsproces, der kræver åben vilje. Det kræver omtanke, omhu og omsorg at sørge for, at forandringen er bæredygtig og værdifuld for organisationen. Og på ægte Scrum’sk: Lad være med at sætte dig bag skrivebordet og udarbejd en stor detaljeret plan for din Scrum implementering – Skab i stedet gradvise forbedringer, hvor du hele tiden lærer nyt og tilretter din proces efter hvad du lærer.

”Go home and experiment” og rigtig god fornøjelse.