Dette er tredje artikel i serien om de syv guiding principles i ITIL, denne gang om at skride iterativt til værks.
De første artikler i serien kan du læse her:
https://metier.dk/blog/itil4-guiding-principles-focus-on-value-hvad-betyder-det-i-praksis/
https://metier.dk/blog/itil-4-guiding-principles-start-where-you-are/
Den nye agile verdensorden
Hen over de seneste par årtier er der sket en stadig udvikling hen imod mere agile metoder, hvor fællesnævneren er større omstillingsparathed, hurtigere reaktion på forandringer og ikke mindst tydeligere fokus på kundeværdi. Hvor det før årtusindskiftet var mere almindeligt at se IT-udviklingsprojekter på både 5, 7 og 10 år—og ikke sjældent blev skrottet uden at føre til noget brugbart—har både softwareudvikling og i stigende grad også andre områder som drift, kontraktstyring, økonomistyring m.v. sat kadencen op og varigheden af de enkelte iterationer ned.
Med Scrum-metodens indtog op gennem 1990’erne og 2000’erne—og siden andre metoder som DevOps, SAFe m.fl.—har vi efterhånden vænnet os til sprint à op til en måneds varighed og løbende tilbagemelding fra forretning og kunder på mindre dele af projektet eller tiltaget. ITIL’s egen søstermodel til projektledelse, PRINCE2, indførte i 2015 en agil version af den velkendte projektstyringsmodel, der forsøgte at bygge bro mellem de agile metoder og den traditionelle tilgang til projektledelse, der i daglig tale kendes som vandfaldsmetoden.
Styrken ved PRINCE2 Agile® er opgøret med denne falske dikotomi om projekter som værende enten agile (som i manges øjne er blevet en ubetinget god ting) eller traditionelt indrettet efter vandfaldsmetoden (som omvendt næsten er blevet synonymt med noget dårligt og forældet). Sandheden er, at et projekt ikke kun kan eksistere som én af de to ekstremer; der kan sagtens forekomme agile elementer eller underinddelinger i et traditionelt ”vandfaldsprojekt”, og PRINCE2 Agile har da også begået en genistreg med det såkaldte ”agilometer”, hvor projektet kan styre graden af agilitet på en række parametre som fleksibilitet, samarbejde, kommunikation m.v.
En svaghed ved PRINCE2 Agile er til gengæld, at modellen stadig anerkender præmissen om, at et projekt er adskilt fra den daglige drift (”business-as-usual” eller BAU), for i en fuldkommen agil verden er der slet ikke behov for projekter; udvikling er en integreret del af den daglige drift (deraf begreber som ”DevOps”, der er en sammentrækning af development og operations), og de enkelte teams er ansvarlige for både kravspecifikation, test, design, udvikling, idriftsættelse, drift og løbende forbedring. Resultatet af dette ansvar og arbejde er produkter, der løbende lanceres og opdateres, efterhånden som krav opstår og ændrer sig, og det bliver derfor nemmere at følge med modtagerens behov og fokusere på værdiskabelse.
Samlet ansvar gennem hele livscyklussen
Forsvarsværkerne langs Københavns kyst, herunder Kastellet, hvor vi i disse år har til huse, havde kanoner til at forsvare byen mod fjendtlige skibe. Ifølge legenden skulle den, der havde støbt kanonen, sidde oven på den ved første affyring for at sikre, at den var bygget ordentligt, og at der ikke var sløset undervejs med potentielle problemer eller risici, som ville blive nogle andres problem, når kanonen blev sat i drift. Det var datidens DevOps. På tilsvarende vis skal en faldskærmsudspringer selv have pakket sin faldskærm, så han kan være sikker på, at det er gjort ordentligt. På tilsvarende vis er udviklerne i agile teams selv ansvarlige for den efterfølgende drift, og kan ikke bare overdrage hovedpinen ved fejl og manglende efterlevelse af krav til driften.
Hele formålet med den agile tilgang netop et fokus på at levere fungerende software frem for at bruge for lang tid på at skrive krav og anden dokumentation, som ender med ikke at blive brugt; at agere på forandringer frem for slavisk at følge en plan, som kan have været fornuftig i udgangspunktet, men som i mellemtiden er blevet overhalet af virkeligheden—og at fokusere på kommunikation mellem mennesker, herunder ikke mindst vores kunder, frem for (begrænsningerne ved rigide) processer, værktøj og kontrakter som beskrevet i det agile manifest [i].
Eksempler fra den virkelige verden
En virksomhed med et kludetæppe af IT-systemer, der var opstået ad åre, var nået til et punkt, hvor kundemedarbejderne brugte mere tid på at navigere rundt i systemerne og indtaste de samme data mange gange end på at rådgive kunderne. Virksomheden besluttede i starten af det nye årtusind gøre noget ved situationen, og nedsatte et projekt, der skulle udvikle et nyt system til erstatning for alle de gamle, så alle oplysningerne om kunderne kunne vises i ét skærmbillede. Projektet arbejdede i 3 år på at udvikle det nye system, og da de kom tilbage til forretningen med det færdige produkt, havde virkeligheden ændret sig så meget i mellemtiden, at de måtte tilbage til start og genbesøge kravspecifikationen.
På tilsvarende vis har vi her i Danmark set vores del af store offentlige IT-skandaler, og Jeff Sutherland, en af forfatterne til det agile manifest, beskriver i bogen ”Scrum[ii]” ligeledes en række offentlige IT-skandaler i USA. Alle har de det til fælles, at man ikke har formået at sætte sig ind i kundernes og brugernes behov og følge med ændringerne, men fastholdt en enorm mængde krav, som måske endte med slet ikke at være relevante, når det kom til stykket. Som det hedder i det agile manifests tiende princip: ”the art of maximizing the amount of work not done”, altså alt det arbejde, man har endt med ikke at behøve at udføre, fordi det har vist sig ikke at være nødvendigt.
[i] Beck, K. et. Al, 2001. Manifesto for Agile Software Development. https://agilemanifesto.org/ [tilgået 9. februar 2023]
[ii] Sutherland, J., 2015. Scrum: The Art of Doing Twice the Work in Half the Time. London, UK: Random House