Sådan bruger vi EventStorming til at gøre vores processer tydelige

Som enhver anden virksomhed har vi mange processer hos Easy LMS. For eksempel hvordan vi håndterer supporthenvendelser eller udvikler nye funktioner. Vi bruger Improvement Kata til at optimere vores processer. Et af de første skridt er at specificere den nuværende situation. Men det viser sig, at alle har deres egen opfattelse af, hvad den aktuelle situation er. EventStorming er en teknik, vi bruger til at definere vores processer entydigt.

Forestil dig, at du er en ny medarbejder i en virksomhed. Du bliver sat sammen med et mere erfarent teammedlem og gennemgår alle, for det meste udokumenterede, forretningsprocesser. Du skaber en mental model af processen ved at stille spørgsmål og læse dokumentation. Jo mere erfaring du får, jo færre spørgsmål skal du stille, og jo mindre dokumentation skal du læse. De fleste ting gør du (semi-)automatisk.

Mindre opdateret dokumentation af en proces vil føre til større variation i de mentale modeller, som medarbejderne har af den pågældende proces.

Hvis du så sammenligner, hvordan du håndterer processen med et andet teammedlem, vil du opdage, at I gør nogle ting helt forskelligt. Det sker, fordi jeres mentale modeller er forskellige.

Når man optimerer en proces ved hjælp af Improvement Kata, kan det være svært at beskrive den aktuelle situation, når de mentale modeller er meget forskellige. Hvis bare vi havde en måde at omdanne disse mentale modeller til dokumentation.

Hvordan vi kom til EventStorming

I begyndelsen af 2020 deltog jeg i Domain-Driven Design Europ-konferencen for at lære mere om at modellere vores software bedre. En af de workshops, jeg gerne ville deltage i, handlede om EventStorming. Jeg har læst om det før, og jeg tænkte, at det kunne hjælpe os med at få domænespecifik viden ud af vores eksperters hoveder på en måde, der er nem at dele med udviklerne. Det betyder, at vi kan bygge bedre software. Det viste sig, at EventStorming er meget nyttigt til modellering af software, men også til modellering af forretningsprocesser!

Desværre ramte pandemien. Vi lukkede vores kontor og begyndte at arbejde eksternt. EventStorming handler om at have en gruppe eksperter i et rum, der arbejder på en stor fælles overflade. Det var ikke længere muligt at organisere. Heldigvis indså Alberto Brandolini, grundlæggeren af EventStorming, også dette og organiserede en anden workshop for at løse problemet: Remote EventStorming. Jeg deltog i den og ventede bagefter på en mulighed for at eksperimentere med EventStorming.

Modellering af vores udviklingsproces med EventStorming

I de sidste par måneder har vi ændret meget på vores udviklingsproces. Nogle gange slog processen fejl, og det blev tydeligt, at ingen længere havde det fulde overblik over processen. Den perfekte kandidatproces til at prøve EventStorming på!

Jeg fortæller teamet, at jeg gerne vil eksperimentere med EventStorming. Jeg er sikker på, at vi kan få et godt overblik over den nuværende udviklingsproces ved at gøre dette. Jeg inviterer et par interesserede udviklere fra begge teams og opretter et fælles fjernwhiteboard ved hjælp af Miro. Vi følger standardtrinnene i EventStorming:

1. Khaotisk udforskning: Lav klistermærker til alle de begivenheder, du kan komme i tanke om, der sker i processen.

2. Forstærk tidslinjen: Bestil begivenhederne fra begyndelsen af processen til slutningen.

3. Berigelse af begivenhederne: Tilføj metainformation til hver begivenhed. Den kommando (handling), der udløser hændelsen, de nødvendige data, det system, der handler, og den politik, der siger, hvad der skal gøres som det næste.

Kaotisk udforskning

I starten føles det lidt akavet. Men så snart de første klistermærker dukker op, kommer tempoet virkelig op, og alle er med.

Vi starter med at give alle deltagere deres egen del af whiteboardet og en farve (men ikke orange, mere om det senere). De har 25 minutter til at lave klistermærker til alle de begivenheder, de kan komme i tanke om, der sker i løbet af processen. En begivenhed er noget, der er sket i fortiden, og som ikke længere kan ændres. Det er derfor, man skriver dem ned i datid. F.eks: "Code repository created" eller "Code deployed to the production environment."

Jeg opfordrer dem til at "snyde" og se på de begivenheder, som andre deltagere har skrevet ned, for det kan åbne op for en helt ny del af processen, som man ikke havde tænkt på før. Det er helt i orden at tilføje begivenheder, som andre deltagere også har.

Håndhævelse af tidslinjen

Når jeg har bemærket, at der ikke kommer nye klistermærker på tavlen, går vi videre til næste trin. Jeg tegner en linje på whiteboardet. Så beder jeg alle om at tage deres seddel med den begivenhed, der sker først i udviklingsprocessen, og flytte den over tidslinjen. Vi diskuterer kort, hvilken begivenhed der virkelig er den første, og placerer den i begyndelsen af tidslinjen. For at vise, at vi alle er enige om denne begivenhed og dens plads på tidslinjen, ændrer vi farven på klistermærket til orange (det var derfor, der ikke var nogen klistermærker i denne farve før ?). Så går vi videre til den næste begivenhed.

Vi kommer ind på en længere diskussion om en begivenhed. For at holde flowet i gang laver jeg en særlig type klistermærke, der kaldes et hotspot. På den beskriver jeg problemet, og så går vi videre. Vi vender tilbage til hotspots senere. Vi støder på en begivenhed, som flere deltagere har skabt. Vi beholder den, der beskriver begivenheden bedst, og fjerner de andre. Vi tilføjer også grene til betingede begivenheder. Vi placerer dem over eller under tidslinjen for den primære proces.

Efter to en halv time stopper vi. Tidslinjen er færdig, og alle hotspots er løst. Alle er fulde af energi, og vi planlægger straks næste møde for at gøre processen klarere ved at berige begivenhederne med metadata.

Berigelse af begivenhederne med metadata

At forklare dette trin fungerer bedst med et billede:

I starten af vores (del)proces (stor sort klæbeseddel) skal vi handle (blå klæbeseddel) for at fordele arbejdet. For at gøre det har vi brug for information (grøn seddel) i form af den brugerhistorie, vi skal arbejde med. Jira er det system (stor pink seddel), vi bruger til dette. Når vi er færdige, har vi delt brugerhistorien op i såkaldte sub-tasks. Det er en begivenhed (orange klistermærke). Udviklingspolitikken (stor lilla seddel) fortæller os så, hvad vi skal gøre: sætte en underopgave i gang i Jira.

Vi følger tidslinjen og beriger hver eneste begivenhed. Hvis vi er usikre på, hvordan vi skal berige en begivenhed med metadata, opretter vi et hotspot og går videre. Senere genbesøger vi alle hotspots. Nogle hotspots kan vi ikke fikse. For eksempel når vi demonstrerer historien, fordi det afhænger af interessenternes planlægning. Eller når vi laver dokumentation for historien, fordi det ikke er en del af vores proces endnu. Det er ok; vi beskriver bare den nuværende situation i vores proces. Men det er noget, vi kan forbedre!

Eksperiment gennemført med succes

Alle er begejstrede for EventStorming og de resultater, vi har fået ud af det.

Jeg var sikker på, at vi kunne få et godt overblik over den nuværende udviklingsproces ved at lave en EventStorm. I sidste ende har vi faktisk et klart billede af vores udviklingsproces:

Det er nu nemt at forklare andre, hvordan vores nuværende udviklingsproces ser ud. Vi ved også, at vi mangler nogle vigtige dele i vores nuværende proces.

Jeg kan ikke vente med at begynde at modellere vores andre forretningsprocesser!