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

3 kommentarer

Mycket bra och helt i linje med mina observationer.

Ett annat skav mellan agil/lean och ITIL jag märkt är att folk som läser ITIL med ickeagila glasögon kan frestas att tänka sig att alla cykler som beskrivs är långa och alla processbeskrivningar som ska till är mångordiga och ägs av chefer, och alla möten är tråkiga.

I lean/agil ITIL jobbar vi med snabba cykler, med punktvisa processbeskrivningar och teckningar på A4/A3-ark upp på väggen, med rappa stående möten, och med att folk själva är sina egna processägare.

Fortfarande precis lika mycket ITIL och struktur, men snabbt, effektivt, och billigt.

Svara

Hej Ola
Tack för din kommentar.
Jag kan bara hålla med. Det är tyvärr så många tillämpningar av ITIL ser ut i verkliga livet. Ofta ses inte ITILs rekommendationer som just det, utan som gospel och evangelium. En ängslighet att inte missa något gör att ingenting tas bort eller tillpassas till den egna situationen, vilket resulterar i tungrodda processer och oändliga möten ("CAB-möten" på 8 timmar...).
Det är väldigt intressant att fler och fler gör som du verkar ha lyckats med. Korta ned till det absolut mest värdeskapande, strunta i resten. Involvera folk och låt dem ta ansvar och ägarskap. Kul att du verkar ha lyckats väl med det.
Jag återkommer i nästa vecka med nästa blogginlägg. Hoppas du orkar läsa även det.
Igen, Ola - stort tack.
Med vänlig hälsning
Jim

Svara

Skicka en kommentar

Trevligt att du vill dela med dig av dina åsikter! Tänk på att hålla på "Netiketten" och använda vårdat språk.