Event Storming & Domain Storytelling

HOE KOM JE SNELLER TOT KWALITATIEVE RESULTATEN BIJ SOFTWAREPROJECTEN?

Bij het automatiseren van bedrijfsprocessen is het altijd de bedoeling dat de gebruikers efficiënter kunnen werken. Hun werk moet dankzij de nieuwe software sneller verlopen zodat ze bijvoorbeeld productiever zijn of klanten nog beter kunnen helpen.

Intussen weten we allemaal dat IT op zich geen doel is maar altijd de business moet ondersteunen en faciliteren. Toch loopt het bij ontwikkelprojecten soms nog mis doordat business en IT niet van bij de start dezelfde taal spreken.

Het gevolg is dat pas later in het project wordt ontdekt waar bepaalde problemen zitten waar de nieuwe toepassing een antwoord op moet bieden. De ontwikkelaars moeten de code dan gaan aanpassen zodat het project langer aansleept dan nodig.

Event storming en domain storytelling bieden een antwoord op dit probleem. Je gaat dan meteen snel maar grondig ontleden wat er van de nieuwe software wordt verwacht. In deze whitepaper leggen we uit hoe je dat doet.

KERNBEGRIPPEN

Domain Driven Design

Een ‘domein’ is de bedrijfsactiviteit waarvoor een toepassing wordt ontwikkeld. Dat kan bijvoorbeeld ‘verkoop’ zijn. Een domein is meestal ook nog onderverdeeld in subdomeinen. Domain Driven Design vertrekt bij de ontwikkeling vanuit de reële situaties die in een domein belangrijk zijn.

Een gemeenschappelijke taal

Bij Domain Driven Design is het heel belangrijk dat je een gemeenschappelijke taal ontwikkelt. Iedereen die bij het project betrokken is – zowel de ontwikkelaar en de businessverantwoordelijke als de analist, de tester en de marketingmedewerkers, bijvoorbeeld. Zij moeten allemaal dezelfde terminologie gebruiken zodat iedereen weet waarover je spreekt. De ontwikkelaar zal dus in de softwarecode voor het binnenhalen van een bestelling een term gebruiken die herkenbaar is voor de sales. Zo vermijd je heel wat misverstanden, kan je als developer veel sneller beginnen programmeren en is de code achteraf veel duidelijker.

One man, one marker

Bij de klassieke meeting staat vooraan één persoon die het woord voert en noteert op een flipchart of whiteboard. Je kan ook een interactieve meeting organiseren, waarbij je eerst in kleine groepjes discussieert. Elk groepje formuleert een mening of oplossing en de persoon vooraan noteert die. Het probleem daarbij is dat binnen de groepjes sommige personen dominanter zijn dan anderen, zodat hun stem meer wordt gehoord. Andere, even nuttige meningen gaan op die manier verloren. De uitkomst van zo’n meeting valt daardoor altijd wat tegen omdat niet iedereen zijn mening aan bod komt en je niet tot de verwachte resultaten komt.

Daarnaast heb je bij meetings ook de verborgen kost van de ‘depleted marker’-situatie: de persoon vooraan wil iets noteren maar de stift blijkt niet meer goed te schrijven. De flow van de meeting wordt compleet gebroken om een nieuwe stift te zoeken. Heel verdwijnt op dat moment de focus bij de deelnemers. Als er tien deelnemers zijn en het duurt tien minuten om een nieuwe stift te vinden, dat gaan tien keer tien minuten verloren – veel kostbare tijd voor een simpele stift. Het lijkt voor de hand te liggen, maar het is een herkenbare situatie die je absoluut moet vermijden.

EVENT STORMING

Bij event storming organiseer je een vergadering waar iedereen samen gaat nadenken over de probleemstelling van je domein en dat ook gaat visualiseren. Zo gaat het coderen achteraf een stuk sneller: je weet al veel beter waar je naartoe wil.

Wat is event storming?

Event storming is een manier om processen te modelleren aan de hand van een tijdlijn met ‘events’ – gebeurtenissen of acties die geautomatiseerd kunnen worden, zoals ‘een bestelling is geplaatst’ of ‘de bestelling is bevestigd’. Er bestaat geen best practice voor event storming en er zijn geen vaste regels om te volgen. Wel zijn er richtlijnen die je moet aanpassen aan jouw noden, jouw eigen team en processen.

Verwacht vooral heel veel post-its. Dit is geen gewone meeting maar een workshop. Een eerste event storming-sessie verloopt vaak wat chaotisch, maar op termijn zal je er steeds beter in slagen om orde te creëren en doelgericht te werken.

Types event storming

Aangezien er geen vaste regels bestaan voor event storming, zijn er veel verschillende soorten. Je kan ze onderbrengen in twee categorieën: ‘big picture’ en ‘design level’.

Big Picture is event storming op grote schaal, in een grote ruimte met veel mensen – tot zelfs 20 deelnemers. Je brengt daarbij je volledige business in kaart, precies daarom zijn er veel mensen nodig. Je hoort dus ook veel meningen. De bedoeling is om de grootste probleemgebieden en risico’s in je hele flow duidelijk te maken en misschien ook al nieuwe oplossingen en ideeën naar voor te brengen.

Design level meetings zijn helemaal anders. Ze verlopen op veel kleinere schaal, met een veel kleiner aantal mensen omdat je focust op één ‘key feature’. Zo kunnen de deelnemers bijvoorbeeld alleen de mensen van het development team en de domain experts zijn. De bedoeling is om één aspect van het domein helemaal uit te tekenen voor er iets van code is geschreven. Achteraf ontwikkel je zo snel mogelijk een prototype of POC (proof of concept) dat je kan aftoetsen aan hetgeen je hebt uitgetekend.

Big picture event storming is duidelijk veel complexer en levert niet meteen tastbare resultaten op. Het voordeel van deze vorm van event storming is vooral dat je de vinger legt op de problemen en dus op de prioriteiten die je als development team eerst moet aanpakken.

EVENT STORMING IN ZEVEN STAPPEN

Stap 1: Voorbereiding

De deelnemers

Je nodigt drie types mensen uit:

• Een facilitator of moderator: leidt alles in goede banen. Hoeft zelf niet alles te kennen.
• Mensen met vragen
• Mensen met antwoorden

De ‘mensen met vragen’ en de ‘mensen met antwoorden’ zijn natuurlijk geen afgelijnde categorieën. Sommigen weten bijvoorbeeld zowat alles over een bepaald onderdeel dus die experts moet je er zeker bij halen. Tegelijk betrek je bij de sessie ook de mensen die nieuw zijn en met de software zullen werken. Soms komen zij met antwoorden die de expert nooit had bedacht.

Zorg er in ieder geval voor dat de deelnemers een andere achtergrond hebben – van verschillende afdelingen komen of andere expertise en inzichten hebben. Dat zal je resultaat achteraf ten goede komen. Je combineert sowieso technische profielen met businessmensen.

De ruimte

Heel belangrijk voor je event storming is een groot werkvlak, liefst een rol wit papier die je ophangt. Je hebt minstens 8 meter nodig. Een alternatief is gewoon werken op de muur met statische post-its.

Naast je werkvlak maak je op voorhand een goed zichtbare legende. Vaak is dat een flipchart die ernaast staat. In de legende hangen de verschillende kleuren post-its die je zal gebruiken, met daarnaast te uitleg waarvoor ze dienen. Zo kan je bijvoorbeeld oranje nemen voor ‘events’ en blauw voor ‘commands’.

Post-its en stiften

Post-its heb je in grote hoeveelheden en in verschillende kleuren nodig. Zorg liefst een paar honderd post-its.

Geef elke deelnemers minstens één stift en voorzie ook drie tot vijf extra stiften als reserve om te vermijden dat je tijdens de sessie nog stiften moet halen – de ‘depleted marker’-situatie.

Meubels

Als organisator moet je als eerste aanwezig zijn. Schuif de tafel en stoelen aan de kant en stapel eventueel de stoelen op elkaar. Het is namelijk niet de bedoeling dat iedereen na binnenkomst gaat zitten. Misschien voelen de deelnemers zich eerst wat onwennig omdat ze moeten blijven staan maar dat is net stimulerend. Bij lange sessies kan je de stoelen wel bij de hand houden.

Eten en drinken

Zorg, zeker bij lange sessies, voor iets gezonds om te eten en te drinken, zoals water en fruit. Mensen denken beter na als ze aan het eten zijn en als ze iets kunnen vastnemen.

Stap 2: Start

Bij de start van de workshop geeft de moderator een korte introductie waarbij hij of zij uitlegt wat het doel is dat je met de sessie wil proberen te bereiken. Je vertelt dus dat jullie ‘events’ op het werkvlak gaan ophangen, op een tijdlijn zetten en daarmee de business of een bepaald feature zullen proberen mappen. Daarna zal je ideeën en mogelijke problemen vinden en die er ook bij hangen.

Je introductie en je uitleg van het probleem dat je wil oplossen moeten heel kort zijn, niet langer dan een paar minuten.

Daarna ga je echt van start. Je deelt aan iedereen post-its en een stift uit en je spreekt een paar regels af, bijvoorbeeld dat een oranje post-it dient voor een event. Je vraagt aan iedereen om de events op te schrijven die volgens hen gaan gebeuren. Belangrijke richtlijnen zijn dat de werkwoorden in de verleden tijd moeten staan en dat iedereen relevante termen (een gemeenschappelijk taal) gebruikt.

De bedoeling is dat de deelnemers hier niet te lang over nadenken en snel beginnen schrijven. Veel mensen voelen zich daar wat ongemakkelijk bij en weten niet waar te beginnen. Nadat iemand de eerste post-it heeft opgehangen is het ijs gebroken. Als dat te lang duurt, kan je als moderator wat gaan sturen door iets te zeggen en eventueel zelf het eerste event op te hangen. Daarna is het aan de deelnemers.

Stap 3: De tijdlijn groeit

Als mensen in deze fase onderling beginnen te discussiëren, breek dat dan af en vraag om alleen, in stilte te werken. Iedereen hangt de events gewoon kriskras door elkaar op het blad. Er zijn geen foute events. Elke discussie is verloren want die wordt niet opgehangen.

Je evolueert naar een tijdlijn met events. Op een bepaald moment valt het wat stil en stoppen de deelnemers geleidelijk met schrijven. Vaak zetten ze een stap achteruit om het geheel te bekijken. Ze kijken dan ook naar de post-its die anderen hebben opgehangen.

Het typische beeld is een aantal clusters van post-its die niet georganiseerd zijn in het totale plaatje.

Stap 4: De tijdlijn organiseren

Tijdens deze fase ga je de dubbele events verwijderen en de resterende post-its sorteren. Dat leidt steevast tot – vaak verhitte – discussies over allerlei details zoals een benaming. Deze discussies zijn zeker nuttig want ze wijzen op problemen of inconsistenties die naar boven komen. Door ze zichtbaar te maken op de tijdlijn wordt er nu over gepraat in plaats van ze te vergeten of weg te moffelen.

Probeer om logica te krijgen in je ruwe tijdlijn door de events te sorteren van links naar rechts. Om efficiënter te sorteren, kan je een van deze strategieën volgen:

• Pivotal elements: Markeer de belangrijkste events in de flow met gekleurde tape. Dat zijn normaal gezien de events waarin het grootste aantal mensen in de zaal geïnteresseerd is. Bijvoorbeeld: een order dat geplaatst is, is interessant voor de marketing, de boekhouding en de verscheping. Daarna kan je de resterende events makkelijker sorteren.
• Swimlanes: Maak horizontale onderverdelingen per afdeling of per ‘actor’ (de persoon die de actie uitvoert in het event). Het voordeel van deze aanpak is dat je tijdlijn hiermee heel leesbaar wordt dankzij de lijnen. Het nadeel is dat je veel plaats nodig hebt, vooral verticaal. De verdeling in ‘zwembanen’ is daarom vooral handig voor het weergeven van één proces/key feature of nadat je eerst al een voorlopige structuur hebt gemaakt die je daarna nog eens verdeelt in zwembanen.
• Temporal milestones: zijn vooral nuttig als je veel gelijktijdige processen hebt. Je hoort dan discussies tussen de deelnemers over de precieze volgorde van de gebeurtenissen. Je kan dan bijvoorbeeld met blauwe post-its bovenaan je werkblad belangrijke events aanduiden die bv. een maand geleden of een jaar geleden gebeurd zijn – aan te passen aan je business of probleemdomein. Op die manier creëer je ‘tijdvakken’ waarbinnen je je events sorteert –zonder heel strikte chronologie, zodat je veel minder discussie hebt over de exacte volgorde.
• Chapters sorting: wordt vooral gebruikt wanneer je te weinig te plaats hebt in je kamer of op je werkblad omdat je heel veel events hebt. Je sorteert dan niet alles in één keer maar je gaat eerst de belangrijkste ‘chapters’ eruithalen. Die sorteer je op een apart vlak – dat kan een tafel of de vloer zijn. Daarna sorteer je de rest op dezelfde manier.

Stap 5: Verbanden en problemen ontdekken

Zoek de oorzaak van events

Wanneer je tijdlijn gesorteerd is, ga je bepalen wat er gebeurt vóór het event. Bijvoorbeeld: wat is de oorzaak van ‘een order is geplaatst’? Er zijn dan verschillende mogelijkheden:

1. Een ‘command’: een actie door een gebruiker, bv. iemand klikt op de website op een knop ‘plaats bestelling’. Je schrijft de commands op een blauwe post-it.
2. Het komt van een extern systeem, bv. een betaling met PayPal. Dit schrijf je op een roze post-it.
3. Het is een gevolg van de tijd die verstrijkt – iets wat om de zoveel tijd automatisch gebeurt. Daarvoor teken je een icoontje op je event met het tijdsinterval bv. 30 minuten.
4. Een reactie op een ander event. Je gebruikt dan een witte post-it die je tussen de twee events kleeft (als/dan).

Hotspots aanduiden

Door bepaalde flows te visualiseren ontdek je bovendien ‘hotspots’ waar er frictie zit en die je ook gaat aanduiden in de business flow. Mensen in de zaal laten merken wanneer een bepaalde flow niet goed werkt. Er komen daarover opmerkingen, die ze op post-its schrijven en bij de hotspot kleven. De problemen en ook de mogelijke oplossingen of ideeën schrijven ze op post-its in verschillende kleuren.

Stap 6: Alles checken

Walk through

Dit is nog niet het einde van de sessie. Vraag iemand om door de flow te gaan door ook fysiek langs het blad te stappen en te vertellen wat ze zien en wat er telkens gebeurt. Wanneer ze haperen of moeten teugkeren, ontdek je waar de flow nog niet juist gesorteerd is. Onderbreek degene die vooraan staat, vraag en toets of alles wel juist staat. Test het verhaal dat verteld wordt en sorteer alles nu heel goed. Het gedeelte links van de spreker staat dan al juist, terwijl het rechterdeel nog beter gesorteerd moet worden.

Reverse narrative

Wanneer dat gebeurd is, doorloop je de flow achterstevoren. Is hetgeen wat staat vóór het event dat achteraan staat, echt alles wat moet gebeuren om daarin te resulteren? Zo zie je het grote plaatje beter en kan je vaak nog events bij de tijdlijn hangen.

Via de techniek van ‘reverse narrative’ of achterstevoren vertellen zet je de deelnemers aan om anders te denken en ontdek je of er nog ‘magische hiaten’ in de flow zitten.

Stap 7: Resultaat

Uiteindelijk kom je tot een heel duidelijk en samenhangend businessverhaal dat alle mensen in de zaal begrijpen. De nieuwelingen krijgen een beeld van hoe de business werkt en hoe de flow in elkaar zit, de experts ontdekken vaak dingen waaraan ze nog niet hadden gedacht of die ze nog niet wisten. Wanneer je in een Big Picture-sessie je hele business hebt gemapt, zie je ook welk domein je het eerst moet aanpakken om een oplossing te vinden en waar het in de bestaande situatie vaak foutloopt. Dat is iets wat je heel moeilijk uit gewone meetings haalt.

DOMAIN STORYTELLING

Domain storytelling sluit deels aan bij event storming. Je leert daarbij je domein of taal kennen door een verhaal te vertellen en door te luisteren. Terwijl je luistert, schrijf je alles pictografisch op, zodat je snel kan volgen. Je stelt ook meteen heel veel vragen en je vraagt feedback van degene(n) met wie je praat.

Een voorbeeld: je wil als developer een online ticketingsysteem creëren. Je praat daarvoor met een werknemer, de manager en de beheerder van het bestaande ticketingsysteem.

Je stelt eerst wat vragen, je leert je domein kennen en je praat kort over hetgeen de applicatie moet kunnen doen, vertrekkend van het concrete gebruik. Teken/schrijf voor elke ‘usecase’ een diagram of flow chart.

Stel dat het gaat over het scenario om een ticket te kopen. De vraag is dan: ‘Wat gebeurt er vandaag? Hoe kan iemand een ticket bestellen?’ Het antwoord: ‘De klanten komen langs, ze bellen of mailen.’ Je neemt hieruit de manier waarmee er de meeste tijd verloren gaat: wanneer mensen fysiek naar het loket komen voor een ticket. Hoe gebeurt dat vandaag? Gebruik bij je beschrijving de correcte namen die in de organisatie door iedereen gekend zijn. Als bijvoorbeeld een kassier in de dierentuin ‘ticket giraffe’ wordt genoemd, schrijf dat dan ook zo op en gebruik de taal van de business.

Door mensen te laten vertellen over de manier waarop het proces vandaag verloopt, ontdek je waar problemen zitten zoals te veel onoverzichtelijke info voor de klant. Je kan ook al mogelijke oplossingen noteren die nog te onderzoeken zijn, zoals een brochure ophangen aan het loket of een extra scherm installeren dat je naar de klant kan draaien om informatie te tonen.

Als alle aanwezigen akkoord gaan met de ‘domain story’ die je hebt uitgetekend, zit je goed. Daarna bekijk je je initiële diagram. Vaak kan je daarin al een aantal lijnen schrappen, want niet elk scenario is met alle systemen gelinkt. Zo behandel je elke usecase.

De bedoeling is dat je zoveel mogelijk weet vóór je als developer je code begint te schrijven. Pas wanneer je een volledig beeld hebt van de manier waarop de toepassing in de praktijk moet functioneren, begin je te programmeren.

CONCLUSIE

Door vooraf zoveel mogelijk visueel uit te tekenen, kan je de ontwikkeltijd van een nieuwe applicatie aanzienlijk verkorten. Je weet dan veel beter hoe het eindresultaat eruit moet zien en je hoeft als developer achteraf veel minder wijzigingen door te voeren. Door de business van bij het begin intensief bij het project te betrekken, werkt iedereen naar hetzelfde doel zodat ook de communicatie veel vlotter verloopt.