De integratie van Agile Scrum en IT-servicemanagement (ITIL)

De ontwikkeling van hét ‘model’; ‘het ei van Columbus!?’

Om direct maar aan te geven, ITIL en Agile Scrum kunnen uitstekend naast elkaar bestaan, sterker nog ze zijn absoluut niet met elkaar in tegenspraak en er is geen sprake van onverenigbaarheid. En in combinatie met Lean IT is het plaatje echt compleet; de organisatiecultuur en de mens binnen de IT-omgeving zijn hierbij twee belangrijke factoren.

Domeindoelen

Scrum is een specifieke manier om resultaten te leveren. Het is een iteratieve, adaptieve en incrementele aanpak en een raamwerk voor het ontwikkelen en onderhouden van complexe producten. Het is voor elke vorm van levering geschikt, ook buiten de IT, en is uitgegroeid tot veruit de meeste populaire Agile-aanpak.

ITIL gaat over de best practice IT-servicemanagement. Het is een holistische verzameling ideeën en processen over hoe IT-services te definiëren, ontwerpen, in productie nemen en operationeel runnen, en met name het continu verbeteren van de IT-serviceverlening als geheel. Dit is bekend als de servicelevenscyclus.

Het operationele oogpunt is binnen ITIL belangrijk, in aanmerking nemend dat de klantwaarde wordt geleverd tijdens de fase serviceproductie (service operation). De operationele eisen dienen vroegtijdig weerspiegeld te worden in de fase serviceontwerp (service design) en worden tijdens de fase servicetransitie (service transition) geconcretiseerd.

Een projectmatige aanpak is onontbeerlijk. ITIL en Scrum zijn dan ook eerder complementair dan tegenstrijdig. De uitdaging is hoe de twee met elkaar omgaan. Een belangrijk ondersteunende aanpak betreft Lean IT als het gaat om continue verbetering en respect voor mensen. Zie de blog: Lean IT gaat verder dan Agile.

De aansluiting

ITIL en Scrum passen uitstekend samen, zelfs op een hoog niveau. Vanuit ITIL-perspectief start Scrum met serviceontwerp en eindigt met het leveren van een IT-service. Eigenlijk begint het steeds weer opnieuw, zeker ook omdat een IT-services zich steeds verder ontwikkeld aan de wensen en eisen van de klant/gebruiker. Dit is waar Lean IT een belangrijke rol speelt; een continue verbetercyclus en een integrale ketenbenadering (met als doel ketenintegratie) en in lijn daarmee een alomvattende aanpak over alle lagen van de organisatie heen (systeemdenken). Zie de blog: Er is altijd wel iets te verbeteren.

Tijdens de ITIL-fase serviceontwerp wordt op basis van een goedgekeurde business case (vanuit ITIL-servicestrategie) de eisen verzameld in de vorm van user stories en geprioriteerd. Het resultaat is de geprioriteerde Product Backlog.

Tijdens de ITIL-fase servicetransitie worden de Product Backlog items (user stories) afgehandeld door timeboxed Sprints van één maand of minder. Iedere Sprint begint met een Sprint Planning waarin de user stories zijn opgenomen voor de volgende Sprint (de Sprint Backlog is een subset van de Product Backlog). De Dagelijkse Scrum (een timeboxed bijeenkomst van maximaal 15 minuten) helpt om de voortgang te volgen en om blokkades (impediments) op te verhelpen en op te heffen. De Sprint eindigt met een Sprint Review (een timeboxed bijeenkomst van maximaal vier uur) waarin de nieuwe/veranderende IT-service formeel wordt aanvaard, gevolgd door een Sprint Retrospective (een timeboxed bijeenkomst van maximaal drie uur) die resulteert in de geleerde lessen voor de volgende Sprint.

De grote uitdagingen

Een van de problemen met het pure gebruik van Scrum is dat er geen directe zorg is voor serviceproductie en de focus sterk gericht is op de utility (het nut); de geschiktheid voor het doel (de functionaliteit die de IT-service biedt om aan een bepaalde behoefte te voldoen). IT-serviceoplossingen worden maar al te vaak ‘over de muur gegooid’ en vooral garantie-aspecten (warranty) van een IT-service (capaciteit, beschikbaarheid, veiligheid en continuïteit) worden buiten beschouwing gelaten en aan het einde van de keten wordt de IT-service nog steeds geleverd zonder de noodzakelijke toegevoegde waarde.

Een van de grote bijdragen van ITIL is dat de operationele aspecten al zijn opgenomen in een vroegtijdig stadium tijdens de fase serviceontwerp, althans zo zou het moeten zijn! Toegepast op Scrum betekent het in ieder geval dat tijdens het opstellen van de user stories en de Product Backlog ook de operationele eisen worden verzameld. Tijdens de Sprint houdt het Scrum Team vervolgens rekening met alle operationele aspecten (bijvoorbeeld infrastructurele, monitoring, incidentafhandeling et cetera). Lean IT ondersteund vervolgens met een aanpak omde klantwaarde te maximaliseren door het minimaliseren van verspilling in de processen en activiteiten.

Change Management & Release Planning

Vanuit operationeel oogpunt fungeert wijzigingenbeheer als de beschermer van de productieomgeving door het (laten) identificeren van risico’s van iedere wijziging en het voorkomen van negatieve gevolgen. Algemeen gesteld valt iedere wijziging op een configuratie-item onder wijzigingenbeheer (bijvoorbeeld de Product Backlog die tijdens de fase serviceontwerp wordt gemaakt). De lastige vraag is in welke mate? Aan de ene kant zal het meer stabiliteit geven en aan de andere kant wordt meer administratie gecreëerd en wordt ingeboet op flexibiliteit.

Het is dus een wisselwerking. Wijzigingenbeheer is ook een belangrijk onderwerp binnen Scrum. Iedere Sprint eindigt bijvoorbeeld met de Sprint Review waarin de Product Owner de Sprint beoordeeld en goedkeurt. Tijdens serviceontwerp fungeert de Product Owner dan ook als poortwachter voor iedere user story (wijzigingenbeheer boven vereisten). Er zijn veel voorbeelden van wijzigingenbeheer, een aantal RFC-plaatsen zijn weergegeven in onderstaande schema.

agile-scrum-versus-itil

Om het juiste evenwicht tussen flexibiliteit en stabiliteit te bereiken is het belangrijk om te beslissen wat wel of niet onder wijzigingenbeheer valt en daarenboven dienen de juiste vertegenwoordigingsmodellen toegepast te worden (in verband met governance-regels).

Een aantal voorbeelden:

  • Wijzigingenbeheer over de Product Backlog is gedelegeerd aan de Product Owner. Ondanks dat dienen serviceproductieteams ook betrokken te worden om de operationele garantievereisten (warranty) zeker te stellen in de vorm van user stories.
  • Wijzigingenbeheer over de Sprint resultaten is gedelegeerd aan de Product Owner en in het geval dat de Sprint wordt opgenomen in een toekomstige release fungeert de reguliere operationele CAB ook als goedkeuring.
  • Wijzigingenbeheer over de Sprint Backlog is gedelegeerd aan het Scrum Team; de Product Owner, de Scrum Master en het reguliere Ontwikkelteam.

Geautomatiseerd testen

Gebruik maken van Agile Scrum betekent (meer) frequente releases. Testen is evenwel vaak een echt pijnpunt. Dit betreft veel minder het testen van nieuwe functionaliteiten (hier ligt vaak al voldoende aandacht tijdens de Sprint) maar eerder de regressietesten (controleren of bestaande functionaliteit nog steeds werkt).

Het automatiseren van regressietesten is de sleutel. Teams die werken volgens het zogenoemde ‘test fabriek-’model dienen vroegtijdig betrokken te worden en op basis van de Product Backlog dienen testgevallen te worden ontwikkeld en te worden geautomatiseerd. Veelal zijn dergelijke teams gepositioneerd als een chapter (volgens het Spotify-model); samengebrachte vaardigheden die binnen eenzelfde algemeen competentiegebied werken en worden ingezet over Scrum Teams heen.

De rollen

Scrum kent slechts drie belangrijke rollen: De Product Owner (de ‘stem van de klant’), de Scrum Master (de facilitator) en het Ontwikkelteam (de professionals). ITIL kent vele rollen, in de context van Scrum zijn de rollen Service Owner, Change Manager, CAB en CSI Manager de meest relevante.

De rol van Service Owner versus de Product Owner heb ik in een eerdere blog uitgebreid besproken. Samengevat is het logisch, zeker als het gaat om bestaande IT-services, dat de rollen Service Owner (ITIL) en Product Owner (Scrum) in een en dezelfde persoon is opgenomen. Beide rollen fungeren als ‘stem van de klant’ en kennen de eisen-kant. Zie de blog: Service Owner versus Product Owner.

Kijkend naar wijzigingenbeheer zal de Scrum Master en de Product Owner onderdeel dienen te zijn van de CAB wanneer het gaat om de release van een Sprint. De Product Owner, vanuit het oogpunt van de Sprint Backlog, treedt op als CAB-goedkeurder.

Binnen Scrum is het continu leren een integraal concept. In een Sprint Retrospective worden procesverbeteringen geïdentificeerd en in de Dagelijkse Scrum worden belemmeringen op succes opgeheven. Dit is een verantwoordelijkheid van de Scrum Master. Structurele verbetering van het Scrum-proces dient te worden beschouwd vanuit organisatorisch ontwikkelperspectief en dient onderdeel te zijn van het CSI-register. De Scrum Masters en de CSI Manager dienen op een regelmatige basis contact te onderhouden. Zie de blog: De opmaat voor Agile Service Management.

Als iemand eenmaal heeft laten zien hoe het gedaan moet worden, weet iedereen hoe het moet.

Conclusie

Het gaat om een viertal specifieke onderwerpen om tot integratie te komen van de servicemanagementprocessen (ITIL) met de Agile-aanpak (Scrum), zeker als het om bestaande IT-services gaat, en met de Lean IT-aanpak als het gaat om continue verbetering en respect voor mensen.

Scrum is niet alleen voor ontwikkeling van nieuwe producten in een geïsoleerde wereld. Het is uitgegroeid tot een belangrijke stroming voor twee belangrijke ITIL-aanpakken: serviceontwerp en servicetransitie, zeker als het gaat om bestaande IT-services. Historisch gezien praten deze werelden niet of onvoldoende met elkaar, in ieder geval wordt niet op dezelfde golflengte gepraat. Aan de ene kant de ontwikkelaars en aan de andere kant de operationeel IT-professionals. Dit is de reden voor een geïntegreerde en praktische aanpak over hoe ze bij elkaar te brengen om een wederzijds begrip te creëren hoe beide werelden werken.

Het betreft een totaalvisie op de gehele keten, van het starten van het ontwikkelproces tot en met het in productie gaan van softwarecomponenten en het operationele beheer ervan.

Kortom, we hebben het over DevOps; een aanpak waarbij de communicatie, samenwerking en integratie tussen ontwikkelaars en de operationeel IT-professionals wordt benadrukt maar zich hiertoe zeker niet beperkt.

Download het artikel: Inbedden van DevOps in de organisatie

2 reacties op De integratie van Agile Scrum en IT-servicemanagement (ITIL)

  1. Meindert Putter 28 mei 2017 op 13:19 #

    Integratie zoeken, waar mogelijk sluit aan bij Best Practise gedachten en klantbelang. Opent de deur naar synergie en minder concurrentie tussen modellen.

  2. Peter 13 december 2018 op 19:58 #

    Interessant. Praktisch toepasbaar.

Geef een reactie

Deze website gebruikt Akismet om spam te verminderen. Bekijk hoe je reactie-gegevens worden verwerkt.

Motto: ‘de gewone dingen ongewoon goed doen’ waarbij geldt ‘garantie is meer dan beloften’.