Er »agilt« løsningen?
Projekter går godt, når man arbejder agilt. Det skrev senior manager Dina Raabjerg fra Systematic i et debatindlæg i Altinget 10. juni.
Hun beskriver en metode, hvor kunde og leverandør sammen udvikler et POC (proof of concept), hvor de i fællesskab definerer kundens behov, forretningsmæssige mål og udkast til løsningen. Under hele projektet arbejder de konstruktivt sammen og reviderer både mål og midler.
Det, ved vi, er en god metode, som tidligere gik under betegnelsen iterativ udvikling. Men som jeg forklarer nedenfor, er der mange andre opfattelser af, hvad agilt er.
Ingen af dem er en mirakelkur. De må suppleres med andre metoder for at give succes.
Mange opfattelser af agil udvikling
Problemet med Dina Raabjergs agile metode er, at den ikke kan bruges i offentlige udbud. EU-reglerne siger, at man i udbudsmaterialet skal definere kravene til leverancen sådan, at flere leverandører kan give et tilbud med en fast pris, og at man kan sammenligne tilbuddene på en fair måde.
Det kan man ikke med Dina Raabjergs metode, for der opstår kravene (dvs. behov og løsningsudkast) i samarbejde med én leverandør. Og prisen kendes ikke på forhånd.
Der er mange andre opfattelser af, hvad agilt er. Agilt kan også betyde, at man laver et normalt udbud med nogle meget løse krav og vælger en leverandør. Lidt inde i processen udvikler leverandøren små stumper program én ad gangen, og »problemejeren« kontrollerer, at stumperne virker korrekt.
Det kan gå godt – men jeg har også set det fungere rigtig dårligt, fordi de små stumper ikke hang sammen på en brugervenlig måde; eller fordi problemejeren ikke havde tid til at kontrollere; ikke vidste, hvad andre brugeres behov var; ikke tænkte på forretningsbehovet; eller kun tænkte på sine egne idealer.
Andre mener, at agilt er det samme som UX-metoden: »Tidlige prototyper med brugervenlighedstest«. Det er også en god metode, men den handler kun om brugergrænsefladen og kan ikke håndtere f.eks. integrationskrav eller forretningsmæssige mål.
User stories giver falsk tryghed
For nogle er agilt, at man skriver kravene til systemet som en række user stories, evt. bundtet i ”epics”. Hvordan det går, har jeg undersøgt eksperimentelt sammen med en kollega. Det viser sig, at de, der formulerer denne form for krav, tror, at de dækker alle behov og krav til systemet. Men faktisk dækker de kun en lille del af kravene og de forretningsmæssige behov.
I eksperimentet beskrev vi en større offentlig organisation, som skulle anskaffe et nyt system til at støtte deres hotline. Vores beskrivelse fyldte fire sider og blev lavet i samarbejde med hotline-medarbejderne.
Det fremgik blandt andet, at der var 11 forretningsmæssige behov/problemer, som fik kunden til at ønske et nyt system – f.eks. at brugerne ikke opdager, at det, de har bedt om, faktisk er udbedret, eller at henvendelser bliver tabt, fordi hotline-medarbejderen tager på ferie. Beskrivelsen er frit tilgængelig på mit website.
Vi fik otte konsulenter/udviklere til at skrive krav til systemet baseret på user stories, og hvad, de ellers mente, var nødvendigt. Besvarelserne var typisk tre til fire sider. På et efterfølgende spørgsmål har konsulenterne bekræftet, at de mener, at deres user stories dækker alt.
Men det viser sig, at disse user stories kun berører cirka halvdelen af de 11 forretningsmæssige behov/problemer. Desuden opdager læseren af kravene ikke, at netop disse user stories er forretningskritiske. Resten af de 11 problemer er simpelthen forsvundet.
Det betyder, at et system baseret på disse user stories kan have ringe værdi for kunden.
Brug problemorienterede krav i stedet
Problemorienterede krav beskriver ikke, hvad systemet skal gøre, men hvad det skal bruges til. Det passer fint til udbud: Leverandøren skriver i sit tilbud, hvad hans system gør, og hvordan det støtter brugen.
Jeg skrev i sin tid selv en problemorienteret kravspecifikation til hotline-systemet, som fyldte 30 sider. Den blev kontrolleret og kommenteret af hotline-medarbejderne. Det, der svarer til user stories, er »tasks«, som fylder fire af de 30 sider.
»Jamen, hvad er de 26 andre sider så?« Det er f.eks. forretningsmæssige mål og hvilke krav, der sikrer at de nås; tildelingskriterier; POC med hævebeføjelser; integrationskrav; sikkerhedskrav; brugervenlighed; svartider; datakonvertering; udfasning; og støtte til kundens deltagelse i udviklingsprocessen.
Alle kravene er formuleret sådan, at de ikke beskriver, hvad systemet skal gøre, men hvad det skal bruges til. Det giver leverandøren frie hænder til at foreslå sin egen løsning. Kravene er opstillet i to søjler, hvor venstresiden er kundens problem/behov, mens højresiden er leverandørens tilbudte løsning.
Kan »agilt« redde de store projekter?
Jeg har undersøgt fem store, offentlige IT-projekter og stumper af flere andre for at finde årsagerne bag, at projekterne gik galt eller fik store problemer. Det var eTL (elektronisk tinglysning), Rejsekortet, PolSag, EFI (gældsinddrivelse) og Epic (Sundhedsplatformen).
Der er 37 »dødsårsager« for projekterne. De har koder A1, A2 … for årsager vedrørende analysedelen, B1, B2 … for årsager vedrørende anskaffelsen, osv. Hvert projekt blev ramt af cirka 16 af dødsårsagerne.
»Agilt« i user story-udgaven kunne, så vidt jeg kan se, ikke have reddet nogen af dem.
Agilt med udvikling i små bidder kunne have forebygget nogle af problemerne, f.eks. at man ikke kan se, hvor langt man er (C4), og at man oversælger teknologien (A5).
UX-udgaven med tidlige prototyper og brugervenlighedstest kunne have forebygget fem af dem, f.eks. at man designer skærmbillederne for sent (C2) og sætter systemet i drift med utilstrækkelig support (F1).
Problemorienterede krav kunne have forebygget ni af problemerne.
Hvis vi tænker på ikke-offentlige projekter, kan vi bruge Dina Raabjergs agile metode. Hvor mange af dødsårsagerne kunne den så forebygge?
Jeg tror, den kunne forebygge cirka 15 af de 37 dødsårsager. Nogle af dem, der ikke forsvinder, er, at man designer skærmbillederne for sent (ligesom det skete i eTL), og at man fejlvurderer brugernes kapacitet (ligesom det skete i eTL og Epic).
Generelt gælder det, at man skal kombinere flere metoder for at sikre succes i store IT-projekter.
Man kan læse om alle projekterne, årsagerne og metoderne her.
Vil du bidrage til debatten med et synspunkt? Så skriv til vores debatredaktion på debat@ing.dk
