Head of IT WEB Kasper Fehrend og Scrum Master Brian Fischer, der begge har stor erfaring med at skabe effektive Scrum-teams, fortæller om Scrum Masterens mangesidede rolle, den vigtige Product Owner og high level-planlægning.
Scrum er nemt nok at lære. Udfordringen er at passe modellen ind i den enkelte organisations virkelighed. Selvom Saxo Bank og Scrum er et perfekt match, da metoden kan håndtere den stadige strøm af input, banken får, kræver det stadig noget benarbejde at bygge bro mellem forretningen og IT. Manden, der har det sorte bælte i netop den disciplin, er Scrum Master Brian Fischer.
Mellem forretning og team
Halvdelen af Brian Fischers tid går med at samarbejde med forretningen, planlægge, hvad der skal ske i de efterfølgende sprint, og sikre sig, at alle har en god forståelse for de opgaver, der kommer ind. Den anden halvdel går med at sikre sig, at der er godt flow af opgaver til udviklerne, og at alle forhindringer er ryddet af vejen, når nye sprint starter op.
”Man står midt imellem forretning og team – og man skal sikre, at det samspil fungerer godt,” siger Brian Fischer, der har syv års erfaring som Scrum Master.
I forhold til traditionel projektledelse skal man være meget detaljeorienteret for at begå sig som Scrum Master, da man har det endelige ansvar for, at opgaverne til næste sprint er veldefinerede. Kasper Fehrend, der kom til banken i 2008 og var en af de første til at anvende Scrum efter bogen, mener ikke, at det er en fordel at være klassisk projektleder:
”Kender man til kode og forstår dynamikken i softwareudvikling, ved man, hvor værdien i Scrum ligger, og faciliterer man den forståelse, bliver vejen fra forretningen til udviklerne meget kortere. Klassiske projektledere har det svært med Scrum, fordi Scrum Masterens vigtigste opgave grundlæggende er at overflødiggøre sig selv.”
Kasper Fehrend er ikke selv Scrum Master længere. Han prøvede hatten i et par år, men kunne mærke, at rollen ikke passede til ham. Derfor blev IT-konsulent Brian Fischer tilknyttet, og de to deles i dag om opgaverne. Kasper tager sig af personale-ledelse og den tekniske side af løsningerne, Brian håndterer det administrative og kontakten med forretningen. Kasper Fehrend har et tilsvarende samarbejde med to andre teams.
Dedikeret Product Owner
Det er en stående udfordring for næsten alle Scrum-teams at få forretningen med i form af en dedikeret Product Owner. Rollen er vigtig, for uden gode requirements risikerer man at spilde teamets tid. Da Kasper Fehrends og Brian Fischers nuværende projekt, udviklingen af TradingFloor.com, startede op for tre år siden, var det tydeligt, at mængden af opgaver ville kræve mere tid, end den forretningsansvarlige for området kunne give dem. Derfor bad de forretningen om at ansætte en dedikeret Product Owner.
”Det er mere end et fuldtidsjob at være Product Owner på TradingFloor-projektet. Vores Product Owner supporteres af to grafikere, en UX-konsulent med flere – vi har et team af folk, der udgør den samlede Product Owner-rolle,” fortæller Brian Fischer.
Også i Saxo Bank er der stor forskel på, hvor meget tid forretningen dedikerer til deres Scrum-teams. I de teams, hvor Product Owneren ikke har tid nok, må Scrum Masteren hjælpe til. Kasper Fehrend fortæller:
”En god Scrum Master formår at skubbe sin Product Owner i den rigtige retning og vise, hvordan små justeringer her og der kan give mere værdi. De to skulle gerne komplementere hinanden i forhold til, hvad der skal produceres.”
Planlægning på højt plan
Selvom man kører Scrum, er det stadig muligt lave ’high level’-planer – det fungerer bare lidt anderledes, end traditionelle projektledere er vant til. I forhold til større features kan Scrum Masteren udarbejde en relativ estimering i story points. Teamets nuværende projekt består af 30 større features. Brian Fischer kender to-tre af dem og har en idé om, hvor meget tid de kræver. Det giver ham mulighed for at vurdere tidsforbruget på andre features. Det samlede estimat leverer han på roadmap planning-niveau. Han fortæller:
”De high level-forecasts, vi laver, er nødvendige for at sikre ressourcer og commitment fra ledelsen til det projekt, vi arbejder på. Det fungerer ok, men vi ved også godt, at de planer, vi laver nu, for, hvad vi skal om tre måneder, er ændret til den tid.”
Brian Fischer vil gerne kende til forretningens road map, og hvilke features der skal leveres på længere sigt, men han er ikke interesseret i, at teamet får detailkrav ind før tid. Erfaringen viser, at det er spild af energi at specificere kravene i detaljer, før IT er klar til at udvikle.
”Vi ved, at der vil komme ændringer, hvis vi gør det for tidligt. Dette er et af elementerne i Scrum, der afviger markant fra vandfaldsprojekter: Vi accepterer, at kravene kommer i sidste øjeblik – men det fungerer godt for os,” forklarer han.
Inspect and adapt
De fleste virksomheder tilpasser Scrum til organisationens virkelighed. Mange fristes eksempelvis til at springe det retrospektive møde efter et sprint over, specielt hvis man har en projektleder-tankegang. For det er dyrt at have et helt team siddende i to timer hver 14. dag, og det kan være svært at kvalificere, hvad man får ud af det. Kasper Fehrend er dog ikke i tvivl om værdien af mødet. På det seneste retrospektive møde kom det frem, at tasks ikke var blevet nedbrudt til et lavt nok niveau.
”Det skaber spørgsmål, så vi bliver nødt til at have Product Owneren tættere på. Vi blev enige om at nedbryde tasks yderligere, og at Product Owneren fremadrettet skal sidde lige ved siden af Brian. Hvis ikke vi havde holdt det møde, var der ikke sket nogen ændring,” siger Kasper Fehrend, der lader resultaterne af møderne hænge på tavlen, så alle kan se, hvad der er gået godt, og hvad der er gået skidt. Han fortsætter:
”Et af mantraerne ved Scrum er ’inspect and adapt’. Derfor er det retrospektive møde alfa og omega, for det er her, hvor du både undersøger og tilpasser. Ikke kun til forretningen, men også til processen, der udvikles og bliver mere effektiv.”
Isoleret set har Scrum været med til at forbedre Kasper Fehrend og Brian Fischers team væsentligt de seneste par år. En af de store forbedringer er hele leverancemodellen for, hvordan kode går fra ide til live feature hurtigst muligt. Optimeringen af modellen er sket iterativt over et halvt til et helt år.
Brian Fischer forklarer:
”Det har været små skridt, sprint for sprint, hvor vi har set på, hvad der skal til for, at vi kan gøre det lidt bedre. Scrum-modellen er utrolig simpel, men de ting, vi opnår med den, giver store værdier for os som team.”
