Agilt setup får SKATs nye inddrivelsessystem ud over stepperne

Der kan være en række fordele ved at implementere en agil struktur i større it-udviklingsprojekter. Det har man opdaget i Skatteministeriet, hvor der ifølge it-udviklingschef i Skatteministeriets Implementeringscenter for Inddrivelse (ICI), Jan Martin Smith, er en forståelse af, at agile er den mest fordelagtige måde at udvikle omfangsrige it-systemer, der er forbundet med store usikkerheder – såsom SKATs nye inddrivelsessystem.

Agile dækker over et sæt principper inden for softwareudvikling, hvor løsninger kontinuerligt udvikler sig i selvorganiserede tværfunktionelle teams. Strukturen fremmer tidlig levering, løbende forbedring, adaptiv planlægning og tilpasningsdygtighed.

Få uger før den endelige implementering af 1. release af SKATs nye inddrivelsessystem har Jan Martin Smith taget sig tid til at fortælle om ICIs erfaringer med agile, og hvordan store udviklingsorganisation kan drage nytte af tilgangen.

Kan du starte med at fortælle, hvad I ønskede at opnå ved at arbejde agilt? 

”Fra både offentlig og politisk side var det en nødvendighed at udvikle et nyt inddrivelsessystem, og en nedsat analysegruppe anbefalede, at systemet skulle udvikles på en anden måde, end tidligere. Det der med at aflevere 5.000 siders kravspecifikation til en leverandør og så vente i tre år, til de var færdige, var ikke en option. Det havde man prøvet før - og det var fejlet. Der var heller ikke tid. Tværtimod var det nødvendigt at gå til opgaven med en iterativ og agil tilgang.”

Hvad var den største gulerod?
”Den agile tilgang lod os vælge den mest optimale løsning undervejs i forløbet. Det var vigtigt, da systemet var forbundet med store usikkerheder på både scope, økonomi og i dette tilfælde lovgivning. Derudover var tidsaspektet essentielt, fordi der var behov for forholdsvist hurtigt at levere noget, der viste, at vi var på rette vej. Vi skulle bevise, at vi kunne komme ud over stepperne.”

Hvordan arbejder I?
”Grundlæggende arbejder vi i sprints af to uger med full stack teams. Alle fagligheder er altså til stede i det enkelte team - både product owners, refinement-eksperter, løsningsarkitekter, udviklere, testere osv. så teamet er i stand til at arbejde autonomt. For at det enkelte team kan fungere optimalt, releaser vi kontinuerligt, ligesom vi gerne vil regressionsteste hele tiden. Vi skaber sammenhæng mellem de forskellige udviklingsteams ved at have et udviklerværktøj, som dokumenterer hvor vi er i og imellem teams (kanban), og som indeholder vores backlog og dokumenterer vores resultater.”

Hvilke fordele giver det, at forskellige kompetencer sidder sammen på den måde?
”Med full stack teams i sprints løber alle efter samme fælles mål, og der er mulighed for i højere grad at evaluere på processen løbende, lokalisere flaskehalse og understøtte en større interaktion på tværs af kompetencer. Man udvisker nogle af de fagskel, der kan være, og det giver større viden på tværs. Ligesom det også forhindrer flaskehalse, at medarbejderne kan træde til for hinanden.”

Hvordan vil du sammenligne jeres grad af agilitet med andre setups?
”Jeg har i mange år været i en stor televirksomhed med omfangsrige it-systemer, og hvor vi arbejdede med basal Scrum (agil udviklingsmetode). Hvis jeg skal sammenligne de to, så er vi i ICI mere gennemførte i vores agilitet, og agile er i højere grad implementeret hele vejen ned gennem organisationen.”

Hvilke udfordringer har I oplevet ved implementering af agile?
”Da jeg startede for lidt over et år siden, var vi 30, nu er vi over 300, så det er gået stærkt. Vi startede fra bunden, og det har derfor været en udfordring at sikre en fælles tilgang, terminologi og rollefordeling. Nogle mener, at agile handler om, at folk selv må bestemme, hvad de laver, og at det hele er kaotisk, men det, synes jeg, er forkert. Faktisk kræver det en mere styret og struktureret proces end med vandfaldsmodellen.”

Hvordan det?
”Agilitet og udførelsen af et velfungerende iterativt forløb i sprints og subsidiært i PIs (program increment) kræver enormt meget struktur og disciplin, for cyklussen skal jo overholdes. Man kan få tilgivelse for alting, men man kan ikke udsætte et sprint.”

Hvad mener du er den største fordel ved et agilt setup?
”Agile har tilladt os at lave mange ting om undervejs, fordi vi er blevet klogere. Vi har i processen haft mulighed for kontinuerligt at stille spørgsmål ved, om vi gør det rigtige, og vi har på den baggrund løbende ændret retning efter behov. Det har været en stor fordel. Og det er der behov for, når man står med et projekt, hvor det er usikkert, præcist hvad scopet er, og hvilket fundament der bygges på.”

Hvilke wins har været de mest centrale?
”Vi har haft nogle ambitiøse delmål med relativt korte tidsrammer, og de er alle blevet overholdt. En anden gevinst ved agile er det meget tætte forhold mellem leverandøren, der kender it-systemerne, og så os som kunde, der kender forretningen. Forholdet understøtter stor vidensdeling, hvilket er en forudsætning for, at leverandøren kan lave tingene rigtigt, og at vi kan blive ved med at vedligeholde, drifte og videreudvikle systemet fremadrettet.”

Vil I introducere nye værktøjer?
”Vores udviklingsprocesser er bygget op omkring en værktøjskasse fra primært Atlassian med Jira og Confluence, og det vil vi fortsætte med. Vores nuværende udviklingspunkter handler om at understøtte samtlige centrale forretningsområder med automatiserede tests. Det er en forudsætning for at release hele tiden, og det vil vi gerne om muligt gøre dagligt. Ligeledes kan vi også blive bedre på den samlede release management-proces, blandt andet når forretningen skal adoptere og lære at bruge nye releases.”

Hvilke learnings vil I ellers tage med videre?
”Man må betragte bevægelsen mod agilitet som en rejse. Det er både en faglig og kulturel rejse uden et klart endemål. Vi startede simpelt ud, da mange ikke var særlig erfarne og har udbygget derfra. Vi introducerede helt basal Scrum, 14 dages sprint, daglige stands og en forholdsvis simpel terminologi, så alle kunne følge med. Nu er vi der, hvor vi kan tage næste store skridt med fuld implementering af SAFe i hele organisationen. Det havde vi ikke været i stand til at gøre fra dag ét. Agile er en udvikling af en organisationskultur, og det er altid en rejse.”