ITIL och agila metoder

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

ITIL – koppling till andra ramverk

Det finns mycket kunskap och erfarenhet kring hur infrastruktur ska sättas ihop och driftas, hur applikationer ska utvecklas och sättas in i produktion, IT-tjänster flyttas från egen regi till outsourcingleverantör och från egen hårdvara till molnet. Delar av dessa kunskaper och erfarenheter paketeras i formen av ramverk och modeller.

Jag tänker försöka ge några tips och betraktelser från denna märkliga värld. I denna första del ger jag mina två cent kring hur man kan förhålla sig till ramverk och kunskapskällor generellt. I nästkommande kommer jag att, mycket kortfattat, beskriva omfattning, syfte och position för några av de vanligast förekommande ramverken inom IT-världen och hur de kopplar till ITIL. Från min horisont, kanske ska påpekas. Ramverk och modeller som kommer hanteras inkluderar Cobit, Devops, Togaf, Lean, KCS samt agila metoder. 

Jag hoppas att du som läser detta finner det värdefullt och du kanske till och med kommenterar det jag skriver.

I resonemanget kring ramverk och modeller kommer jag att förhålla mig till en utgångspunkt:

Själva poängen är att leverera värdefulla IT-tjänster till kunder som får det utfall de vill och behöver. IT-tjänsterna ska levereras på ett kvalitativt och kostnadseffektivt sätt.

Allt annat kommer att vara sekundärt. Om inte ovan gäller, är inget annat intressant eller användbart.

Konceptet kallas ”IT Service Management” eller ”ITSM”. Vikten av effektiv ITSM går inte att överskatta. ITIL som ramverk för ITSM är väl känt och spritt, men har i de flesta svenska organisationer inte levt upp till sin fulla potential. Anledningen till det är ämnet för ett annat blogginlägg.

Förutom ITIL finns det andra ramverk och modeller för att sprida kunskap och erfarenheter kring delar av ITSM. En del har några år på nacken och har fått positionera och formulera om sig i förhållande till nya tider i allmänhet och ITIL och ITSM i synnerhet. Andra är yngre och har det redan i sig från start. Ytterligare andra missar sin positionering.

En utgångspunkt för allt detta är att det finns oerhört mycket kunskap och erfarenhet kring väldigt många områden inom IT. Mycket mer än vad en enskild människa kan greppa och använda sig av på ett vettigt sätt. Man kan däremot välja att antingen bli lite bättre på vissa saker och inte på andra - det kallas specialist – eller så blir man bredare och grundare i sina kunskaper – det kallas konsult! Eller generalist.

Skämt åsido – det är viktigt för oss konsulter att vara tydliga med vad vi faktiskt kan bidra med, specialistkompetens eller generalistkunskap. Och vad den är bra för. Igen, ett annat blogginlägg.

För att få maximal nytta av ramverk och modeller är det viktigt att anamma dessa under ordnade former. 

Ordnade former betyder att organisationen tydliggör, på lämpligt sätt, vilka ramverk som organisationen använder sig av och i stora drag hur de ska bidra till verksamheten.

Ibland, tyvärr ganska ofta, sker detta på mindre ordnat sätt. Någon initiativrik person hittar en källa till kunskap, tycker att den verkar bra och börjar sedan använda och tillämpa på sin egen del av verksamheten. Inget ont i detta, men kanske inte så effektivt. I bästa fall.

Vill det sig lite värre så är personen i fråga ännu mer företagsam och lyckas få med sig andra och en del av budgeten i investeringar och kostnader som helt enkelt inte borde uppstå.

Detta kan gagna individers roll, rykte och karriär samt ge värdefulla kunskaper och åsikter. Men, det är inte optimalt för organisationen som helhet.

En god idé är att få ned en förteckning över vilka ramverk och andra källor till kunskap som organisationen ska använda (eller redan börjat använda?) samt hur de ska användas. Om det är något som används mycket och ofta, in på listan med det. Om det används sparsamt och inte så ofta – ta inte med det. Sätt upp mål kring vad som ska göras med de ramverk som är på listan. Att vara på listan betyder att det är värt att förvaltas. Och tvärtom.

De ramverk som hamnar utanför listan är givetvis tillgängliga vid behov ändå, men förmodligen inte så lätt, snabbt och tillämpbart som det som är på listan. Och givetvis bör man kunna ändra sig och ta bort respektive lägga till ramverk under resan.

Att positionera ramverken och tydliggöra vilken omfattning och avgränsning som de har hjälper också till. Kan man dessutom tala om vem som ska arbeta med det är det ännu bättre. Det börjar dra ihop sig till en checklista:

• Identifiera vilka ramverk som organisationen ska använda
• Sätt kriterierna innan, se ovan
• Tillsätt någon som ansvarig/ägare
• Om detta blir svårt för att ingen är intresserad, så är det förmodligen ett ramverk som inte ska vara på listan 
• Positionera, sätt omfattning och avgränsning
• Tydliggör i era processer hur ramverket ska tillämpas

Vad ska då en ansvarig/ägare av ett ramverk göra?

Tja, förutom att åka på härliga, långväga konferenser, köpa roliga böcker och gå på kurser i ämnet finns det ett antal punkter som borde fungera:

1. Tillhandahålla fokalpunkt för diskussioner i ämnet
2. Bidra till strategiska och taktiska diskussioner och beslut där ramverket är relevant
3. Hantera kompetensutveckling och internutbildning
4. Samverka med HR, chefer eller utbildningsansvarig
5. Ansvara för kunskapsobjekten, dvs böcker, e-learningkurser, abonnemang etc.
6. Ansvara för förvaltningen av ramverket, uppdateringar, kompletterande kunskap och analys av tillämpningar

För vissa ramverk, exempelvis Togaf, är det naturligt att det hanteras av olika arkitektroller. Arkitekter av olika ordning brukar tycka att det är naturligt att skriva policies och riktlinjer samt instruktioner hur riktlinjerna ska tillämpas. Det är ett bra arbetssätt, särskilt när det kombineras med starka, mogna processer. Så borde fler områden hanteras. En ”service transition policy” skulle kraftfullt och tydligt kunna sätta spelreglerna för all driftsättning, releasehantering, beslutsfattande etc.

Sammanfattningsvis, positionering av ramverket och dess tillämpning är viktigt. Att tydligt kunna peka ut i vilka frågor som kunskapen, riktlinjerna från respektive ramverk ska användas.

Som sagt, syfte med detta inlägg har varit att positionera ramverk rent generellt. Nästa inlägg kommer konkretisera hur ITIL förhåller sig till agila metoder.

Skicka gärna dina kommentarer kring detta. Jag uppskattar det mycket.

Hälsningar

Jim Lindfors

Verksamhetskonsult och utbildare