ITIL och agila metoder - Motsatser eller komplement?

I mitt förra inlägg skrev jag om ITIL och förhållandet till ramverk i allmänhet. Nu går vi in på förhållandet till specifika ramverk och vi startar med agila metoder.

Agila metoder har vunnit mark på senare år och det av bra skäl - kortare cykler, snabb anpassning till ändrade behov, bättre nyttjande av kompetens och säkert fler ändå. Tyvärr ser många en konflikt mellan detta och de "rigida" och "oflexibla" ITIL-processerna. Ofta, om inte oftast, är detta en helt onödig konflikt och ett pseudoargument mot ITIL och IT service management i största allmänhet.

För att sätta förväntningarna så definierar jag agila metoder enligt följande: 
Lättrörliga programvaruutvecklingsmetoder som används för programvaruutveckling där fokus ligger på nära samarbete mellan utvecklare och experter på affärens behov och processer. Detta kännetecknas av korta cykler, täta möten mellan beställare och utvecklare med uppföljning och justering, inkrementellt och iterativt arbetssätt och förlitande på människor, relationer och kommunikation mer än process och dokumentation. Se det agila manifestet: http://www.agilealliance.org/the-alliance/the-agile-manifesto/

Jag påstår att missuppfattningen till mycket stor del bygger på det faktum att tillämpningen av ITILs ramverk och utformningen av processerna upplevs som tungrodd. Det är förmodligen helt sant. Men det behöver inte vara så. Tvärtom. Dessa två vinklar in på delvis olika, delvis samma sanning kan samverka och skapa oanade synergier. Låt oss kika på en del områden där det kan uppstå konflikter.

• Change management är ITIL-processen för beslut och kontroll.
• Agil metodik bygger på ständiga små inkrementella beslut.
• Konflikt? Inte nödvändigtvis.

Att fatta beslut om riktlinjer för Change management att hålla sig inom är ett kännetecken för mogna organisationer. Det är mekanismen för högre chefer att ta strategiska beslut att genomsyra de taktiska och operativa besluten.

Exempel: Om strategin är att nå ut snabbt med nya tjänster och kvaliteten inte står i fokus så är det OK med en Change-hantering som inte trycker hårt på testning, kvalitetssäkring och genomarbetade business case. Google är ett företag som har anammat den change-strategin. Det var också en nyckelfaktor för hur www.aftonbladet.se blev den mest framgångsrika nyhetssajten i Sverige redan på 90-talet. Det var ofta nytt utseende på hemsidan och nya sätt att hantera och sortera information. Inte många kommer ihåg att det ofta var störningar och avbrott i tjänsten.

Det finns ingen motsättning till denna strategi i ITIL-processen Change Management. Tvärtom, ITIL trycker hårt på vikten av att anpassa varje enskild (ITIL)-process efter organisationens specifika behov och strategier.

• Release and Deployment management är ITILs process för att med en helhetssyn säkerställa att grupper av godkända ändringar byggs, testas, rullas ut och verifieras på ett säkert, repeterbart och spårbart sätt.
• Inom agila metoder är det inbyggt med inkrementella utrullningar av den programvara som produceras.
• Motsägelsefullt? Inte alls!

De flesta förstår det mycket kraftfulla argumentet som IT service management och ITIL slår fast som en grundbult: det är tjänster som levereras, inte teknik. 

Att programvaruutvecklare tar hand om de fel och brister som uppstår i och med deras ständigt pågående utveckling och utrullning är en bra sak. Vissa kallar detta "dog fooding", dvs man äter sin egen hundmat och tar fullt ansvar för den och alla aspekter av den.
Men, en seriös och mogen beställare inser att det slutliga målet är att detta ska landa i en tjänsteleverans och att förutsättningarna för detta måste skapas Detta är ett ansvar som läggs på utvecklingen av samtliga komponenter - applikationer, infrastruktur, supportprocesser, information och verktyg för hantering av tjänsteinformationen etc.

Alltså - om en organisation väljer att fylla sin Release and Deployment-process med ett agilt innehåll är detta helt OK. Vissa saker kommer att vara annorlunda, andra kommer att vara precis likadana. ServiceDesk kommer fortfarande att behöva förbereda sitt bidrag till den färdiga tjänsten, det kommer fortfarande att behövas en Known Error Database (KEDB), Incident management processen kommer fortfarande att behöva känna till hur den ska anpassas och de nya Service Requests som tjänsten obönhörligt kommer att ge upphov till ska förberedas och fördelas.

Med en lagom stor dos ödmjukhet på alla sidor kan man säkert komma överens och till och med sätta en metodik och erfarenhet som kan gälla framtida utvecklingsprojekt och hur det ska fungera i verkligheten. Ju bättre rustad organisationen är för detta, desto bättre beställning och desto större chans att projektet lyckas hålla sig inom den heliga treenigheten tid - kostnad - resultat/kvalitet.

• En sista jämförelse - Configuration management.
• För det första, det verkar som de flesta inom IT-världen har förstått att Configuration management inom Software Asset Management är en sak och att Configuration management inom IT service management är en annan sak. De har beröringspunkter, men är två olika discipliner.
• Bråk? Inte om man tänker efter först.

För att leverera tjänster med en chans att lyckas behövs kontroll på vad man har och hur det hänger ihop. Självklart kan krav ställas på allt som går i produktion att det ska vara känt vad det är och var det är. På en nivå som tjänstelevererande organisation bestämmer och utvecklingsprojektet tillhandahåller som del av leverans. Komplett med dokumentation.
Om man bara lyssnar och tar hänsyn till alla intressenters behov och krav i förväg har man en bra chans att lyckas. Om inte tar man en stor risk att vakna upp väldigt bryskt.

Nästa inlägg i denna serie kommer att handla om arkitektur och jag kommer att dra en lans för en ny slags arkitektroll. Som vanligt tar jag tacksamt emot era åsikter och kommentarer. 

Jim Lindfors
Verksamhetsutvecklare och utbildare