In de afgelopen jaren heb ik het voorrecht gehad om Agile-principes en -instrumenten toe te passen in veel verschillende it-serviceorganisaties. Vaak was dit gericht op het verbeteren van de samenwerking tussen domeinen (multidisciplinair/DevOps) en het reduceren van doorlooptijden van incidenten en changes. Echter, één van de meest intrigerende opdrachten betrof het creëren van een cultuur van continue verbetering voor een telecomdienstverlener.
Eerst wat context. De it-manager van dit bedrijf realiseerde zich dat de organisatie een enorm probleem had, op het moment dat de grootste klant herhaaldelijk geklaagd had over het reactieve gedrag van zijn leverancier. Natuurlijk kreeg de klant wel wat werd gevraagd, maar er was geen sprake van het proactief besturen van de dienstverlening, laat staan van continue verbetering van de processen en diensten. Er was wel een uitgebreide beschrijving aanwezig van het Continual Service Improvement (CSI)-proces, volledig volgens ITILv3. Desondanks werden er geen echte verbeteringen gerealiseerd, het leefde gewoonweg niet.
ITIL als administratieve waterval
Met de introductie van ITILv3 in 2007, heeft het begrip Continual Service Improvement een gezicht gekregen in servicemanagementland. Deze toevoeging aan het ITIL-palet betrof een broodnodige, maar zeker ook fundamentele verandering. Hiermee is erkenning gekomen voor de waarde van continue verbetering als motor voor de it-serviceorganisatie. Echter, het toewijzen van een apart proces en de administratieve watervalaanpak om dit doel te bereiken, is de reden waarom zoveel ITILv3 CSI implementatiepogingen falen. Net als bij Masaaki Imai’s Gemba Kaizen, bestaat succesvolle continue verbetering van it-diensten vooral uit kleine, bottom-up, incrementele verbeteringen, die geïntegreerd zijn in het dagelijkse werk.
Bovendien slaagt ITIL er niet in om het belangrijkste element in het bereiken van continue verbetering adequaat beet te pakken: cultuur. Zo lang de cultuur van een organisatie er niet op is gericht dat verbeteringen worden beloond of dat fouten mogen worden gemaakt, zullen fouten bedekt worden, in plaats van ze te visualiseren, verbeteren en ervan te leren.
Agile maakt CSI praktisch
Aangezien ITIL dus onvoldoende praktisch toepasbare handvatten voor continue verbetering bood, zijn Agile principes (bijvoorbeeld multidisciplinaire, zelforganiserende teams), methoden (Scrum) en instrumenten (Kanban) geïntroduceerd; om de verbeterpunten aan te pakken en te groeien naar een proactieve serviceorganisatie. Het startpunt was Scrum. Alle betrokkenen hebben een gedeeld begrip gekregen van Agile-principes, het Scrum-proces en de relevantie ervan in beheer- en onderhoudsomgevingen. Daarna zijn de rollen toegewezen. De (klagende) klant pakte de Product Owner rol op, terwijl de servicemanager de Scrum Master rol invulde. De meest relevante betrokkenen in de dienstketen (servicedesk, ontwerp, ontwikkeling, testen, beheer en de belangrijkste leverancier) waren betrokken als Team Members.
Als een gezamenlijke inspanning heeft het team vervolgens in korte tijd een inventarisatie gemaakt van alle mogelijke service- en procesverbeteringen. Alle verbeteringen werden verzameld op een Product Backlog (ofwel een Improvement Backlog). User Stories zijn hier gebruikt om de requirements te beschrijven. User Stories zijn weliswaar kort en eenvoudig, maar adresseren altijd de ‘waarom’-vraag. Ook voor verbeteringen is kennis van de noodzaak (business case) essentieel voor iedereen die bijdraagt aan de realisatie ervan.
Tegelijkertijd is Planning Poker gebruikt als instrument om de geïnventariseerde verbeteringen in te schatten. Dit is een bijzonder praktische en nuttige manier om zowel wijzigingen (changes) als verbeteringen (improvements) in te schatten. De relatieve maatstaf (story points) appelleert aan de onvoorspelbare aard van veel changes en improvements.
Zo is in twee weken tijd de Improvement Backlog gevuld (dat wil zeggen, ‘ready’ gemaakt voor drie sprints) en geprioriteerd door de Product Owner. Dus ja, dit betekent inderdaad dat de klant beslist welke verbeteringen het belangrijkste waren. Daarna is de Improvement Backlog verbijzonderd naar een Sprint Backlog voor de eerste sprint tijdens een sprintplanning. Hier zijn taken toegewezen aan de betreffende User Stories en toegevoegd aan het fysieke Scrum-bord dat was opgezet. Samen met de andere ceremonies (daily stand-up, demo, retrospective) was het Scrum-proces geïmplementeerd en gefaciliteerd door de servicemanager. Dagelijks trokken de teamleden hun taken door het proces, om zo de verbeteringen tijdens de drie sprints daadwerkelijk te realiseren.
CSI is ‘business as usual’
Na drie sprints van elk één maand was 80 procent van alle geïdentificeerde verbeteringen gerealiseerd. En geïmplementeerd. Resultaat: een betrokken klant, zichtbaar blij met de verbeteringen tot nu toe en vol vertrouwen over de proactieve instelling van de serviceorganisatie. Maar daar is het niet gestopt. Okay, we zijn gestopt met Scrum. Immers, na drie sprints was de Improvement Backlog bijna verdampt. Maar op dat moment werden de verbeteringen nog altijd gepositioneerd als een afzonderlijk instrument. Daarom werden alle verbeteringen vanaf dat moment opgenomen op het reguliere Kanban-bord, dat reeds gebruikt werd om incidenten, problemen en wijzigingen op te visualiseren. Zo werden verbeteringen onderdeel van ‘business as usual’. Alle teamleden, waaronder de klant, werden inmiddels actief betrokken in de hele keten en waren allemaal gericht op het continu verbeteren van de processen en dienstverlening. Iedereen was zich volledig bewust van de prioriteiten van het onderhanden werk, maar vooral ook van de waarde van het voortdurend verbeteren hiervan.
Ik hoor je zeggen: dit klinkt te mooi om waar te zijn. Natuurlijk zijn hier diverse problemen aan de oppervlakte gekomen. Nogal wat teamleden waren sceptisch met betrekking tot het gebruik van Agile-principes en -instrumenten. Door de waarde van visualisatie aan te tonen, met taakverdeling dwars door het multidisciplinaire team en met het inzichtelijk maken van de gehele leveringsketen, is een verandering in attitude teweeg gebracht. Daarnaast was het allesbehalve eenvoudig om focus te houden op de verbeteringen in de sprints, naast de dagelijkse sores aan incidenten, projectwerk en andere verplichtingen. Dagelijkse stand-ups, de aandacht vanuit management en visualisatie van de resultaten hebben hier zeker positief aan bijgedragen.
Nooit klaar
Het creëren van een mentaliteit rondom continue verbetering valt of staat met het realiseren van een leercultuur. Het besef dat je nooit klaar bent is fundamenteel. Ook deze organisatie heeft dit ingezien. Als toekomstige verbeteringen worden verder nog metrieken geoptimaliseerd en diverse andere Lean- en Agile-elementen geïntegreerd.
Agile CSI is slechts één voorbeeld hoe Agile- en Lean-principes en -instrumenten kunnen helpen om excellente diensten te leveren. Servicemanagement heeft een primaire rol in het bereiken hiervan, door het delen van praktische ervaringen (good practices), maar vooral ook door het creëren van de randvoorwaarden voor alle betrokkenen om hun werk, processen en diensten continu te kunnen verbeteren.
Beste Dave,
Prachtig en praktisch geschreven artikel over de toepassing van Agile als verbeterprincipe. Weer wat bijgeleerd.
Ik ben het volledig met je eens dat het realiseren van continue verbeteren ingebed moet zijn in het dagelijks werk. Medewerkers moeten zelf verbeterpunten kunnen signaleren en ondersteund door de juiste instrumenten, de verbeteringen realiseren. En dit kan alleen binnen een organisatiecultuur die dit mogelijk maakt.
Hi Dave, het lijkt mij lastig om continue verbetering op te nemen als Service. Veel beslissers associeren dat met continue verandering. Hoe hebben jullie dat getackeld, de fluïde relatie tussen de 2 partijen?
Anko,
ik begrijp niet helemaal wat je bedoelt met “opnemen als Service”. We hebben het juist niet als een service opgenomen, maar deze organisatie gecoached om het onderdeel te maken van “business as usual”, en daarmee continue veranderkracht aan de organisatie zelf toegevoegd. Dus zeker niet als twee aparte partijen.
Ik vrees dat we de volgende ronde bullshit-bingo in te gaan, business manager is product owner geworden en service manager Scrum Master terwijl incidenten plots een kanban zijn geworden. Tenminste als ik dit verhaal tegen de context aan zet van beheer:
“Er was wel een uitgebreide beschrijving aanwezig van het Continual Service Improvement (CSI)-proces, volledig volgens ITILv3. Desondanks werden er geen echte verbeteringen gerealiseerd, het leefde gewoonweg niet.”
Even voor de duidelijkheid, idee van Kanban ken ik al vanuit de logistiek waarmee niet veel anders bedoeld wordt dan een trigger. En aangezien een parallel kanban systeem vaak te complex is, wat met wisselend succes geprobeerd werd te ondervangen met ERP, lijken continu veranderingen me een recept voor chaos. Stellen dat CSI faalt door administratieve watervalaanpak is dan weer zo’n constatering van een management consultant die even aan komt vliegen, iedereen op zijn kop schijt en dan weer gauw gevlogen is.
Want een trigger voor verandering kan ook gewoon een event zijn, intern of extern om zodoende behendig mee te bewegen met de markt. Alle termen daar gelaten gaat het uiteindelijk toch om de service naar de laatste schakel. Grappige is namelijk dat verbeteringen binnen organisaties – een telecomdienstverlener toch? – niet altijd tot een betere beleving van de service bij de eindklant leiden. Laten we niet vergeten dat als er geen discussie meer is over de kwaliteit er altijd weer gezeurd wordt over de prijs. ITIL noemt trouwens benchmarking als onderdeel van CSI proces, kijken of je good practice een better practice is ten opzichte van je concurrent.
Prachtig artikel, maar niet meer dan dat. Na zo’n kleine 30 jaar gebruik te hebben gemaakt van de basic principes van ITIL, kom ik een beetje tot de volgende conclusies.
1. ITIL implementatie
Men roept erg vaak ITIL als leidraad te gebruiken, de praktijk is volkomen anders. Dan zegt met, net als dit artikel, dat ITIL de lading niet meer zou dekken.
Het is niet zo zeer dat ITIL de lading niet zou dekken, het is meer dat men klaarblijkelijk te weinig begrijpt van de linaire wetmatigheden ITIL te implmenteren. Dit laatste is overigens niet eens ingewikkeld maar een ‘mind set’.
2. Senior vs Junior
Men heeft sinds 2008 heel snel komaf willen maken van de ingewerkte ervaren, soms duurdere, Senior IT professional. Onder allerlei voorwendselen heeft men die vervangen door zzp-ers of dat aanstormende ’talent’. Of men neemt gewoon iemand aan die vrijwel niets kost en laat de aanvraag open staan. (welke u ook neemt) resultaat is dan zeer eenvoudig dat dat jonge aanstormende talent geen enkele clou heeft van….. o.a. ITIL en de zakelijke en praktische implementatie. Dat betreft dan natuurlijk ook ‘even dat papiertje halen… staat zo leuk op mijn cv’… routine.
3.Verkoopverhaaltje
Sinds 2008 zijn er plots een aantal zaken bedacht waarvan iedereen heel hard aan het roeptoeteren is dat…. Of u wil of niet… daar gaan wij wel naar toe…. Verander mee, anders ben je te laat, …. Agile, Scrum Humtidum en ‘Bunte Illustrierte’ is wat de klok slaat want…..
Het levert alleen maar omzet en geld op, het bespaart u weinig tot niets. Zo zij n de berekeningen van dit moment.
Agile vs ITIL
Agile is een onnozel gelul, excusez moi, t.a.v. ITIL. Kijk naar ITIL en implementeer ITIL strategische en lineair de organisatsie in en men heeft helemaal geen documentatie op proceswaterval. Als dat zo is dan word dit veroorzaak door commerciële geesten die u graag iets willen verkopen dat vaak haaks staat op.
Kijk je goed naar ITIL, en de combinatie van hier voorgaande benoemde factoren, dan weet je meteen waar de schoen hem wringt.
Continue verbeteren
Ik heb meer dan dertig jaar Aikido beoefend. daar komen twee zeer belangrijke elementen naar voren.
Zen
Zen moet u dan niet zien als een absolute maar een manier tegen dingen in het leven aan te kunnen kijken. Dat laat je namelijk ‘door zaken heen kijken’ waar je enorm veel voordeel uit kunt halen. Dat is niet een ’trucje’ dat je zo nodig de business zou moeten leren omdat…..
Kaizen
een ander onderdeel is…. wat u en ik als kind hebben geleerd, oer Hollands, ‘met vallen en opstaan’. Toyoda maakte er begin jaren vijftig een concept van en implementeerde dit in de Toyota fabrieken en processen. Het zegt eenvoudig, alle kennis is vitaal en belangrijk. Een fout is geen fout maar een ervaring dat er ergens iets niet goed in het proces past en aangepast moet worden. dat word nog steeds gezien als zeer waardevol.
Concept in tegenwoordig NL?
Dat betekend als men vind dat je een fout maakt dat je daar zo snel mogelijk op moet worden afgerekend en je er uit word gewerkt.
Zoals u leest, gewoon oude wijn, nieuwe zakken en ik hoef geen duizenden euro’s te investeren voor iets zeer eenvoudig. De wetenschap dat je door samenwerken en goed naar elkaar luisteren, de hiaten in de individuele systemen en processen tegen komt. Iets wat van bijzondere waarde is want anders heb je namelijk geen enkele grond je proces of systeem te perfectioneren.
Daar heb je geen agile voor nodig maar gewoon common sense. De rest is een verkooppraatje. Zet het eens op papier en je ziet hoe eenvoudig het is. Daarna? Gewoon practise as you preach en zie, het werkt en het kost de organisatie helemaal niets extra.