Change Management
Als team binnen een grotere organisatie ben je aangemoedigd om agile te werken. Al een aantal jaar ben je fanatiek aan het scrummen geslagen. Elke twee weken rollen er user stories van de band, waarde wordt geleverd.
Fijn! Maar…
Ondertussen staat je omgeving niet stil en wordt er gewerkt aan de algehele volwassenheid van de organisatie als geheel. Onderdeel hiervan is het inrichten van processen als incident en change management. Maar, hoe sluit dit nu aan bij het agile proces dat je met je team al jaren hebt gefinetuned?
De processen vergelijken
In dit geval heb ik mogen helpen bij het opstellen en inrichten van het change management proces binnen onze organisatie. Als uitgangspunt hebben we het ITIL change management proces genomen. Voor elke wijziging in de IT infrastructuur betekent dit dat de volgende stappen worden doorlopen:
- Aannemen en registreren
- Classificeren
- Beoordelen
- Voorbereiden
- Testen en vrijgeven
- Implementeren
- Afsluiten
Dit proces lijkt op het eerste gezicht misschien veel gestructureerder dan een gemiddeld agile / scrum proces, maar als je er beter naar kijkt zijn er veel overeenkomsten:
- Aannemen en registreren – Maak een user story.
- Classificeren – Voer een impact analyse uit, onderdeel van backlog refinement.
- Beoordelen – Product owner bepaalt de prioriteit, samen met de waarde die geleverd wordt kan beoordeeld worden of de user story verder opgepakt kan worden.
- Voorbereiden – De user story wordt opgenomen in een sprint en ontwikkeld.
- Testen en vrijgeven – In een sprint wordt de user story volgens de Definition of Done getest en opgeleverd in een increment.
- Implementeren – De increment wordt op een gegeven moment in productie genomen.
- Afsluiten – Documentatie is bijgewerkt als onderdeel van de Definition of Done en het werk is geëvalueerd (evt. in een Retrospective).
In ons geval was het naast het volgen van het proces ook nodig om de administratie in één systeem te vatten. Dit is vaak lastig omdat er meerdere systemen worden ingezet om verschillende redenen. De wijzigingen die in het kader van het change management proces worden bijgehouden worden vastgelegd in Topdesk. De user stories en backlogs van de scrum teams in Jira. Hoe kun je er nou voor zorgen dat niet alle wijzigingen dubbel geadministreerd hoeven te worden? Mijn antwoord zou zijn: automatiseren.
Administratie automatiseren, hoe dan?
De product en sprint backlog van het scrum team worden bijgehouden in Jira. De administratie van alle wijzigingen binnen de organisatie worden bijgehouden in Topdesk. Topdesk biedt een vrij eenvoudige Change Management API aan. Deze API is te gebruiken door met Jira Automation webrequests uit te voeren. Op deze manier is het mogelijk om op basis van wat er in Jira gebeurt wijzigingen in Topdesk aan te maken en te beheren. Deze communicatie gaat maar één kant op, van Jira naar Topdesk. Het is dus belangrijk om goed na te denken over welke informatie je wanneer naar Topdesk wil sturen.
In de bovenstaande afbeelding is te zien dat de automatisering wordt gestart op het moment dat de sprint begint. Dit doen we omdat we in Topdesk met sjablonen werken en al het sprintwerk een standaard wijziging oplevert in Topdesk. De doorlooptijd van deze wijziging staat dus voor alle wijzigingen die op deze manier worden aangemaakt op twee weken, de duur van onze sprints. Bij het aanmaken van de wijziging sturen we vanuit Jira de volgende velden op:
| Veld in Jira | Veld in Topdesk |
|---|---|
| Issue summary | Korte omschrijving |
| Issue Description | Aanvraag |
| Issue URL | Actie |
| Issue Reporter | Aanmelder |
In Topdesk is een aparte verkorte impactanalyse aanwezig. Deze hebben we in Jira nagemaakt, zodat we deze per user story kunnen invullen en ook geautomatiseerd kunnen opsturen naar Topdesk, nadat de wijziging in Topdesk is aangemaakt.
Op basis van de status wijzigingen in Jira wordt de status in Topdesk bijgewerkt. Wanneer de user story uiteindelijk op de status “Done” of “Won’t Do” wordt gezet dan wordt de status in Topdesk bijgewerkt naar respectievelijk “bijgewerkt naar “Completed” of “Rejected”. Dit zijn twee statussen waarmee in Topdesk de wijziging als gereed is aangemerkt.
Conclusie
Het implementeren van een change management proces in een agile omgeving lijkt complex en leidt misschien tot dubbele administratie. Echter kunnen we ons ook niet met de rug naar dit soort ontwikkelingen keren. In het kader van volwassenheidsmodellen en/of benodigdheden voor certificeringen kan het nodig zijn om extra processen in te richten in verschillende applicaties. De truc is volgens mij om te kijken waar je de aansluiting tussen de verschillende processen kan maken en deze waar mogelijk te automatiseren. Zo maak je het voor je scrum team eenvoudig om mee te gaan in externe processen zonder dat deze je dagelijkse flow teniet doen.
Heb je ook ervaring met het toepassen van de ITIL processen zoals incident en change management binnen een agile werk omgeving? Wil je delen wat je hiervan hebt geleerd? Of heb je nog andere tips en trucs om de processen goed in je team te laten landen?
Laat dan hieronder een reactie achter.
Header photo by Jack Moreh from Freerange Stock
Geef een reactie