Dynamisk IT-udvikling er et mirakel – næsten

De seneste fem år har det offentlige for alvor taget nye metoder i brug til udvikling af IT-projekter. En del er begyndt at udvikle efter såkaldte agile udviklingsprocesser.

SAMDATA Magasinet har talt med tre forskellige institutioner, der overbevisende og med klar stemme beretter om bedre og hurtigere systemudvikling. Langt fra de klassiske IT-skandaler.

”Kvaliteten er steget ganske betydeligt. Vi leverer løbende værdi til forretningen, fordi vi har hyppigere småleverancer og små-idriftssættelser, ligesom vi har langt færre produktionsfejl efter releases. Brugerne melder entydigt om højere kvalitet uden et ”men”,” siger kontorchef Willy Kofoed, der har ansvar for IT-systemerne i Styrelsen for Institutioner og Uddannelsesstøtte (SU).

SU-styrelsen havde flirtet med ”Scrum”, en form for agil udviklingsproces, i et par år, og gik for fem år siden målrettet og militant ind i agil udvikling af software.

”Vi har taget stort set al udvikling in house, hvor vi har tre teams med otte-ni medarbejdere i hver,” forklarer Willy Kofoed.

Teamet sprinter

Scrum er en udviklingsmetode, der især er velegnet til IT-systemer.

I Scrum nedbryder man opgaverne i små delopgaver, der hurtigt kan defineres, udvikles, testes og sættes i drift. Den komprimerede arbejdsperiode kaldes Sprint og varer typisk 14 dage. Udviklerne arbejder i teams på fem til ni medlemmer, der selv skal definere, udvikle, teste og implementere et Sprint.

Hver dag sikrer et kort møde, at Sprintet er på rette kurs og kan nås indenfor perioden. Hver 14. dag revurderes de enkelte Sprint i forhold til den overordnede projektplan.

Også IT-folkene hos Sundhed.dk har kastet sig over Scrum.

”Vi udvikler klart mere og bedre for færre penge, end vi gjorde før. Antallet af ændringer og fejl, vi fanger i tide, er steget radikalt,” siger Jakob Uffelmann, der tidligere var IT-chef i Sundhed.dk og nu er chef for modning og innovation samme sted.

Syddjurs Kommune har en årelang tradition for agile arbejdsprocesser i arbejdet med digitalisering. Udgangspunktet er centrale IT-funktioner inhouse, selv om forholdene er mere beskedne.

”Vi kan kun gøre det her, fordi vi har en tradition for at centralisere. Jeg har tre medarbejdere, der bruger en del af deres arbejdstid på udvikling efter Scrum-metoden. De arbejder fortrinsvis på at udvikle interne løsninger – typisk automatisering – som markedet ikke kan stille til rådighed,” siger afdelingsleder for Digitalisering, Jon Badstue Pedersen.

Agil udvikling er ikke et mirakel

Bagsiden af den hurtige og fleksible udviklingsmetode er, at man risikerer at skabe et mere komplekst patchwork af IT-komponenter og få en mere fragmenteret IT-infrastruktur.

”Der kan ligge en fare i at bygge så lille en klods som muligt. Det kan være svært at skalere, og det er ikke sikkert, at man overordnet når derhen, hvor man gerne ville,” siger Jon Badstue Pedersen.

Selvom de tre eksempler hver for sig har gode erfaringer med agil udvikling, så er det ikke sikkert, at man kan overføre Scrum-metoden til store fagsystemer. Og dermed bruge Scrum til at undgå IT-skandaler som EFI, Polsag, Amanda, Proask og DeMars.

”Vi bruger Scrum til at lave små og snævre løsninger, der ikke kan ret meget i modsætning til de store platformsløsninger. Men vi ender også op med 17 små løsninger, der kan noget forskelligt – i stedet for en platform, der kan 17 ting,” siger Jon Badstue Pedersen.
Han tilføjer:

”Når vi udvikler flere små og snævre løsninger, så får vi ganske vist bedre løsninger, men til gengæld får man en mere kompleks løsningsarkitektur.”