Binnen veel organisaties is er een strijd gaande tussen het loslaten van de ITIL-kaders en het adopteren van de Agile-kaders. Voornamelijk het gebruik van Scrum (als ‘lichtgewicht’ Agile-aanpak) en DevOps (het behendiger leveren van IT-services; continue levering) viert hoogtij. Het is bijna zover dat wanneer je als organisatie niet Agile werkt je eigenlijk als mateloos ouderwets wordt beschouwd. ITIL is zó 2015, 2014, 2013 …. dat kan écht niet meer!
ITIL (anno nu) is als IT Service Management (ITSM) best-practice gericht op de levenscyclus van een IT-service. Op basis van strategische kaders (de nut en noodzaak om een IT-service te ontwikkelen of significant aan te passen) wordt via de fase ontwerp en de fase transitie een nieuwe of gewijzigde IT-service overgedragen naar een operationele omgeving (de fase productie). In feite ligt de kracht van ITIL in de fase continue serviceverbetering, oftewel op basis van de prestaties vanuit de operationele omgeving verbeteren van willekeurig wat wordt vastgesteld als noodzakelijke verbetering.
Praktijkconstatering 1: In veel organisaties krijgt de ontwerpfase onvoldoende aandacht en wordt er te snel een transitie uitgevoerd; we willen ‘direct’ (of in ieder geval zo snel mogelijk) van situatie A naar situatie B.
Een ontwerp richt zich op ‘het identificeren van de eisen en het vervolgens kiezen van een oplossing die in staat is om aan de eisen te voldoen’. Deze oplossing wordt vervolgens via transitie gerealiseerd (bouwen, testen en inzetten). Vanzelfsprekend is er afstemming respectievelijk samenwerking tussen degenen die zich met het ontwerp bezighouden en degenen die zich met de transitie bezighouden. Sterker nog, tijdens zowel ontwerp alsook transitie worden degenen die zich met de productie van de IT-service bezighouden (permanent) betrokken. Dit is een van de kernitems binnen DevOps; development en operations voegen gezamenlijk waarde toe en zijn gezamenlijk verantwoordelijk.
Agile in relatie tot IT Service Management (ITSM) hanteert als best practice de navolgende uitgangspunten:
- Klanttevredenheid boven SLA-compliance;
- Attitude & samenwerking boven certificering;
- Sturen op resultaat boven sturen op uitvoering;
- Adaptiviteit boven procedures.
Agile Service Management (Agile SM) zorgt ervoor dat de ITSM-processen de Agile-waarden weerspiegelen. De ITSM-processen zijn met “net genoeg” controle en structuur ontworpen om de IT-services effectief en efficiënt te leveren ter ondersteuning van de bedrijfsresultaten, op het moment en op een wijze waarop ze nodig zijn.
Uitgaande van hetgeen binnen Agile Service Management wordt gesteld ‘net genoeg controle en structuur’ kan het dus zijn dat op basis van een analyse binnen de CSI-fase wordt vastgesteld dat de controle en/of de structuur ‘net niet genoeg’ is! Het gebeurt namelijk maar al te vaak dat, ten aanzien van bijvoorbeeld het uitgangspunt ‘adaptiviteit boven procedures’ dit wordt opgevat als ‘we hoeven dus geen procedures (wie doet wat, wanneer en waarmee) meer op te stellen’. Dit gebeurde al met het basis Agile-uitgangspunt ‘werkende software boven allesomvattende documentatie’ en de opvatting ‘we hoeven dus geen documentatie meer op te leveren’! Gevolg is dat na de oplevering van een nieuwe of gewijzigde IT-service er vaak veel onduidelijkheden zijn binnen de operationele omgeving. Dit nog los van de herstelwerkzaamheden om ervoor te zorgen dat de controle en/of structuur wordt bijgesteld of om te zorgen dat de IT-service überhaupt goed functioneert.
Praktijkconstatering 2: In veel organisaties krijgt bij de Agile-aanpak (en in het bijzonder het gebruik van Scrum) sprint-Ø onvoldoende aandacht en ontstaat het inzicht tijdens de vervolg-/uitvoerings-sprints.
De voorbereidende sprint-Ø is erop gericht dat wordt nagedacht over de omgevingen, het team, de hulpmiddelen, de standaarden, de implementatie in de organisatie et cetera. Er moet dus flink wat worden gedaan om dit fundament op orde te hebben. Maar dit is toch eigenlijk vergelijkbaar met de fase ontwerp binnen ITIL? Hierbinnen wordt (naast hetgeen benoemd als onderdeel van sprint-Ø) de aandacht gelegd op onderwerpen zoals technologie- en management-architecturen, de benodigde beheerprocessen, de meetmethodieken en metrieken en de informatievoorziening richting de operationele omgeving.
Het ontwikkelen (en ook het verbeteren) volgens de Agile-aanpak richt zich erop om met een klein, multidisciplinair team, doelgericht, meetbaar en efficiënt te werken, waarbij de werkzaamheden worden ingedeeld in kleine behapbare delen (sprints). Dit is een vergelijkbare aanpak zoals dat binnen ITIL voorkomt in de vorm van een release unit en/of een release package.
Agile Service Management definieert naast de product backlog een proces backlog. Deze combinatie is vergelijkbaar met het CSI-register zoals binnen ITIL gedefinieerd. Er worden drie basistypen sprints onderkend: een strategische sprint, een procesactiviteit sprint en een CSI sprint en vanzelfsprekend kunnen hier combinaties in worden gemaakt.
Bij CSI (continual service improvement) staat de drive om processen effectiever en efficiënter in te regelen centraal, door bijvoorbeeld het meten en het evalueren van de bevindingen van een IT-service. Door CSI toe te passen wordt inzichtelijk wat het effect is van een IT-service en hoe deze IT-service wordt ervaren door de klant/gebruiker. Het is belangrijk dat er, nadat een IT-service is geoperationaliseerd, er voortdurende verbeterslagen worden uitgevoerd. Kijkend naar de kerndoelstelling van CSI ligt hier de essentie van het hebben van een vliegwiel voor verbeteringen (het vullen van een Backlog met verbeterinitiatieven op ofwel het product of op een proces). Dit is een Kaizen-systeem, daar waar verbeteringen in het ene (deel)proces consequenties heeft voor de gehele waardestroom en bijdraagt aan het creëren van waarde voor de klant/gebruiker.
Praktijkconstatering 3: In veel organisaties wordt CSI nog te weinig toegepast en is er onvoldoende aandacht voor continue verbetering en het meten en evalueren van de bevindingen van een IT-service.
Continue serviceverbetering dient te beschikken over de mogelijkheden om een positieve invloed te hebben op alle niveaus van het management om ervoor te zorgen dat het verbeteren de nodige steun ontvangt en voldoende middelen beschikbaar heeft om oplossingen te implementeren. CSI in ITIL gaat overigens pas echt leven als het wordt ondersteund door een bedrijfsbrede filosofie, zoals Lean IT. Bestaande verbeterinitiatieven worden dan gestroomlijnd zodat er in de organisatie een doorstroming wordt bereikt of wordt behouden.
Samenhang
IT-service ontwikkelwerkzaamheden zijn zonder problemen op een iteratieve en incrementele wijze (volgens een agile-aanpak) uit te voeren. Sterker nog, dit wordt onderbouwd door een zeer interessante beschrijving in het ITIL-boek Service Design (TSO, ISBN 9780113313174), paragraaf 3.1 Service Design Basics op pagina 35.
Wanneer services of processen niet worden ontworpen, dan zullen ze zich organisch ontwikkelen. Als ze zich ontwikkelen zonder de juiste controles dan is de tendens gewoonlijk om op de omgevingscondities te reageren die zich voordoen, in plaats van de visie en de bedrijfsbehoeften werkelijk te begrijpen.
Ontwerpen om te voldoen aan de verwachte omgeving is veel effectiever en efficiënter, maar vaak onmogelijk – vandaar de noodzaak om een iteratieve en incrementele benadering van service ontwerp te overwegen. Een iteratieve en incrementele benadering is van essentieel belang om ervoor te zorgen dat de IT-services die naar de productieomgeving worden overgezet, zich voortdurend zullen aanpassen in lijn met de veranderende bedrijfsbehoeften.
IT-services ontwikkelen zich in de loop van de tijd. Tijdens de ontwerp-fase/sprint-0 wordt bepaald wat er in de eerste release van de IT-service (vanuit strategisch perspectief) opgeleverd dient te worden. Vervolgens worden tijdens de geplande vervolgreleases (hierbinnen worden de sprints uitgevoerd) nieuwe IT-service functionaliteiten toegevoegd alsook verbeteringen aangebracht op basis van de bevindingen vanuit de fase productie. Van daaruit wordt middels de vervolgreleases (op basis van het uitvoeren van sprints) naar ‘perfectie’ toegewerkt; een combinatie van nieuwe en vernieuw(en)de functionaliteiten en verbeteringen.
Voor het plannen van de diverse werkzaamheden (zowel ontwerp, ontwikkel en operationele werkzaamheden) is Kanban (het visualiseren en reguleren van de workflow) uitstekend geschikt.
Conclusie
Het is een utopie te denken dat een IT-service ‘in een keer goed’ is. Het ontwerpen en ontwikkelen van een IT-service zal zich dan ook altijd in een groeipad afspelen. Het incrementeel en iteratief ontwikkelen is dan ook een logisch gevolg. Afhankelijk van de noodzaak zal, door een klein, multidisciplinair team, in de vervolgreleases, op basis van het uitvoeren van sprints (strategische, procesactiviteit en/of CSI) telkens naar een nieuwe situatie toe worden gewerkt, in goed overleg met de klant/gebruikers.
Het zit niet in de raamwerken, de best-practices en/of de hulpmiddelen maar in de wijze waarop wijzelf als mensen er mee omgaan; de mindset (de manier van denken) en de cultuur.
Het gaat om gezond verstand en slimmer werk…… ‘het zit tussen uw eigen oren’!
Dit alles vraagt, ook binnen snel veranderende omstandigheden, nog steeds een serieuze afweging en overweging welke (combinatie van) aanpak het beste past, binnen de beschikbare mogelijkheden en middelen, rekening houdend met de huidige (organisatie)situatie.
Ik wens u veel Agile, Scrum, Kanban, DevOps, Lean IT en ITIL wijsheid……. En ik hoop in een goede combinatie en verstandhouding; ‘het een laat namelijk het ander niet onverlet’!
