Professor om forsinket gælds-it: Ufornuftigt kun at benytte agil udvikling

Det er en dårlig idé at forlade sig på agil udvikling til større it-systemer såsom det forsinkede gældsinddrivelsessystem PSRM, mener professor emeritus Søren Lauesen.

Det var en fejl af Skatteforvaltningen at udvikle det nye it-system til inddrivelse af gæld, PSRM, udelukkende med en agil metode.

Det mener professor emeritus Søren Lauesen, der i mere end 20 år har beskæftiget sig med store it-projekter i det offentlige og kravspecifikation af dem.

»Det var ufornuftigt udelukkende at benytte sig af agil udvikling til det nye gældsinddrivelsessystem. Systemet er et eksempel på, at agil udvikling kan være direkte skadeligt i større projekter,« siger Søren Lauesen til Version2.

Ifølge Søren Lauesen har udviklingsmetoden ført til, at Skatteforvaltningen ikke har fået defineret ordentligt, hvad systemet skal kunne, hvem der skal bruge systemet og hvornår.

Han peger desuden på, at valget af udviklingsmetode også har bevirket, at der ikke har været opmærksomhed på det helt store problem: hvordan man tilslutter de 800 fordringshaveres forskellige it-systemer.

Fordringshavere er eksempelvis politi og kommuner, der har behov for at indkræve gæld.

Det nye system er blevet forsinket flere gange, og selv da den fjerde og sidste release af PSRM blev præsenteret i foråret, manglede der en række funktioner, før det var fuldstændig klar. I mellemtiden er danskernes gæld til det offentlige nået op på et tårnhøjt niveau – i alt 118 milliarder mangler stadig at blive kradset ind.

Eksminister afviste kritisk rapport

Reaktionen fra Søren Lauesen kommer i kølvandet på en ny rapport fra Rigsrevisionen.

Rapporten konkluderer, at det nye system til at kradse gæld ind hverken er færdigt, testet eller tilsluttet til de offentlige institutioner, der rent faktisk skal bruge systemet til at inddrive danskernes ubetalte gæld.

Kritikken fra Rigsrevisionen er blevet blankt afvist af den tidligere skatteminister Karsten Lauritzen (V), som overfor Version2 har påpeget, at Rigsrevisionens faglighed »er overraskende lav«.

»Man bliver nødt til at forstå, hvordan man laver it-udvikling nu. For eksempel sætter man ikke et helt system i drift på samme tid, men derimod skal man gøre det i faser. I dag laver vi agil it-udvikling som en helt afgørende ting,« sagde Karsten Lauritzen i et interview i sidste uge.

Kan ikke stå alene i store it-projekter

Ifølge Søren Lauesen burde projektgruppen bag det nye inddrivelsessystem have brugt mere tid på at spørge sig selv, hvad systemet skal kunne, ved at bruge såkaldte problemorienterede krav.

Med problemorienterede krav beskriver man, hvilke problemer et it-system skal afhjælpe, og hvad it-systemet derfor skal kunne for at afhjælpe disse problemer.

Hvis man i stedet for at tænke i problemorienterede krav udelukkende benytter sig af den agile udviklingsmodel, kan det ifølge Søren Lauesen føre til, at man mister overblikket over det samlede systemkompleks, og på den måde ender man med fragmenterede og usammenhængende projekter.

»Man skal ikke forlade sig på agil udvikling til større systemer, fordi man ikke får den nødvendige sammenhæng, og så er det svært at sikre sig, at f.eks. de forretningsmæssige mål bliver nået. Derudover får man ikke sikret sig, at de faktiske brugssituationer bliver støttet effektivt. Man får en hel masse små stumper af et system, som brugerne kan anvende, men de indgår ikke i en fornuftig kontekst,« siger han.

Indkøbsliste før middagsret

Søren Lausen peger på, at PSRM er specificeret ved at tage hver lille funktion i systemet for sig uden at have overblik over sammenhængen til at starte med. I stedet for at sætte sig ordentligt ind i de konkrete arbejdssituationer for brugerne har man brugt kræfter på at udvikle små dele af systemet, forklarer han.

Udviklerne kan ifølge Lauesen være positivt stemt overfor den agile model, fordi de synes, at det bliver mere tydeligt, hvad den enkelte skal lave. Men det skyldes, at de fokuserer på nogle små fragmenter i projektet, og det er ikke det samme, som at det samlede projekt går godt.

»Det er den sikre vej til at miste overblikket. Det svarer til at bruge kræfterne på at lave en logisk indkøbsliste, før man ved, hvilken middagsret, man vil lave,« siger Søren Lauesen.

Han peger på, at det i små projekter kan være fornuftigt at gå agilt frem, f.eks. når man sidder med vedligeholdelsesopgaver af allerede eksisterende it-systemer.

»Hvis man har et system, hvor der ønskes nogle ændringer, så kan man sætte sig ned sammen med brugeren og finde ud af, hvordan ændringerne skal se ud. I de situationer har man allerede kendskab til den kontekst, systemet bliver brugt i, og det er afgørende for, at den agile metode kan bruges,« siger Søren Lauesen.

Minister kræver plan

Rigsrevisionens rapport har fået den nuværende skatteminister, Morten Bødskov (S), til at kræve, at der bliver lavet en ny og realistisk plan for, hvordan gældsinddrivelsen kan blive genoprettet.

Planen skal blandt andet give svar på, hvordan skatteforvaltningen vil tilkoble landets 800 fordringshavere såsom politi, kommuner og andre offentlige myndigheder, så de kan bruge det nye inddrivelsessystem PSRM til at kradse gæld ind. I øjeblikket er der sluttet 47 fordringshavere til systemet.

Søren Lausen mener dog stadig, at der er store opgaver forude, før systemet er færdigt. Både i forhold til at udvikle de sidste ting på selve PSRM og derefter opgaven med at tilslutte landets fordringshavere.

Skatteminister Morten Bødskov har allerede erkendt, at »det kommer til at tage år, før gældsinddrivelsen er oppe i gear«. Det er en vurdering, som Søren Lauesen tilslutter sig:

»Jeg tror ikke, at systemet er klar med alle fordringshavere tilsluttet i løbet af 2020. Det mener jeg ikke er sandsynligt.«

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (18)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Anne-Marie Krogsbøll

Søren Lausen peger på, at PSRM er specificeret ved at tage hver lille funktion i systemet for sig uden at have overblik over sammenhængen til at starte med. I stedet for at sætte sig ordentligt ind i de konkrete arbejdssituationer for brugerne, har man brugt kræfter på at udvikle små dele af systemet, forklarer han."

Det lyder som et præmieeksempel på det, en eller anden (husker ikke hvem) for nogle måneder siden beskrev som den store tillokkelse ved IT-projekter for politikere og embedsmænd: Man kan skubbe ansvaret fra sig, ud engang i fremtiden. Der kommer en god løsning i morgen.... (eller måske om 15 år.... eller måske aldrig....Det tager jo tid at udvikle så store systemer...)

  • 4
  • 2
Casper Bang

Her har vi desværre endnu et godt eksempel på hvorfor agil udvikling i disse år får et dårligt ry - det bliver simpelthen gradbøjet og voldtaget i en grad som aldrig har været tiltænkt!

Til at starte med, der findes ingen Agil metode - hvor en opskrift følges og værktøj anvendes som f.eks. RUP osv. Agilitet som defineret at 17 praktiserende guroer tilbage i 2002 består istedet af nogle værdier og principper omkring at løse en kundes behov på den bedste måde:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Det er slet og ret en anerkendelse af, at du bliver klogere undervejs og at vi derfor er nødt til at glemme forestillingen om store faste faser (analyse, design, implementation, test...) og én afleværing, men istedet tænke Minimum Marketable Features hvor scope har lov at ændre sig og hvor der er mange leverencer.

I det konkrete tilfælde, er det f.eks. nærliggende at forestille sig, at 30% af PSRM systemet kan indrage 70% af gælden - og så giver det naturligvis rigtig god mening at starte dér. Måske kræver det kun 6 integrationer med omverdenen istedet for 12.

Søren Lauesen synes direkte at angribe IT-udviklerens bedste våben; nedbrydning i mindre dele der kan overskues (divide n' conquer) og det fortæller mig at det er meget langt tid siden manden har haft rigtige udviklingsprojekter under fingrene. Ja jeg er på nippet til at kalde en sådan sætning for idioti.

Jeg mener vi har masser af eksempler på større problemer over i den modsatte grøft, vandfaldsmodellen med faste faser og hvor du principielt ikke anerkender at du bliver klogere undervejs - og sådan en type projekter går jo altid godt, ik?

  • 19
  • 5
Anne-Marie Krogsbøll

Jeg har ingen indsigt i dette, så det bliver muligvis dumme spørgsmål:

I det konkrete tilfælde, er det f.eks. nærliggende at forestille sig, at 30% af PSRM systemet kan indrage 70% af gælden - og så giver det naturligvis rigtig god mening at starte dér. Måske kræver det kun 6 integrationer med omverdenen istedet for 12.


Men hvad så, hvis den tilgang betyder, at det i sidste ende bliver umuligt at inddrive de sidste 30%?

Søren Lauesen synes direkte at angribe IT-udviklerens bedste våben; nedbrydning i mindre dele der kan overskues


Sådan læser jeg ikke Søren Lauesens udtalelser. Jeg læser det mere som om, han siger "Både OG": At man er nødt til at have blik for både de mindre dele, og have det store overblik over, at de mindre dele skal ende med at kunne fungere sammen. Han siger f.eks.:
I stedet for at sætte sig ordentligt ind i de konkrete arbejdssituationer for brugerne, har man brugt kræfter på at udvikle små dele af systemet, forklarer han.

Ingen kan vel være uenige i, at det er vigtigt at kende de konkrete arbejdssituationer, og at disse også udgør en form for "mindre dele", som man skal have blik for - og som så også skal fungere i den store sammenhæng?

Jeg håber, at jeg tager fejl, men for mig lyder den beskrevne tilgang hos SKAT som endnu en EFI-skandale, Sikkert på et andet grundlag, men stadig er problemet, at man ikke har tænkt tingene ordentligt igennem, inden man gik i gang. Og denne gang har man så ikke fyret folk, inden der var belæg for det - i stedet har man forbudt kommunerne selv at inddrive gælden. Jeg ved ikke, hvad begrundelsen er, men det forekommer mig umiddelbart ligeså dumt, som at fyre folk, inden systemerne virker. Kender nogen grunden til, at kommunerne ikke må det?

  • 6
  • 9
Casper Bang

Men hvad så, hvis den tilgang betyder, at det i sidste ende bliver umuligt at inddrive de sidste 30%?


Det er der vel ingen belæg for at konkludere? Tilgængæld betyder det at man kan starte med at indrive langt hurtigere så man ikke bliver ved med at skubbe problemerne foran sig til det har en størrelse hvor man er nødt til at afskrive hele molivitten.

Ved du hvad der typisk sker hvis du satser på de 100% i et faseopdelt forløb over mange år? Integrationerne har ændret sig, nye er kommet til osv. osv. Det er DETTE man anerkender ved agil udvikling, men at lave lighedstegn med et Kanban board eller referere til Agil som en metode er altså at fordreje tingene.

  • 14
  • 2
Anne-Marie Krogsbøll

Det er der vel ingen belæg for at konkludere?


Nej - men du opstiller selv et tænkt scenarie, som jeg så tænker videre over...Vi kan heller ikke konkludere, at det ikke ville ske, hvis man bare gør, som du foreslår, for det er jo netop et tænkt scenarie, der er ingen fakta at gå ud fra.

men helt at skyde skylden på Agil udvikling og fejlagtigt referere til det som en metode,


Sådan læser jeg det som sagt ikke - for mig lyder det ikke som en anklage mod agil udvikling som sådan, men mod den måde det er blevet brugt på i den konkrete sag. For mig lyder det til, at Søren Lauesen anklager Lauritzen og Skat for at misbruge den agile metode - han anklager, tror jeg, ikke metoden som sådan.

  • 9
  • 3
Casper Bang

...han anklager, tror jeg, ikke metoden som sådan.

Pointen jeg ikke helt lykkedes at komme frem med, er at agilitet er en filosofi eller et mindset - IKKE en metode. :)

Der er ingenting i det agile der dikterer at først gør du A, dernæst B - og derfor kan det ej heller være en metode.

Indlæg som disse fra Søren Lauesen, man skulle mene at vide bedre (kender ikke manden), er desværre med til at udvaske begrebet agilitet til noget det aldrig er tiltænkt og det er ikke fair.

  • 20
  • 0
Allan Ebdrup

Men hvad så, hvis den tilgang betyder, at det i sidste ende bliver umuligt at inddrive de sidste 30%?


Mit bud vil være:
Du kigger nok på de 100% i nogen detalje, men ikke ned i mindste detalje, inden du laver de 30% der inddriver 70% af pengene, både så du prøver at sikrer dig at du ikke maler dig op i et hjørne men også for overhovedet at få identificeret de første 30% du vil starte med. Det der så vil ske når du kaster dig over de 30% er at du bliver klogere undervejs, the devil is in the detail, dette fører du løbende tilbage og lader det påvirke din plan. Så planen hele tiden er lagt udfra den nyeste information.

  • 17
  • 0
Claus Jepsen

"at glemme forestillingen om store faste faser (analyse, design, implementation, test...) og én afleværing, men istedet tænke Minimum Marketable Features hvor scope har lov at ændre sig og hvor der er mange leverencer"

Ligesom den agile "metode" bliver gradbøjet, er det tilsvarende fordummende at antage, at alternativet altid er en gigantisk kravspecifikation (omend det er dog klart mere udbredt i offentlige udbud grundet udbudsregler og praksis).

I langt hovedparten af de projekter jeg har set, har man arbejdet incrementielt og taget ved læring efterhånden som man arbejdede sig fremad fase for fase, fremfor at planlægge alt fra start - det er faktisk standard PRINCE2, selvom kun få praktiserer det som tiltænkt.
I de seneste mange år med elementer fra det der i dag er "agil udvikling".
Man kan sagtens høste store gevinster ved at have en overordnet kravspecifikation med fokus på værdiskabelse (problemorienterede krav) og lade projektteamet levere incrementielt og ændre undervejs baseret på opnået erfaring med kortvarige cycles - det har man gjort i mange år.

I min verden udelukker det ene ikke det andet. Men, som ved så mange andre "metoder", uddanner mange sig overfladsk uden at have øje for, hvad metoden kan levere af forskel.

  • 10
  • 0
Allan Ebdrup

Lyder fornuftigt, Allan Ebdrup. Det interessante er så, om det er det, man har gjort i det aktuelle proj

For mig personligt er det mindre interessant. Det har man sikkert ikke gjort.

Det interessante er, den kontroversielle titel på artiklen taget i betragtning og persongalleriet i den, hvordan man kan påstå at hvis man ikke har gjort det så er det fordi man har kørt agilt?

  • 7
  • 0
Denny Christensen

Han skriver at 100 udviklere der hver arbejder med 100 brikker til et puslespil mangler det overordnede billede af hvordan de 10.000 brikker skal hænge sammen til sidst.

Jeg er enig med Casper Bangs synspunkt om at agil udvikling er et mindset mere end en metode, så langt som at udviklerne kun kan skabe en succes indenfor det område de er oplyst på, mens andre roller har andre overblik men ikke kender detaljerne.

Og således har Søren Laugesen ret, et miks af overordnet styring og så mere agilitet i 'hjørnerne' vil nok være det bedste.

  • 13
  • 1
Allan Ebdrup

I langt hovedparten af de projekter jeg har set, har man arbejdet incrementielt og taget ved læring efterhånden som man arbejdede sig fremad fase for fase, fremfor at planlægge alt fra start - det er faktisk standard PRINCE2, selvom kun få praktiserer det som tiltænkt.

Som jeg ser det, i min helt personlige udlægning, så er det agile manifest en modreaktion på, i forfatterenes erfaringer, dårlig praksis, som de har set igen og igen i deres profesionelle virke. Ellers var det nok ikke kommet et manifest.

Altså arbejdspladser hvor:

  • Alle "målinger" siger at der bliver produceret en masse (nøj hvor vi har lukket mange issues), men der kommer ikke ret meget software der virker ud og kunden er ikke tilfreds
  • Udviklerne ingen inflydelse har på deres arbejdsprocess, hvor der ikke løbende reflekteres, evaluers fordomsfrit og forbedres på egen process.
  • Man ikke stoler på hinanden og "officielle" kommunikerer gennem dokumenter der sendes frem og tilbage
  • Der dokumenteres på livet løs, men der kommer faktisk ikke ret meget software ud og det kommer ud meget sjældent.
  • Kunden/forretningen ses som en modstander mere end en medspiller og ikke inddrages direkte
  • Planen bare SKAL holdes, selvom den burde justeres
  • Der produceres dårlig kode
  • Arkitekter der ikke selv har fingrene i bolledejen dikterer dårlige løsninger ned over hovedet på dem der rent faktisk skal implementere tingene
  • Der ikke gøres noget for at motivere folk
  • Lyset brændes i begge ender med alt for tung arbejdsbyrde, der sprintes konstant (pun intented, I'm looking at you scrum ;-))

Hvis du ikke har nogle af disse dårligdomme, så kan man kalde hvad end man gør for agilt?

  • 6
  • 0
Jesper S. Møller

Hvor er det dog fordummende at høre intelligente mennesker skulle forfladige vigtige problemstillinger om komplekse sammenhænge og begreber til “puslespil” og anvende groft forenklede fluffyheder som “den agile metode”.

Hele balladen med gældsinddrivelsen er at det fra politisk side er besluttet at 800 forskellige typer af gæld skal inddrives i damme proces og system, fordi “centralisering altid er godt”. Og Det er måske rigtigt for meget homogene behov, men balladen er jo at rigtig mange af fordringhaverne har vidt forskellige hjemler, og derved stiller forskellige krav til systemet.
Er samtlige 800 typer specificeret i bund? Nej, sikkert ikke. Men var der regnet en ordentlig business case på at centralisere “inddrivelsesprocessen” for samtlige 800 fordringshavere inden centraliseringen blev vedtaget? Jeg tvivler.

Man kan godt køre et projekt agilt hvis man har en rimelig dækkende behovsopgørelse, og kan tegne en rimelig arkitektur og løsningsmodel allerede fra starten og så trykprøver disse fra første sprint. Og så fejler hurtigt, hvis det ikke holder!

  • 14
  • 2
Aslak Stage

I min optik rammer Søren Lauesen netop hovedet på sømmet når han angriber brugen af den agile metode, som den vel og mærke synes at være brugt i forbindelse med udviklingen af PRSM.

Det er jo det som Karsten Lauritzen, SKAT og Netcompany bruger som undskyldning for at systemet er hvor systemet er. Og systemet opfylder ikke det som det skal : indkræve 118 mia!

Og i den forbindelse er det i min bog mere korrekt at skyde på dem og deres forkerte brug af agilitet og ikke Søren Lauesens ganske udemærket bemærkninger om at agil ikke kan stå alene og især ikke i store it projekter( og særligt ikke i det offentlige)

Det er jo ikke Søren Lauesen, som har defineret hvordan den agile metode er brugt i forbindelse med udvikling af PRSM, men netop SKAT og Netcompany.

Søren Lauesen angriber ikke den agile metode på nogen som helst måde, men gør opmærksom på at den netop ikke er brugt korrekt i det her tilfælde og måske slet ikke kan bruges i især store offentlige it-projekter.

Og han har en pointe: SKAT og Netcompany har ikke formået at opfylde den opgave de burde have løst og dermed må konklusionen vel også være at den agile metode de har brugt ikke har virket.

Og som Caspar Bang beskriver den agile metode, så er det vel også først en metode, som skal tages i brug når Business Casen er lavet og den overordnede ramme er besluttet og ikke før. Samtidig er det også en metode og tankegang, som er meget svær at arbejde med i det offentlige, fordi love og regler, budgetter, samt embedsmandskultur ikke spiller særligt godt sammen med den agile tankegang. (Hint: ejendomsvurderingssystemet)

  • 3
  • 4
Henrik Sørensen

Kære Søren Lauesen

Jeg håber inderligt, at du er blevet misforstået og fejlciteret i forbindelse med ovenstående artikel.

Du skal naturligvis have lov til at mene lige hvad du har lyst til, men når du trækker professor emeritus kortet, så tillader jeg mig at have en forventning om en mere sagligt velfunderet kritik.

Du har, de senere år, været ude med riven og har kritiseret utallige store offentlige it-projekter, men jeg kan efterhånden godt have mine tvivl om på hvilket grundlag du udtaler dig.

Den 21. januar i år udtalte du dig også om PSRM til Version2. Den gang var din konklusion, at opgaven var “komplet håbløs” og inddrivelsesreglerne var for komplicerede.

Seks måneder senere den 28/6 bliver du i Version2 citeret for at “lige nu ser planen dog fornuftig ud” og du udtaler: “... det ser ud til, at Skatteforvaltningen har lært af sine erfaringer, og det er jo altid rart”.

Kun tre måneder senere er det så nu udviklingsmetoden, der er skurken og du kritiserer, at man ikke har overblik over, hvordan man skal tilslutte de 800 fordringshavere.

Men skruer vi tiden tilbage til 2015 så var du gæst i Version2’s Podcast og udtalte dig om EFI som du (også) kritiserede voldsomt og ca. 10:30 inde i interviewet fortæller du, at det som kunne have reddet EFI, og som man burde have gjort, var at tage nogle ganske få fordringstyper og sætte dem forsigtigt i drift for at få nogle erfaringer og så bygge videre derfra ... det lyder i mine ører ret meget som det holdet bag PSRM er igang med ... og som du nu erklærer er direkte skadeligt.

Hvad skal man tro på?

I mine øjne skifter du argumentation og rationale i et hæsblæsende tempo og det får mig altså til at tvivle på det fagligt saglige i dine udtalelser.

Kære Søren, hjælp mig venligst med at forstå, om der er forskningsmæssig emperi bag dine udtalelser, eller om det bare er noget du mener og tror ... begge dele er fuldkommen legale udgangspunkter for dialog, men skal jeg tillægge dine udsagn vægt, så er det rart at vide, om det er professoren eller Søren der udtaler sig.

  • 14
  • 1
Lise Gerd Pedersen

Bravo, Henrik. Det har altid undret mig, at journalister så ukritisk refererer professorer ved de højere læreanstalter som "eksperter" i, hvordan den virkelige verden fungerer - også selv det er længe siden, de sidst har befundet sig i den. Hvis der er teori og empiri bag deres udtalelser, så er den akademiske titel relevant - ellers er det falsk varebetegnelse.

  • 5
  • 1
Max Kjeldgaard

Tak for den "lune" kommentar. Jeg slog "agil" op - se nedenfor -, Jeg skraldgrinede over den rammende "kommentar" til de offentlige IT - projekter.

Min første reaktion på Søren Lauesens indlæg var: "Noget værre akademiker !!!!",
men så slog jeg ordet op - se nedenfor -.

        Agil      

Betydninger

hurtig, let og smidig i sine bevægelser SPROGBRUG sjældent
SYNONYMER bevægelig adræt

ORD I NÆRHEDEN
HURTIG BEVÆGELSEhurtig, stærk, snar, lynhurtig, lynsnar, lynrap, lynende hurtig, superhurtig, fantom- tempofyldt pludselig1, hovedkulds1, overilet, akut, brat, abrupt rask og rørig, adræt, smidig, agil, hurtig til bens, letbenet, rapfodet, fodrap, hurtigtløbende kattesmidig gesvindt, rap4, hurtig på fingrene hurtig i vendingen, hurtig på aftrækkeren, rastløs, ilfærdig hurtigtgående, hurtigtkørende epidemiskfra Den Danske Begrebsordbog, kapitel 8Den Danske Begrebsordbog, Det Danske Sprog- og Litteraturselskab 2015.
Kapitel 8: »Sted og bevægelse«
HAST, HASTVÆRKtravl, hurtig i vendingen, effektiv, vims, agil, hurtig, resolut, beslutsom, hæsblæsende, fremfusende, hurtig i aftrækket, hurtig på aftrækkeren, tililende fortravlet, stressetfra Den Danske Begrebsordbog, kapitel 9Den Danske Begrebsordbog, Det Danske Sprog- og Litteraturselskab 2015.
Kapitel 9: »Vilje og handling«
...vis mindre
Læs mere om Den Danske Begrebsordbog

  • 0
  • 3
Log ind eller Opret konto for at kommentere