Det var Katrine Hald Kjeldsen, agil coach hos Bankdata, der under interviewet introducerede lagkagemetaforen for at forklare situationen i Bankdata før og efter den agile transformation.
– Tidligere leverede vi en færdig kage til kunden, hvor nogle havde lavet nøddebunden, nogle andre smørcremen, og nogle andre igen stod for glasuren. Og de, der havde ansvaret for nøddebunden, var typisk supergode til nøddebund, men vidste måske ikke så meget om, hvad de andre lag i kagen bestod af. Nu leverer vi ét lag ad gangen, hvor det er et fælles ansvar i teamet at sikre, at kunden kan lide smagen af de enkelte lag, og at lagene passer godt sammen og ender med at blive til en rigtig god kage, siger hun.
Det første team blev dannet i tredje kvartal 2015, og i dag er der omkring 120 teams, der arbejder med Scrum-basisteknikker og -roller.
Bankdata udvikler løsninger til de 11 pengeinstitutter, der i forening ejer virksomheden, så som noget lidt specielt er ejer og kunde her en og samme ting. Og det var på grund af signaler fra kunderne, at det blev besluttet at iværksætte den store transformation.
– Det blev tydeligt for os, at vi ikke kunne udvikle og justere løsningerne i den takt, som vores kunder havde brug for i en verden præget af stor omskiftelighed og krav om kort time-to-market, forklarer Berit Kuhr, underdirektør i enheden Investering & Økonomi.
Skalering ud i organisationen
Den agile transformation startede med dannelse af de enkelte Scrum-udviklingsteams, men man er i færd med at brede det agile tankesæt og tilhørende teknikker ud i hele organisationen.
– Den agile transformation omfatter hele virksomheden inklusive support, diverse stabsfunktioner samt ledelseslaget, der har deres Stand Up-møder hver fredag i ”cockpittet”. Det er faktisk ret enestående at tage en 50 år gammel projektorganisation og lave en agil transformation, der på den måde kommer hele vejen rundt, siger Berit Kuhr,
Netop udbredelsen af det agile tankesæt og arbejdet med at få flere teams til at samarbejde om samme produkt – den såkaldte skalering – er en udfordring, mange virksomheder adresserer i øjeblikket. Ifølge Katrine Hald Kjeldsen er det en balancegang.
– Koordination mellem teams og på tværs af enheder i organisationen er vigtig, og vi implementerer den nødvendige skalering, men er samtidig meget opmærksomme på, at vi ikke kommer til at overskalere. Det agile handler jo om at fjerne overhead, så det er vigtigt, at man ikke gennem skaleringen kommer til at introducere organisatorisk overhead. Så måske man bare skal lade teams koordinere direkte med andre teams, men samtidig være parat til at skalere op, hvis det er nødvendigt – og ned igen, hvis det under ændrede forudsætninger er det rigtige, siger hun.
Der findes flere rammeværk, der kan bruges som støtte for skalering af Scrum, og hos Bankdata har man valgt at anvende Nexus som inspiration.
Fordel med kortere forløb
Esben Terp Sørensen, oprindelig uddannet edb-assistent og gennem mange år udvikler, har arbejdet i Bankdata siden 2012. Han trives godt med, at man som udvikler ikke arbejder i et isoleret hjørne af løsningen.
– Jeg betragter mig egentlig som forretningsudvikler og kan lide at have direkte kontakt med de folk, der formulerer forretningsbehovene. Jeg har også brug for at vide, hvad mit arbejde bliver brugt til og vil have meget svært ved at kode ”halvfabrikata”, siger han.
Han ser det som en fordel, at udviklingsopgaverne bliver delt op i to-ugers sprints, hvilket er meget kortere forløb end tidligere.
– Tidligere delte vi også leverancerne op i delleverancer, men grundlæggende var det mere ”vandfaldsagtigt”. Det kunne være en meget stor stressfaktor at skulle sætte en voldsom stor pakke i drift, så ved at dele leverancerne op i sprints og have tæt kontakt til kunden undervejs tager man meget af risikoen og dermed stress ud af udviklingsprocessen, siger han.
Han peger dog på, at de korte sprints kan være mere velegnede til tilføjelser på eksisterende løsninger end til løsninger, hvor man starter helt fra bunden. I de tilfælde kan det være noget helt grundlæggende, der skal laves, før man overhovedet kan komme i gang med at score de såkaldte Story Points, der afspejler fremdriften i en Scrum-udviklingsproces.
Højere kvalitet
Helt overordnet ser Esben Terp Sørensen gevinsterne ved at arbejde agilt på to områder. Den Product Owner, der formulerer forretningskravene, og som løbende skal levere sparring til Scrum-teamet, risikerer ikke pludseligt at miste de ressourcer, der skal omsætte kravene til løsninger. De behøver ikke at have alt med fra starten, men kan ud fra estimaterne fra teamet beslutte sig for, hvad hvert enkelt sprint skal indeholde. Og så bliver kvaliteten af produktet højere, fordi det bedre matcher kundens krav.
– Det er en kvalitet i sig selv, at man ikke sidder og udvikler noget, som der alligevel ikke bliver brug for. Og det er en meget stor tilfredsstillelse, at man på den måde i højere grad rammer lige det, kunden har brug for.
Jesper Lund Klaris er Scrum Master i det team, som Esben Terp Sørensen arbejder i. Han ser også højere kvalitet som en af de store gevinster ved at arbejde agilt.
– Vi kan meget bedre tage højde for de ændringer, der sker markedsmæssigt, og vi kan få rettet fejl undervejs. Så der er simpelthen færre børnesygdomme i det releasede produkt. Den tætte kundekontakt undervejs er en stor fordel, og det har ikke været svært at få kunderne til at involvere sig, siger han og tilføjer, at det er kunderne, det vil sige de enkelte pengeinstitutter selv, der stiller med en Product Owner.
Også udfordringer
Jesper Lund Klaris fortæller, at det for nogle udviklere selvfølgelig også var en udfordring og krævede noget tilvænning at arbejde med Scrum.
– Der var da nogle, som syntes, at der var lige rigeligt med rutiner, møder og andre events, der skulle lægges ned over deres arbejde. Men specielt i de situationer, hvor teamet har direkte kontakt med forretningen og får input, der er anderledes end det forventede, begynder mange at se fordelen ved arbejdsmåden. Der har vi for eksempel fået meldinger som: ”Det var godt, vi ikke sad og arbejdede på det her i et helt år!”
For nogle kan det også rent personlighedsmæssigt være en udfordring med den intense kommunikation og tætte samarbejde med kolleger og kunder.
– Vi har helt sikkert oplevet hele paletten af udfordringer ved at arbejde agilt, også dem, der kan være bundet op på personligheden. Jeg tror dog på, at alle kan bliver agile – det tager bare længere tid for nogle, siger Jesper Lund Klaris.
Esben Terp Sørensen genkender udfordringen med de mange events i Scrum-verdenen.
– I starten diskuterede vi, om alle behøvede at være med til de forskellige events som refinementmøder og retrospectives, og nogle strittede da også lidt imod. Men så vendte vi den om og sagde, at det var op til folk selv, om de mødte op. Det endte jo med, at alle i teamet alligevel mødte op, fordi det er en god tilgang til tingene. Og vi oplevede så også, at når vi for eksempel skulle præsentere produktet for en kunde, så ville man gerne være der for at bakke kollegaerne op, siger han.
Ledelsesopbakning afgørende
Berit Kuhr er ikke i tvivl om, hvilke forudsætninger der er vigtige for succes med så stort et agilt transformationsprojekt.
– Det er helt afgørende, at der er ledelsesopbakning til sådan en total agil transformation, så det ikke blot er noget, som der eksperimenteres med i et hjørne af udviklingsorganisationen. Det er vigtigt, at der skabes et fælles billede af det ambitiøse mål om organisatorisk business agility og hjælp til at forstå, hvorfor det ikke kan nås med ”business-as-usual”. Ligesom det gør en kæmpe forskel, at vores Product Owners leveres af vores kunder, for de er de bedste til at beskrive kundens behov samt prioritere det, som skaber størst værdi. Derudover må man ikke undervurdere behovet for Agile Coaches både i opstarten og til løbende at holde kursen, når det eventuelt begynder at blive svært, siger hun.
Ifølge Katrine Hald Kjeldsen er arbejdet ud fra det agile tankesæt noget, man skal lære, mens man gør det.
– Man kan ikke installere et bestemt tankesæt på forhånd og så gå i gang med transformationen. Man skal gå i gang, og når man så kommer til et punkt, hvor det gør rigtigt ondt, så har man valget, om man vil fortsætte eller give op, siger hun og tilføjer:
– Det siges, at omkring 70 procent af transformationerne mislykkes. Ofte skyder man skylden på Scrum og siger, at det ikke virker, men reelt skyldes det stort set altid, at ledelsen selv ikke ønsker at blive transformeret. Jeg tror, at det er lige præcis der, at transformationen for alvor skal stå sin prøve, siger hun.
Esben Terp Sørensen mener ikke, at den enkelte udvikler bør være nervøs for at blive ”ramt” af en agil transformation.
– Jeg tror, at hvis man går til det med et åbent sind, så er der ikke noget at frygte. Når man først arbejder med det, begynder man at se fordelene, og så er det heller ikke nødvendigvis så langt fra det, man kender – der er bare et mere formaliseret rammeværk til at understøtte en udviklingsprocess, hvor man arbejder tæt sammen i et team og med kunden, siger han.
