Services møder agil udvikling – er det enden på ITIL?

Big Agile udvikling er blevet ”det nye sort” i diskussionen om god it-ledelse. Siden lanceringen af det det agile manifest i 2001 har mange arbejdet med metoderne fra Scrum og Extreme Programming (XP) – og i disse år slår det virkelig igennem på virksomhedsniveau, i takt med at Big Agile metodikker, DevOps og *disruptions *på forretningssiden rammer stadig flere brancher. Indenfor agil metode er produktet konge, og man kører korte effektive releases med integration af drifts-folket direkte i teams. Men betyder det så, at vi ikke længere har brug for ITIL og fokus på services?

Jeg har netop selv været på kursus i Big Agile, hvor der fokuseres på at skalere agilitet til at fungere i store organisationer i stedet for kun de små teams, hvor man traditionelt har anvendt metoden. Udover at blive godt og grundigt opdateret på min viden på de agile koncepter, fik jeg også øjnene op for fordelene ved at opskalere og anvende det på store organisationer.

En case for agile – og en case for ITIL

Traditionelt har udfordringen ved agile været, at det har fungeret godt i små teams, men har været svært at få til at fungere på virksomhedsniveau, hvor mange teams og arkitektur-overvejelser skal balanceres mod hinanden. Big Agile forsøger at løse denne udfordring ved at organisere agile teams indenfor virksomhedens værdistrømme og sikre periodisk koordinering imellem de enkelte værdistrømme. Dette skaber en mere langsigtet organisering og gør det nemmere at tænke kundens forskellige behov ind i en samlet løsning, som hele tiden udvikles, forfines og forbedres. Agilt fokus er altså produkter værdioptimeret mod virksomhedens tværgående værdistrømme.

I modsætning hertil har ITIL traditionelt fokuseret meget på at holde et datacenter og igangsatte services kørende – men også her er der sket en udvikling. ITIL har over det seneste årti bevæget sig mod strategisk service management, hvor fokus er på de nye og ændrede services, kundens forretning har behov for i fremtiden; at man via en service-strategi udviklet i tæt samspil med kunden løbende sikrer, at udviklingen fokuseres på de eksisterende eller nye services, der skaber størst forretningsværdi for kunden. Så fra begge sider er der en bevægelse i gang, hvor fokus bredes ud til at omfatte hele kundens forretning og værdistrømme. ITIL fokus er altså services værdioptimeret mod virksomhedens forretning og strategi.

Hvorfor ikke det bedste fra begge verdener?

Jeg vil argumentere for, at vi har behov for begge – og at både agilitet og ITIL skaber stor værdi, når man altså skaber den rette kobling. At man iterativt i en agil proces leverer stories og features mod epics, ændrer jo ikke på, at produktet hele tiden skal leve op til kundernes forventede serviceniveauer – både funktionelt og ikke-funktionelt – og at et vist niveau af forandringskontrol og forberedelse af support-organisation og kunder derfor er nødvendig.

Den bedste løsning er efter min mening altså en løsning, hvor de igangsatte produkter og services styres efter en aftalt service level agreement, og produktejer er ansvarlig for, at udviklingen af servicen er både fleksibel, langsigtet OG overholder SLA’erne. Det kræver, at når produktændringer lægges i produktion (og dermed bliver en del af den leverede service), er produktejeren både ansvarlig for, at 1) servicen lever op til de aftalte SLA’er med kunden, 2) at organisationen er klar til at håndtere ændringerne, og 3) at kunderne er klar over, hvad ændringerne indebærer.

En sådan løsning sikrer momentum og kundenærvær og understøttes af metodikkerne i Big Agile via dialog om og udvikling af produkter. Samtidig giver service-kataloget og ITIL-redskaberne omkring service-pipeline en vigtig del af det overblik, som understøtter produktejere og værdistrømsejere i at tænke strategisk på tværs af forretningsprocesser og produkter. Dermed sikres, at de overordnede epics reelt understøtter organisationens bedste – og ikke blot er lineære videreudviklinger af den eksisterende produktportefølje.

For hvis man går all-in på agile og helt fravælger ITIL, risikerer man ustabilitet og forvirrede kunder. Og hvis man omvendt fortsætter med ITIL uden agile, risikerer man manglende momentum og dermed manglende konkurrencekraft. I den virksomhed, hvor jeg arbejder, er vi netop på en rejse mod agile udviklingsteams, kundeinvolvering, fleksible produkt back-logs, release-trains og et stigende fokus på DevOps – og jeg ser store synergier i at sammenkoble dette fokus med en ITIL-baseret service management-organisation, der sikrer support, efterlevelse af SLA’er og ikke mindst den nødvendige agilitet i release-styring og change management.

Men hvad er din holdning, kære kollega – kan agil udvikling og ITIL forenes? Og hvis ja, hvad skal der så til? Jeg ser frem til, at vi får udviklet den bedste måde at forene de to verdener på – og at vi på den måde kan bringe os selv og vores kunder et stort skridt videre i at skabe værdi.

Kristian Hjort-Madsens billede
Kristian er teknologidirektør i BEC. Han har en baggrund som management konsulent hos Accenture, er PhD i strategisk it-planlægning fra It-universitetet i København og var i 00’erne chefarkitekt i Finansministeriets Digitale Taskforce. Kristian blogger om trends indenfor FinTech, it-strategi og teknologistyring.

Kommentarer (7)

Jesper Frimann

Jeg tror, at det formelle (ITIL vs Agile Development) er det mindste problem. Kulturen i firmaet er IMHO nok det vigtigste.

Man kan jo f.eks. stille sig de her spørgsmål :

Hvordan er ledelses kulturen ? Har en produkt ejer et 'end to end' ansvar, eller har han/hun mulighed for at påberåbe sig SEP (Somebody Else's Problem), når kæden hopper af f.eks. på et lavere niveau i teknologistakken ?

Hvordan er folk organiseret ?
Snakker vi lagdelte siloer/søjler, hvor der er et højt niveau af formelt adskillelse ? Uden nogen som helst virtuelle/formelle matrix org. bygget oven på ?
Eller har vi en mere uformel 'Team of Teams' aproach til organisering af folk ?

Hvordan er sammensætningen af folk i teknologi stakken ?
Er der mange folk med snævre dybe tekniske skills sets (konger), der har det med at fokusere på 'deres' lille område og det på bekostning, af det bredere perspektiv ?
Har man versitalister, der kan bygge bro og hjælpe med til at flytte fokus fra at være snævert til at være bredt ? Og får de lov til det ?

Får firmaets Enterprise Architecture funktion (hvis man da har sådan en fætter) lov til, at trampe ind på HR domæne, og få indflydelse på hvilke profiler man skal have. Og på det traditionelle 'top management' domæne om, hvordan man organiserer sig ?
Og forstår Enterprise Architecture funktionen at tænke bredt, eller er den f.eks. splittet op efter divisioner, og hvor hver sub-EA funktion bliver målt og vejet på at lige netop den del af forretningen (divisionen) kører optimalt ?
Og hvor rapporterer sådan en funktion ind hvor den burde i ledelses hierarkiet ?

Altså hvis man har en kultur, hvor tværfagligt samarbejde, respekt og forståelse er en grundsten i kulturen. Så burde man kunne forene det formelle (Agile og ITIL), for man er, der jo allerede lidt på det uformelle plan.

Hvis man derimod har en kultur hvor suboptimering, fokus på snævre mål, og SEP er tilladt, så er der et stykke vej.

// Jesper

Christian Nissen

Tak for et godt og balanceret indlæg, hvor det bliver tydeligt, at der reelt ikke er tale om to verdener, men om to perspektiver på den samme verden.

Det er i øvrigt et varmt emne i den store verden, og ejerne af ITIL, Axelos, har fra deres LinkedIn gruppe valgt et pege på en blog, hvor 25 fremtrædende eksperter inden for både Agile og Service Management har givet deres mere eller mindre interessant syn på sammenhængen mellem ITIL og Agile: https://www.linkedin.com/groups/8265717/8265717-6115432709746683905?trk=...

(Det direkte link til bloggen er: https://purplegriffon.com/blog/is-itil-agile-enough?utm_content=buffer8e...)

Palle Simonsen

Eller Dual-Speed IT

I Bankverdenen er der allerede et eksempel fra Danske Banks anvendelse af 'speedboat' teknikker til at udvikle Mobilepay samtidig med at man også opretholder en stabil drift for sine normale forretningsområder.

Umiddelbart tror jeg mere på den model for etablerede virksomheder end Big Agile eller Agile Wall to Wall.

Der kan muligvis være virksomheder, hvor forretningsmodellen kræver så stor agilitet i hele IT-landskabet, at Big Agile giver værdi og Bimodal så kan være et udviklingstrin hen mod dette. I så fald kunne det være nyttigt og oplysende med helt konkrete eksempler i denne blog på etablerede virksomheder med dette behov. Gerne med indsigt i hvordan Big Agile har forbedret forretningen for de pågældende.

Når man ser bort fra startups, hvor man typisk har en meget Agil tilgang til forretningsudvikling og tilhørende IT udvikling, har jeg i mit daglige virke indtil videre kun mødt virksomheder, hvor Dual-Speed IT kan give mening og selv der - og i startups - er man glad for at have er stabilt -ikke-agilt IT fundament under sine støtteprocesser. F.eks. bogføring :)

Dette skal ikke ses som en afvisning af ideerne. Jeg er bare nysgerrig efter eksempler på etablerede virksomheder, der har adopteret Big Agile og deres begrundelser og successer.

Kristian Hjort-Madsen Blogger

Jeg er helt enig i organisationsperspektivet. En af de ting vi arbejder på her i Roskilde er at tænke agilitet op i vores ledelseskultur på tværs af virksomheden, så vi navigerer hurtigt og agilt i både ledelse og i leveranceorganisation. Personligt tror jeg ikke, at man kan skabe en effektiv agil rejse, hvis man ikke tænker det bredere end blot en trendy leverancedynamik. Men det er en interessant refleksion, og ikke en der er nem for etablerede virksomheder. Samtidigt er essensen af Big Agile netop at få teams-af-teams organisering og ”enterprise-niveauet” til at virke.

Kristian Hjort-Madsen Blogger

Det er helt rigtig, at vi skal tænke bimodal. Og jeg tror også på modellen med en X-afdeling eller ”speedboat” uden for stærke bånd til moderorganisationen. For mig er der dog ingen modsætninger imellem Big Agile med teams-af-teams inkl. forvaltning, support, etc. i backloggen i store organisationer og startups. Vi kan indrette større it-virksomheder langt mere agilt med entreprenante medarbejdere end vi gør det i dag. Og jeg vil meget gerne komme med konkrete eksempler – men det kræver næsten et nyt blogindlæg… Så tak for opfordringen, Palle!

Log ind eller opret en konto for at skrive kommentarer