Staten arbejder også agilt – men ingen beviser for at det er bedre end ’vandfald’

I halvandet år har statens it-projekter kunne køre på en agil kontrakt, som gør processen mere fleksibel. Men der er ikke sikre tegn på, at det bliver bedre end med den klassiske vandfaldsmodel, fortæller Digitaliseringsstyrelsen.

I England har statens it-projekter igennem de seneste par år været igennem en massiv omstilling, så enorme projekter og tommetykke kravspecifikationer til en leverandør blev afløst af små og mere fleksible projekter, hvor statens selv har styringen og it-kompetencerne, og så køber resten ind i mindre bidder.

Læs også: Sådan åbnede den engelske stat for små it-leverandører – og sparede 5 milliarder

Læs også: It-chef for den britiske stat: Derfor koder vi altid i open source

Sådan en omvæltning er ikke på programmet i Danmark, men statens it-projekter har faktisk i halvandet år kunne køre på en kontrakt, som tillader agil udvikling undervejs, i stedet for den klassiske vandfaldsmodel, hvor alt er skrevet ned på forhånd, når udviklingen går i gang.

»I nogle tilfælde giver det rigtig god mening at arbejde agilt, så efter arbejdet med standardkontrakt K02 valgte vi at prioritere en standardkontrakt til agile projekter, for det var den lavest hængende frugt, som myndighederne havde mest brug for,« fortæller Morten Ellegaard, kontorchef i Ministeriernes Projektkontor i Digitaliseringsstyrelsen.

Kontrakt K03, som den blev døbt, var klar til brug i december 2012, efter en tæt dialog med branchen, og den er siden blevet brugt, også i nogle store projekter. Hvor mange i staten, som har valgt et agilt projekt, er der ikke tal på, for det bliver ikke målt.

»Der er ikke indberetningspligt, så vi har ikke en oversigt, men jeg kender til en del myndigheder, som arbejder agilt eller semi-agilt,« fortæller Morten Ellegaard til Version2.

Skal stadig have fast pris og tidsplan

Statens agile projekter kan dog ikke give los og være helt fleksibelt på alle parametre. Der er et krav om en fast pris og en fast tidsplan, når man indgår en kontrakt med en leverandør, fordi pengene til et større it-projekt skal bevilges på forhånd i det politiske system.

»Tid og pris betyder meget i staten, så her lægger K03-kontrakten ikke op til fuld agilitet. Men vi er relativt agile på ydelsen, så det er her, man kan finde frem til løsninger i samarbejde med leverandøren,« siger Morten Ellegaard.

Læs også: Mirakel-moppedreng? Agil K03-kontrakt skal redde offentlige it-projekter

Der er også indsat et krav om en minimumsleverance, som leverandøren skal kunne levere for den aftalte sum. I kontrakten skal man således have en række ’absolutte krav’, som så bliver suppleret med alt det, der er ’nice to have’, og som man så undervejs kan forsøge at nå med de resurser, der er til rådighed.

Desuden rummer kontrakten en leveranceforpligtelse inden for de forskellige delleverancer. Det er lidt konservativt, men det understøtter den måde, staten fungerer på. Vi ønsker ikke at forpligte os til at betale for en vare, man måske slet ikke får,« forklarer kontorchefen.

Det måske mest banebrydende i den agile kontrakt i staten er, at man som kunde kan afbryde samarbejdet undervejs, hvis det ikke fungerer.

»Det er ikke nødvendigvis gratis at udtræde af samarbejdet, og man skal tænke sig rigtig meget om, før man gør det. Men oplever man store problemer i de første uger, ser man ofte, at problemerne fortsætter. Så bør man ikke lade som ingenting og tro, at det løser sig, for det gør det meget sjældent,« siger Morten Ellegaard, som endnu ikke har hørt om en kontrakt, der blev droppet på den måde.

Læs også: It-leverandører er utilfredse: Ny agil standardkontrakt er farlig

Ingen klare beviser for bedre projekter med agil kontrakt

At skifte vandfaldsmodellen ud med en agil tilgang, så det bliver muligt at ændre projektet løbende, i takt med at udviklingen skrider frem, er i nogle kredse blevet udråbt som løsningen på mange af de problemer, som it-projekter bliver ramt af.

Men faktisk er der ikke sikre tegn på, at agile projekter generelt klarer sig bedre end ikke-agile-projekter, fortæller Morten Ellegaard, blandt andet med henvisning til den kendte Oxford-professor Bent Flyvbjerg, som forsker i fejlslagne projekter.

»At arbejde agilt er ikke nøglen til at lykkes med sit it-projekt. Der er mange parametre, som afgør, om et it-projekt bliver en succes eller ej, men ser man isoleret på agile projekter i forhold til vandfalds-projekter, så er der ingen signifikante forskelle på, hvordan projekterne overholder tid og budget,« siger han.

I stedet handler det om at bruge de agile metoder i de projekter, hvor det giver mest mening. Det er typisk i de projekter, hvor man fra starten ikke med sikkerhed ved, hvordan man bedst skruer løsningen sammen. Altså når man har svært ved at skrive en færdig kravspecifikation før en udbudsrunde.

Til gengæld er der også mange situationer, hvor det agile koncept, med tæt samarbejde mellem kunde og leverandør hele vejen, kan give problemer, hvis kunden ikke er klar til den ’belastning’.

»Man skal være dygtig som kunde, før det giver mening at kaste sig ud i et større agilt projekt. Man skal for det første have en projektleder, som reelt kan træffe dag-til-dag-beslutninger. Og så skal man have en projektgruppe, der reelt kan arbejde på fuld tid med leverandøren. Det er ikke alle, der har det til rådighed, og det er heller ikke altid hensigtsmæssigt,« siger Morten Ellegaard.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (21)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Niels Henrik Sodemann

Ord kan være tvetydige og have mange betydninger. De fleste it-folk har nok en opfattelse af ”agile”, der ligger i nærheden af ”Manifesto for Agile Software Development” (se: http://agilemanifesto.org):
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan

Der er intet I K03, absolut intet (som 0,00%), der er I nærheder af ovenstående. Draft til den ikke udfyldte K03 kontrakt med bilag er på 177 sider (se: http://www.digst.dk/Styring/Standardkontrakter/K03-Standardkontrakt-for-...) og en udfyldt kontrakt efter anvisningen må være på tusindevis af sider. Den er fyldt med big-bang, mini vandfald der leder til at monster vandfald, planer, processer, dokumentationer osv.

At man kalder K03 agil, må bero på uvidenhed om it-terminologi, paradigmer, erfaringer og lærdom (da det i modsat fald er i mod bedre vidende).

@Jesper Kildebogaard, det må da pirre din journalistiske nysgerrighed, at man kan komme til den vildfarelse at K03 er agil. Håber at du og dine kolleger graver dybere for at finde svar.

  • 21
  • 0
Henrik Rathje

At kalde staten for "agil" er nok at gå.. hmm... RET langt væk fra sandheden, og det er definitivt ikke korrekt at de arbejder agilt fuldt ud.

De bruger ofte dele af den agile tankegang, men på ledelses niveau arbejder man stadig ABSOLUT med fast pris, fast mål og vandfalds leverancer.. man forsøger så at indføre lidt agilt på udvikler niveau, iterations tankegangen.. men det bremses altid af daglige/ugentlige rapporter med excel ark der skal udfyldes til chefen, fast deadline med faste krav osv.

Nu er jeg ikke tilhænger af agil i alle sammenhænge, det er IKKE en "silver bullet".. men metoden har sin berettigelse mange steder.. man skal dog være bevist om at benyttes den forkert, så har den ikke store fordele frem for vandfalds modellen.

Så ja; se lige lidt nærmere på om K03 kan kaldes agil!?... jeg mener det ikke. Og jeg vil tilslutte mig:

"At man kalder K03 agil, må bero på uvidenhed om it-terminologi, paradigmer, erfaringer og lærdom (da det i modsat fald er i mod bedre vidende)."

well said!

  • 4
  • 0
Christian Nobel

Desuden rummer kontrakten en leveranceforpligtelse inden for de forskellige delleverancer. Det er lidt konservativt, men det understøtter den måde, staten fungerer på. Vi ønsker ikke at forpligte os til at betale for en vare, man måske slet ikke får

Javel ja, det var da helt nye toner, for man har da ellers været rigtig gode til at betale for noget man enten slet ikke får, eller som slet ikke virker.

Det burde ikke være nødvendigt at trække perlerækken frem igen.

  • 7
  • 0
Daniel Udsen

De bruger ofte dele af den agile tankegang, men på ledelses niveau arbejder man stadig ABSOLUT med fast pris, fast mål og vandfalds leverancer..

Hvis du begynder med tæt samarbejde uden objektive udvalgsprocess og forudaftale pris og leverings betingelser, så har du svært ved at dokumentere der ikke foregår skumle ting på ledelses plan. Offentligt privat samarbejde er noget der altid har været dybt problematisk fra et juridisk/etisk standpunkts.

Husk at vi taler om store stive og historisk set korruptions betændte organisations typer og ikke små private firmaer hvor beslutningstagere og "stakeholder" er identisk. Du kan ikke ignorere den problemstilling, og det kan påvirke hvilke modeller man i praksis kan bruge især når der er store pengebeløb og eksterne parter involveret.

EU udbudsreglerne har et og kun et realt formål nemlig at dæmme op for korruptions potentialet(husk at EU dybest set betegner favorisering af lokale firmaer som korruption) i den offentlige sektor.

Spøgsmålet her er om du realt kan outsource udviklings projekter til private firmaer uden at ende i et uløseligt etisk/juridisk problem.

  • 5
  • 1
Mikkel Christensen

Hej Version2

Hermed en opfordring til at hjælpe Digitaliseringsstyrelsen ud af deres misforståelse om at K03 projekter skulle være agile.

Når I, som overskriften på artiklen mere end antyder, ikke stiller jer kritiske overfor at der nu skulle være beviser for at agile projekter ikke er bedre end vandfaldsprojekter, kommer I til at være mikrofonholdere for en absurd fortælling.

Det er vældigt ærgerligt, fordi der lige nu sidder en del mennesker i det offentlige system som får indarbejdet en helt skæv forståelse af hvad agil softwareudvikling drejer sig om. Nogle af disse er beslutningstagere, og når de for fremtiden skal vælge kontraktmodel, vil de ikke have et retvisende billede af hvad agile kan bidrage med, og i hvilke sammenhænge det giver mening at bruge agile principper.

mvh

  • 4
  • 0
Mikkel Christensen

Hej Daniel,

Et par uddybende spørgsmål til din kommentar, set i relation til K03/agil debatten

Hvis du begynder med tæt samarbejde uden objektive udvalgsprocess

Mener du at en agil model er i modstrid med en objektiv udvalgsproces - i så fald hvorfor?

så har du svært ved at dokumentere der ikke foregår skumle ting på ledelses plan

Mener du at den nuværende udbudsmodel udmærker sig ved sin transparens og tydelige sammenhæng mellem udbudskrav og det faktisk leverede?

mvh

  • 5
  • 0
Henrik Rathje

Hvis du begynder med tæt samarbejde uden objektive udvalgsprocess og forudaftale pris og leverings betingelser, så har du svært ved at dokumentere der ikke foregår skumle ting på ledelses plan.

hmm... er ikke sikker på jeg er enig.. men måske jeg misforstår dig?

I en agil udvikling aftales jo netop mål og delmål løbende (pr. sprint), og hvis man virkelig ville så kunne man jo lave en kontrakt der kun gik på et givet antal sprints af gangen og så evaluere om man fortsætter? Så kan ikke se det blokerer for kontrol af leverandøren?.. tværtimod er det MEGET hårdere at udvikle til et agilt projekt.. og også mere krævende af organisationen.. der er ingen "free rides" i et agilt projekt.. er vores erfaring.

så jeg kan ikke se det ikke kan lade sig gøre.. har selv arbejdet agilt i det offentlige (nogle få gange) og det gik faktisk forbavsende fint. Problemet opstod da EU blandede sig.

Det største problem (og vel samtidigt en af de store fordele) er at for at køre agilt så SKAL man kunne acceptere at der sker en dyb påvirkning af kultur og processer i virksomheden/styrelsen/ministeriet.

Men det er jo en lang diskussion.. vedr. nærværende artikel så er overskriften jo kun vand på ignoranter og uvidendes mølle.. i virkeligheden er agil udvikling en stor fordel i projekter hvor problemstillingen er for kompleks eller ikke kan defineres 100%.. hvordan spiser man en elefant?.. en lille bitte bid af gangen :-)

  • 3
  • 0
Jeppe Boelsmand

1½ år er i øvrigt ikke ret lang tid. Hvis bruger udtryk som semi-agil og agil på udviklerniveau og tror man kan jamme et scrummøde ind her og lidt parprogrammering ind der så tyder det, for mig, ikke på at man har forstået værdien og pointen. Hvis stakeholderne ikke stoler på dem de sætter til at løse opgaven, så gør det ingen forskel hvilken model man bruger. Hvis de gør, hvad er pointen så med kontrolstrukturene?

  • 1
  • 0
Morten W. Jørgensen

Tid og pris betyder meget i staten

Det må så være med omvendt værdiset i forhold til mig, for det virker som om "staten" gentagende gange vælger at bruge så lang tid og så mange penge som muligt på at opnå så lidt som muligt.

Sjovt som vi kan lægge forskellige værdier i de samme ord.

  • 2
  • 0
Torben Mogensen Blogger

Et klassisk mantra indenfor softwareudvikling er "Time, price and specifications: Pick any two". Så med fast pris og tid, må man forvente, at specifikationerne ikke bliver helt opfyldt. Men det er nok også bedre end at hælde tid og penge efter et projekt, indtil specifikationer er helt opfyldt.

Men generelt tror jeg, at de involverede personer i et projekt er vigtigere end systemudviklingsmetoden: Dygtige mennesker opnår gode resultater uanset metoden (og ofte uden at bruge en formuleret metode) og inkompetente mennesker opnår dårlige eller slet ingen resultater uanset metode. Metoder kan måske have en lille effekt overfor mellemgode arbejdere, men hvis der er inkompetente mennesker på holdet, vil de ofte gøre mere skade end gavn, og det bedste vil være at lade dem gøre ingenting.

  • 2
  • 0
Morten W. Jørgensen

Hej Torben.

I det følgende sætter jeg lighedstegn mellem "Leveret men så ringe det ikke kunne bruges og mårtte skrottes" og "Ikke fået noget". Det i mente så:

"Time, price and specifications: Pick any two".

Ja. Eller "Good, fast and cheap", men jeg forstår ikke hvad det er du prøver at forklare mig, for normalt er det ikke sådan at man ikke får noget som helst hvis man vælger tid og pris. Man får et eller andet produkt som så ikke er så godt som man havde ønsket sig.

Ser vi på proask, polsag og Amanda, har man intet fået og så er det ikke billigt uanset hvad man har givet. Så er det faktisk meget, meget dyrt. Tillige kom ingen af projekterne til tiden - faktisk kom de slet ikke, og så er det jeg funderer over hvad monstro Morten Ellegaard mener når han siger at "Tid og pris" er vigtig. Det kan ikke betyde at han ønsker:

  • Billigt og hurtigt men dårligt, for det har han ikke fået.
  • Billigt og godt men langsomt, for det har han ikke fået.
  • Godt og hurtigt men dyrt for det har han heller ikke fået

Så hvad er det præcist han mener? Mit gæt er, at han ikke selv ved hvad han mener. Han står nemlig og forsvarer en langsom og dyr process der ikke giver noget produkt. Det forsvar han giver er at "tid og pris" er meget vigtige, men udfaldet taget i betragtning forsvarer han samtidig at det er vigtigere at få en stram deadline til en lav pris end et produkt.

Det giver jo ikke nogen somhelst mening. Overhovedet.

  • 1
  • 1
Casper Niebe

Jeg deler i høj grad holdning med hovedparten af de, der har kommenteret denne artikel. K03 har så absolut intet med agilitet at gøre. Omvendt forhindrer den ikke agilitet i tilblivelsesprocessen. Men når resten ikke følger med, kan du være nok så agil på udførelse, og stadig aldrig nå i nærheden af de reelle gevinster en agil tilgang vil kunne bidrage til. En stor del af dette skyldes med god sandsynlighed reglerne for EU-udbud, hvor der - i min optik - ganske enkelt ikke er mulighed for agile projekter.

Og hvorfor i himmelens navn bringes Bent Flyvbjerg ind i debatten her? Bevares - man finder næppe nogen med bedre og mere detaljeret indblik i såkaldte "megaprojekter", men hans speciale er altså megaprojekter for infrastruktur. Infrastruktur! Veje, jernbaner, trafikplanlægning i byer og tilsvarende. Nu kan man godt kalde mig firkantet, men lige med den type projekter, forstår jeg egentlig godt, der ikke er den store forskel på vandfalds- og iterative projektmodeller. Et stykke motorvej fra A til B har jo på forhånd et ganske fint defineret mål, som ingen rigtigt kan være uenige om. Et system til sikker lagring af danskeres CPR-numre (pun intended) har jo langt fra samme tydelige målsætning fra start, hvorfor jeg på ingen måde mener, Bents forskning kan anvendes i denne sammenhæng. Det er altså en ommer med "ekspertudtalelsen", Version2.

  • 1
  • 0
Per Erik Rønne

Måske skulle man se på hvilken type mennesker, der bestemmer i disse store it-projekter.

Består ledelsen af jurister og andre djøf'er uden særligt kendskab til it-området?

Eller består den af dataloger og andre fagfolk?

Ved IC4-skandalen i DSB viste det sig at det var djøf'erne der bestemte. Ingeniørerne, der rent faktisk vidste noget om tog, var kørt ud på et sidespor.

  • 1
  • 0
Daniel Udsen

Mener du at en agil model er i modstrid med en objektiv udvalgsproces - i så fald hvorfor?

Problemet er at du kun må se på absolut standardiserede faktorer under udbudsreglerne, og de er dybest set varianter af pris og specifikation.

Mener du at den nuværende udbudsmodel udmærker sig ved sin transparens og tydelige sammenhæng mellem udbudskrav og det faktisk leverede?

Nej absolut ikke, men det betyder ikke at man bare kan smide reglerne ud uden at forholde sig til det grundproblem de er sat i verden for at løse.

så jeg kan ikke se det ikke kan lade sig gøre.. har selv arbejdet agilt i det offentlige (nogle få gange) og det gik faktisk forbavsende fint. Problemet opstod da EU blandede sig.

Jep problemet opstod da EU gjorde dine konkurrenter og markedet gennerelt til stakeholders i processen.

Problemet er her at staten har en række forpligtelser over for markedet et privat firma ikke har og det forbyder enhver form for partnerskab mellem staten og individuelle private firmaer samt gennemtvinger en form for omvendt bevisbyrde i forhold til "saglige skøn".

Det største problem (og vel samtidigt en af de store fordele) er at for at køre agilt så SKAL man kunne acceptere at der sker en dyb påvirkning af kultur og processer i virksomheden/styrelsen/ministeriet.

Der ligger svjv et implicit krav om at udbudsvindere holdes på armslængde afstand af offentlige myndigheders kultur og processer netop fordi de ikke må opnå en privilegeret adgang der kan give fordele ved senere udbud.

Der er modeller for den slags transformationer men de kræver at nyudvikling foregår i et åbent forum hvor hele samfundet/markedet har adgang til både processen og slutresultatet, hvilket man ikke bare kan udlicitere til et individuelt firma.

  • 1
  • 0
Daniel Udsen

Nåeh, det går vist udemærket med SKI.

SKI er svjv formelt en ramme aftale der er åben for alle firmaer, og er udbudt i overenstemmelse EU's udbudsregler. der er netop her ikke tale om et lukket seamarbejde med kun en partner. Men igen jura og virkelighed kan værre forskelligt. og vi er langt fra der hvor ting foregår efter reglerne.

At der er firmaer der ikke gider besværet med at forsøge at leve op til de specifikationer der stilles under SKI er så en anden sag. Men ofte er der flere konkurrerende firmaer under en SKI ramme aftale.

Problemet med udbudsreglerne kommer først rigtigt når der ikke er tale om køb af standardiserede produkter.

  • 1
  • 0
Uffe Seerup

er Styrelsen for Arbejdsmarked og Rekruttering (STAR) (tidligere Arbejdsmarkedsstyrelsen).

STARs udbudsproces er, at de køber agile teams (fx Scrum teams) i stedet for produkter lavet fra specifikationer.

Som del af Udbudsprocessen/udvælgelsen, vurderer STAR (som én af flere parametre) de teams der tilbydes fra leverandørerne.

STAR sætter sig så som product owner sammen med leverandørens team under udviklingsforløbet.

  • 0
  • 0
Ole Jepsen

Hej allesammen

Fin debat! Godt at "skændes" lidt ;-)

Tillad mig at bringe lidt fakta ind i debatten. Statistik baseret på 80.000 projekter:

http://www.mountaingoatsoftware.com/blog/agile-succeeds-three-times-more...

Vær opmærksom på, at Mike Cohn (og jeg) er stærkt farvet pro-Agile, men det er hans kilde ikke...

Fortsat rigtig god sommer til alle - og gid flere projekter vil lykkes ( = bringe værdi - og nok også nogenlunde holde sig indenfor budget og tid, men PRIMÆRT bringe nytteværdi...)

Sommerhilsen fra Ole Jepsen, goAgile

PS: Nogen kender måske historien om Sydney Opera House. Det gik jo exorbitant over budget og tid (var det 100 gange det oprindelige budget..?), men har siden betydet vanvittig meget for Sydney og for Australien - SELV OM budgettet og de oprindelige planer slet, slet ikke holdt. Det vigtige spørgsmål er nu ikke bare HVAD vi kan lære af denne historie, men snarere om vi ER ÅBNE FOR LÆRING... P

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