Mere plads til agil udvikling

Digitaliseringsstyrelsen lancerede den opdaterede statslige it-projektmodel d. 28. september. Modellen indeholder en række nye tiltag, der skal forenkle processen for it-projekter i staten. Tanken bag den nye model er, at de enkelte styrelser og ministerier i højere grad selv kan bestemme, hvordan de ønsker at tilrettelægge deres projekter – særligt hvis myndigheden ønsker at udvikle sine it-projekter agilt.

Den nye it-projektmodel kobler agil udvikling og ensartet styring af it-projekter

Mange myndigheder arbejder allerede med agil udvikling. Et af de centrale tiltag i den nye it-projektmodel er, at myndigheder skal have mulighed for at bruge modellen og samtidigt kunne udvikle agilt.

Når en myndighed bruger en agil udviklingsmodel i sit it-projekt, kan den skubbe væsentlige designbeslutninger til udviklingsfasen og samtidig sætte de færdigudviklede delleverancer i produktion løbende. Således kan en myndighed løbende opsamle erfaringer fra projektet og tilpasse leverancerne tilsvarende. Med den agile tilgang forsøger myndighederne samtidig at undgå at lave store og omfattende analyser og design, længe inden de går i gang med udviklingen.

Myndigheder vil ofte kunne reducere mange af de risici, som de agerer i, ved at bruge en agil tilgang til projektudviklingen. Det giver således god mening, at myndighederne i staten er i stand til at udvikle agilt, samtidig med at de også følger den statslige it-projektmodel. Modellen understøtter således den agile tilgang, men giver samtidig en ensartet måde at styre it-projekter i staten på.

Det kræver en væsentlig tilvænning at udvikle agilt, og vi anbefaler derfor, at den enkelte myndighed afprøver den agile udviklingsmodel på mindre projekter. På den måde får myndigheden trænet sine hold i de nye rytmer og roller, som agil udvikling kræver. Og så er myndigheden klar til at arbejde agilt, når der kommer nogle store og vigtige projekter, hvor agil udvikling virkelig giver effekt!

Ministeriernes projektkontor har lavet en god model, der har letanvendelige rammer, hvis myndighederne ønsker at udvikle agilt. Inden for disse rammer er der mange muligheder for at bruge både eksisterende agile rammeværker eller hjemmelavede rammeværker. Ministeriernes projektkontors kunder er på meget forskellige modenhedsniveauer, og modellen kan anvendes, uanset hvor på spektret den enkelte styrelse eller det enkelte ministerium befinder sig – og at få det til at lykkes er fantastisk klaret i sig selv!

Hvilke agile modeller understøttes i den statslige it-projektmodel?

Den nye statslige it-projektmodel understøtter altså agil udvikling, og styrelserne kan bibeholde den organisering, som allerede eksisterer omkring deres projekter. Den nye it-projektmodel understøtter modeller, som er udviklingsfokuserede, såsom Scrum og lignende udviklingsmodeller. Men modeller, der kræver organisatoriske ændringer, såsom SAFe®, LeSS og DAD, bliver ikke understøttet.

Tanken er, at myndigheden kan gennemføre den agile udvikling på udviklingsniveauet, som den enkelte organisation ønsker det, så længe myndigheden har en klar prioritering af epics og user stories, som skal, bør, kan (taget fra MoSCoW – must, should, could, would). Dette gør, at der er kontrol med, hvad projektets minimumsløsning er (epics og user stories, som er skal-prioriteret), og at myndigheden samtidig prioriterer, hvad der kan tages ud, såfremt omstændighederne ændrer sig, mens projektet skrider frem.

Den statslige it-projektmodel får udviklingsniveauet til at hænge sammen med projektniveauet gennem en hård prioritering af krav og behov i form af user stories. Således er det klart ud fra udviklingsniveauet, hvad der er essentielt, og hvad der kan tages ud, hvis der er behov for ændringer. Fordelene ved den model er, at man kan låse økonomi og tid og dermed udelukkende bruge den prioriterede funktionalitet til at styre udsving i projekttrekanten.

Nye roller i modellen

Ledelses- og projektniveauet er stort set uændret i den agile udviklingsmodel i den statslige it-projektmodel. Det er dermed i interfacet mellem projektniveauet og udviklingsniveauet, at der er behov for at styre prioriteringen af epics og user stories. For at dette kan fungere i dagligdagen, introducerer Digitaliseringsstyrelsen to nye roller i den statslige it-projektmodel: En product owner-rolle og Scrum Master-rolle.

Product owner

Den helt centrale, og i øvrigt obligatoriske, nye rolle i den statslige it-projektmodel er product owneren, som styrelserne skal have med, hvis de ønsker agil udvikling. Product ownerens hovedopgave er at være bindeled mellem udviklingsteamet og brugersiden af projektet.

Der kan være en skov af modsatrettede krav og behov inden for det overordnede scope og produktnedbrydningen. Det er således product owners ansvar at prioritere mellem disse krav og behov og sørge for, at de bliver lavet om til user stories i et lettilgængeligt sprog for udviklingsteamet.

Product owneren er den eneste, der bringer opgaver ind i teamet. Det gør, at teamet bliver beskyttet mod den larm, som konflikter og uenighed i brugerorganisationen kan give. Teamet kan derved hellige sig selve udviklingen af de beskrevne user stories.

Det er en omfattende opgave at være product owner, men det sikrer, at teamet altid kender prioriteten af deres opgaver og samtidig har et ”single point of contact”, hvis der er spørgsmål eller behov for afklaring med brugersiden. Product owneren er til stede i det daglige, således at funktionelle krav til sprintets user stories kan blive afklaret løbende, og produkterne kan tilpasses under selve udviklingen.

Den statslige it-projektmodel gør det obligatorisk at have en product owner i agile projekter, uanset om udviklingen sker i den enkelte myndighed eller hos en underleverandør. Det er desuden en klar anbefaling, at product owneren er allokeret fuld tid til projektet – uanset om udviklingen sker internt eller hos en eller flere leverandører.

At være product owner er et krævende job, og kravene til en product owner i den nye model er da også omfattende. Du skal have minimum fem års erfaring inden for forretningsområdet, og du skal have gennemført lignende projekter før som product owner. Hvis dette ikke er tilfældet, så vil det højest sandsynligt blive påpeget ved en risikovurdering.

Ministeriernes projektkontor rammer helt præcist, når de identificerer product owner-rollen som en central rolle i den agile udvikling og lægger vægt på, at det er erfarne folk, som får rollen.

Scrum Master

Ligesom product owner er Scrum Masteren en obligatorisk rolle i den agile udvikling i den statslige it-projektmodel.

Rollen er en slags intern facilitator, som hjælper teamet, når der er behov for at holde hinanden op på de agile rammer og rydde hindringer af vejen. Samtidig beskytter Scrum Masteren teamet mod forstyrrelser udefra og lægger vægt på, at teamet kan udvikle sig uhindret.

Scrum Masteren kan både være intern ved udvikling i det enkelte ministerium eller ekstern, hvis udviklingen sker hos en underleverandør.

Nye principper understøtter modellen

Den nye statslige it-projektmodel anbefaler, at styrelserne eller ministerierne etablerer teams, hvor der er allokeret ressourcer på minimum 50% og med en fuldtids product owner. Det skal sikre, at projekterne hænger sammen, og at de har en reel fremdrift. På den måde undgår styrelserne lange og tynde projekter, og samtidig er der et fast holdepunkt til forretningen gennem product owneren.

Projektmodellen anbefaler samtidig, at udvikling sker i selve styrelsen, så udviklingsteam, projekt, projektleder og product owner alle rent fysisk er placeret samme sted.

Disse principper skaber sammen med princippet om, at projektejeren skal være aktivt engageret, et grundlag, som sammen med den agile udviklingsmodel gør det muligt faktisk at skabe udviklingsprojekter, hvor der er et nært og effektivt samarbejde mellem ledelse, projekt og udvikling. Det er præcis nogle af de grundlæggende præmisser, som skal være på plads for at få agil udvikling til at gøre en forskel.

Konklusion

Alt i alt har Ministeriernes projektkontor lavet en fremragende løsning, som gør det muligt for ministerierne at udvikle agilt – uanset hvad de laver, og hvor modne de er. Man kan sagtens argumentere for, at modellen skulle være mere omfattende, men det ville i sidste ende gøre den mindre brugbar over for en kundegruppe, som har meget forskellig projektmodenhed. Principperne understøtter projektarbejde både agilt og traditionelt, prioriteringen af kravene har altid været god projektteknik og ambitionen om at understøtte metoder som Scrum i udviklingen er et godt sted at starte den agile rejse. Samtidig er rollerne godt tilpasset, og ambitionsniveauet er passende til at starte ud med.

Udfordringerne er naturligvis, at agile modeller ikke er en garanti for at få leveret til tiden og for at få implementeret de medfølgende ændringer i modtagerorganisationerne. Men ved hjælp af et øget fokus på gevinstrealisering og med løbende støtte fra Ministeriernes projektkontor i form af en tidlig risikovurdering er der gode muligheder for at få succes med agil udvikling i de statslige projekter.

Der er mange måder at arbejde agilt i den statslige it-projektmodel, og det er derfor helt sikkert muligt at finde en model, som passer til jer.

Og husk, at der er gå hjem-møde i Implement d. 2. november, hvor Ministeriernes projektkontor kommer og præsenterer modellen, og der er workshops i de forskellige nye dele.