Change management op een agile manier implementeren

Een change implementeren is doorgaans een vrij star proces. Wil je de implementatie hiervan meer agile aanpakken? Dat kan op verschillende manieren. In dit blog vertel ik je hoe je één enkele wijziging agile implementeert, en hoe je meer agile omgaat met alle wijzigingen op je afdeling.

Hoe je een enkele change meer agile implementeert

Zoals ik in mijn vorige blog vertelde kan het implementeren van een change, of in het Nederlands een wijziging, een vrij star proces zijn. Laten we daarom eerst kijken naar hoe je de implementatie van een enkele wijziging wat meer agile aanpakt.

Omschrijf alleen het doel en de randvoorwaarden

Als het goed is, heb je tijdens de change request geen volledig formulier ingevuld, maar vooral het hoognodige omschreven. De twee belangrijkste dingen die je moet omschrijven, zijn het doel en de randvoorwaarden.

Stel, je krijgt vaak dubbele meldingen binnen over kapotte koffieautomaten of trage mailservers. Om dubbele meldingen te voorkomen, wil je dat je klanten kunnen zien of de storing al gemeld is. Je doel zou dan zijn: zorgen dat je klanten zien welke meldingen er al ingediend zijn. Maar je wilt ook zeker weten dat je klanten geen privacygevoelige informatie van anderen kunnen zien, zoals HR-gegevens. Dat is dan een randvoorwaarde.

Veel meer dan het doel en de randvoorwaarden hoef je niet te weten voor je ermee aan de slag kunt.

Zo maak je jouw change management proces eenvoudiger >>

Toets regelmatig je nog aan je doel en de voorwaarden voldoet

Implementeer je een change volgens de traditionele watervalmethode? Dan loop je de kans dat je er op het einde achter komt dat je oplossing niet voldoet aan de vraag van je klant. Bij de watervalmethode ga je er namelijk van uit dat het plan dat je hebt gemaakt hebt, één op één wordt uitgevoerd.

Ruimte om tussentijds bij te sturen bij te sturen is er niet. Terwijl er in die tijd toch genoeg kan veranderen. Misschien ben je tot andere inzichten gekomen over de wens van de klant, of is er nieuwe technologie op de markt gekomen die in een betere oplossing voorziet.

Toets daarom tijdens het uitdenken en implementeren van de change regelmatig: draagt wat we doen nog bij aan ons oorspronkelijke doel? En voldoet het aan de voorwaarden? Bij kleinere wijzigingen is dat niet altijd relevant, die kun je vaak gewoon uitvoeren. Maar bij grotere wijzigingen is regelmatig toetsen zeker handig.

Voldoet je oplossing niet? Dan kun je tussentijds bijsturen. Soms ben je al te ver om nog bij te sturen. Wees dan niet bang om de stekker eruit te trekken. Dat is vaak lastig, want je hebt er al veel tijd en energie in geïnvesteerd. Toch is stopzetten beter dan doorwerken aan een oplossing waar toch niemand blij van gaat worden.

Betrek andere specialisten erbij

Als je een idee hebt hoe je een change wilt oppakken, is het goed als er verschillende specialisten kritisch naar kijken. Welke impact heeft het op andere applicaties of hardware? Brengt het veiligheidsrisico’s met zich mee?

Traditioneel gezien gebeurt de ‘sanity check’ door de CAB-leden, wanneer ze een request evalueren. Volgens de agile-filosofie is het beter het team de ruimte te geven zelf een oplossing te bedenken. Maar als je IT-team de oplossing bedenkt, valt de ‘sanity check’ die het CAB normaal doet, weg. Hoe los je dat op?

Geen vrijheid zonder verantwoordelijkheid. Geef je IT-team niet alleen de vrijheid om een oplossing te bedenken, maar ook de verantwoordelijkheid om bij specialisten te controleren of deze oplossing gaat werken.

Hoe je meer agile omgaat met alle wijzigingen op je afdeling

Je IT-afdeling werkt nooit aan één wijziging tegelijk. Zelfs een kleine IT-afdeling van 6 tot 8 man heeft er al snel 10 á 20 tegelijk lopen, als het er niet meer zijn. En dat is eigenlijk te veel. Soms heb je het gevoel dat je dweilt met de kraan open.

> Waarom je change-proces te langzaam is – en wat je eraan kunt doen

Voer zo min mogelijk tegelijkertijd uit

De oplossing ligt voor de hand: beperk het aantal wijzigingen dat je tegelijkertijd uitvoert. Makkelijker gezegd dan gedaan, absoluut. Maar zeker de moeite waard. Je slaat daarmee meerdere vliegen in één klap:

• De doorlooptijd wordt voorspelbaarder. Doordat je aan minder wijzigingen tegelijk werkt, heb je minder onzekerheden in je werk en kun je beter voorspellen wanneer het afgerond is.

• De kwaliteit van de opgeleverde dienst wordt hoger. Als je ongestoord en met je volle aandacht eraan kunt werken, is de kans kleiner dat je fouten maakt.

• Het is voor je team leuker om eraan te werken. Je kunt je focussen en boekt snel resultaat. Onderzoek wijst uit dat zichtbare voortgang een van de belangrijkste factoren is voor werkplezier. Dat werkt veel motiverender dan het gevoel hebben dat je aan honderd dingen werkt en er nooit iets af komt.

Changes vs incidenten: maak een duidelijke keuze

Hoe maak je tijd voor changes als je zwemt in de incidenten? Maak een bewuste beslissing wat voor jouw team het belangrijkst is.

Wil je een bepaalde doorloopsnelheid van wijziging garanderen? Dan moet je bij alle teams een vaste hoeveelheid tijd afblokken die ze eraan mogen besteden. En accepteren dat incidenten soms wat langer blijven liggen.

Vind je het belangrijk dat meldingen snel afgehandeld worden? Accepteer dan dat de implementaties van changes soms wat langer duren. En dat je team dus wat minder snel nieuwe oppakt.

Wat zijn jouw ervaringen?

Agile Change Management staat nog in de kinderschoenen. Heb jij hier al mee geëxperimenteerd? Ik ben benieuwd naar jouw ervaringen! Meld het in een comment.

Download gratis het Agile Service Management e-book en lees wat je nodig hebt om jouw afdeling wendbaarder te maken.