Hoe we EventStorming gebruiken om onze processen inzichtelijk te maken

Net als elk ander bedrijf hebben we veel processen bij Easy LMS. Bijvoorbeeld hoe we support tickets afhandelen of nieuwe functies ontwikkelen. We gebruiken de Verbeterkata om onze processen te optimaliseren. Een van de eerste stappen is het specificeren van de huidige situatie. Het blijkt echter dat iedereen zijn eigen kijk heeft op wat de huidige situatie is. EventStorming is een techniek die we gebruiken om onze processen eenduidig te definiëren.

Stel je voor dat je een nieuwe medewerker bent bij een bedrijf. Je wordt gekoppeld aan een meer ervaren teamlid en doorloopt alle, meestal ongedocumenteerde, bedrijfsprocessen. Je creëert een mentaal model van het proces door vragen te stellen en documentatie te lezen. Hoe meer ervaring je opdoet, hoe minder vragen je hoeft te stellen en hoe minder documentatie je hoeft te lezen. De meeste dingen doe je (semi-)automatisch.

Minder actuele documentatie over een proces zal leiden tot meer variatie in de mentale modellen die werknemers van dat proces hebben.

Als je vervolgens vergelijkt hoe je het proces aanpakt met een ander teamlid, zul je merken dat je sommige dingen heel anders doet. Dit komt omdat jullie mentale modellen verschillen.

Wanneer je een proces optimaliseert met behulp van de Improvement Kata, kan het moeilijk zijn om de huidige situatie te beschrijven wanneer de mentale modellen aanzienlijk verschillen. Hadden we maar een manier om deze mentale modellen om te zetten in documentatie.

Hoe we bij EventStorming zijn gekomen

Begin 2020 bezocht ik de Domain-Driven Design Europ conferentie om meer te leren over het beter modelleren van onze software. Een workshop waar ik aan mee wilde doen ging over EventStorming. Ik had er al eerder over gelezen en ik dacht dat het ons zou kunnen helpen om domeinspecifieke kennis uit de hoofden van onze experts te halen op een manier die makkelijk te delen is met de ontwikkelaars. Zo zouden we betere software kunnen bouwen. Het bleek dat EventStorming heel nuttig is voor het modelleren van software, maar ook voor het modelleren van bedrijfsprocessen!

Helaas sloeg de pandemie toe. We sloten ons kantoor en begonnen op afstand te werken. EventStorming draait om het hebben van een groep experts in een kamer die werken aan een groot gedeeld oppervlak. Dit was niet langer mogelijk om te organiseren. Gelukkig realiseerde Alberto Brandolini, de oprichter van EventStorming, zich dit ook en organiseerde hij een andere workshop om dit probleem op te lossen: Remote EventStorming. Ik deed mee en wachtte daarna op een kans om te experimenteren met EventStorming.

Ons ontwikkelproces modelleren met EventStorming

De afgelopen maanden hebben we ons ontwikkelproces vaak veranderd. Soms mislukte het proces, en het werd duidelijk dat niemand meer het totale overzicht over het proces had. Het perfecte kandidaat-proces om EventStorming op uit te proberen!

Ik vertel het team dat ik wil experimenteren met EventStorming. Ik ben ervan overtuigd dat we hiermee een goed overzicht kunnen krijgen van het huidige ontwikkelproces. Ik nodig een paar geïnteresseerde ontwikkelaars van beide teams uit en maak een gedeeld remote whiteboard met Miro. We volgen de standaardstappen van EventStorming:

1. Chaotische verkenning: maak plakbriefjes voor alle gebeurtenissen die je kunt bedenken en die in het proces plaatsvinden.

2. Dwing de tijdlijn af: rangschik de gebeurtenissen van het begin van het proces naar het einde.

   Verrijk de gebeurtenissen: voeg metagegevens toe aan elke gebeurtenis. De opdracht (actie) waarmee de gebeurtenis wordt gestart, de benodigde gegevens, het systeem dat actie onderneemt en het beleid dat aangeeft wat er vervolgens moet gebeuren.

Chaotische verkenning

In het begin voelt het een beetje onwennig. Maar zodra de eerste plakbriefjes verschijnen, gaat het tempo omhoog en zit iedereen er helemaal in.

We beginnen met alle deelnemers een eigen stuk whiteboard en een kleur te geven (maar niet oranje, daarover later meer). Ze krijgen 25 minuten de tijd om sticky notes te maken voor alle gebeurtenissen die ze kunnen bedenken en die tijdens het proces plaatsvinden. Een gebeurtenis is iets dat in het verleden gebeurd is en niet meer veranderd kan worden. Daarom schrijf je ze op in de verleden tijd. Bijvoorbeeld: "Code repository aangemaakt" of "Code uitgerold naar de productieomgeving."

Ik moedig ze aan om "vals te spelen" en te kijken naar de gebeurtenissen die andere deelnemers opschrijven, omdat het een heel nieuw deel van het proces kan openen waar je eerder niet aan dacht. Het is prima om gebeurtenissen toe te voegen die andere deelnemers ook hebben.

De tijdlijn handhaven

Nadat ik merk dat er geen nieuwe plakbriefjes op het bord verschijnen, gaan we verder met de volgende stap. Ik trek een lijn op het whiteboard. Dan vraag ik iedereen om een sticky note te kiezen van de gebeurtenis die als eerste plaatsvindt in het ontwikkelingsproces en deze boven de tijdlijn te plaatsen. We bespreken kort welke gebeurtenis echt de eerste is en plaatsen deze aan het begin van de tijdlijn. Om aan te geven dat we het allemaal eens zijn over deze gebeurtenis en zijn plaats op de tijdlijn, veranderen we de kleur van het plakbriefje in oranje (daarom waren er eerder geen plakbriefjes in deze kleur?). Daarna gaan we verder met de volgende gebeurtenis.

We krijgen een uitgebreidere discussie over een gebeurtenis. Om de stroom op gang te houden, maak ik een speciaal soort sticky note genaamd een hotspot. Daarop beschrijf ik het probleem en dan gaan we verder. We komen later terug op de hotspots. We komen een gebeurtenis tegen die door meerdere deelnemers is aangemaakt. We houden degene die de gebeurtenis het beste beschrijft en verwijderen de anderen. We voegen ook takken toe voor voorwaardelijke gebeurtenissen. We plaatsen ze boven of onder de tijdlijn van het primaire proces.

Na tweeënhalf uur stoppen we. De tijdlijn is klaar en alle hotspots zijn opgelost. Iedereen heeft energie en we plannen meteen de volgende bijeenkomst om het proces duidelijker te maken door de gebeurtenissen te verrijken met metadata.

De gebeurtenissen verrijken met metadata

Het uitleggen van deze stap werkt het best met een afbeelding:

Aan het begin van ons (deel)proces (grote zwarte sticky note) moeten we actie ondernemen (blauwe sticky note) om het werk te verdelen. Hiervoor hebben we informatie nodig (groene sticky note) in de vorm van de user story waaraan we gaan werken. Jira is het systeem (grote roze sticky note) dat we hiervoor gebruiken. Als we klaar zijn, hebben we de user story opgedeeld in zogenaamde subtaken. Dat is een gebeurtenis (oranje sticky note). Het ontwikkelbeleid (grote paarse sticky note) vertelt ons vervolgens wat onze volgende actie is: een subtaak in Jira in voortgang zetten.

We volgen de tijdlijn en verrijken elke gebeurtenis. Als we niet zeker weten hoe we een gebeurtenis moeten verrijken met metadata, maken we een hotspot en gaan we verder. Later bekijken we alle hotspots opnieuw. Sommige hotspots kunnen we niet repareren. Bijvoorbeeld wanneer we het verhaal demonstreren, omdat dat afhankelijk is van de planning van belanghebbenden. Of wanneer we documentatie maken voor het verhaal omdat dat nog geen onderdeel is van ons proces. Dat is niet erg; we beschrijven gewoon de huidige situatie van ons proces. Maar het is wel iets wat we kunnen verbeteren!

Experiment succesvol afgerond

Iedereen is enthousiast over EventStorming en de resultaten die we ermee hebben behaald.

Ik had er vertrouwen in dat we een goed overzicht konden krijgen van het huidige ontwikkelproces door een EventStorm uit te voeren. Uiteindelijk hebben we inderdaad een duidelijk beeld van ons ontwikkelproces:

Het is nu eenvoudig om aan anderen uit te leggen wat ons huidige ontwikkelproces is. We weten ook dat we een aantal essentiële onderdelen missen in ons huidige proces.

Ik kan niet wachten om te beginnen met het modelleren van onze andere bedrijfsprocessen!