Slik bruker vi EventStorming for å gjøre prosessene våre tydelige

Som alle andre selskaper har vi mange prosesser hos Easy LMS. For eksempel hvordan vi håndterer supporthenvendelser eller utvikler nye funksjoner. Vi bruker Improvement Kata for å optimalisere prosessene våre. Et av de første stegene er å kartlegge nåsituasjonen. Det viser seg imidlertid at alle har sin egen oppfatning av hva nåsituasjonen er. EventStorming er en teknikk vi bruker for å definere prosessene våre på en entydig måte.

Tenk deg at du er nyansatt i en bedrift. Du blir satt sammen med et mer erfarent teammedlem og går gjennom alle forretningsprosessene, som for det meste er udokumenterte. Du skaper en mental modell av prosessen ved å stille spørsmål og lese dokumentasjon. Jo mer erfaring du får, jo færre spørsmål trenger du å stille, og jo mindre dokumentasjon trenger du å lese. Det meste gjør du (semi-)automatisk.

Mindre oppdatert dokumentasjon om en prosess vil føre til større variasjon i de mentale modellene de ansatte har av prosessen.

Hvis du deretter sammenligner hvordan du håndterer prosessen med et annet teammedlem, vil du legge merke til at dere gjør noen ting ganske annerledes. Dette skjer fordi de mentale modellene deres er forskjellige.

Når du optimaliserer en prosess ved hjelp av Improvement Kata, kan det være vanskelig å beskrive nåsituasjonen når de mentale modellene er svært forskjellige. Hvis vi bare hadde en måte å gjøre disse mentale modellene om til dokumentasjon.

Slik kom vi til EventStorming

Tidlig i 2020 deltok jeg på Domain-Driven Design Europ-konferansen for å lære mer om hvordan vi kan modellere programvaren vår bedre. En workshop jeg ønsket å delta på, handlet om EventStorming. Jeg hadde lest om det før, og jeg tenkte at det kunne hjelpe oss med å få domenespesifikk kunnskap ut av hodene til ekspertene våre på en måte som er enkel å dele med utviklerne. Det betyr at vi kan bygge bedre programvare. Det viste seg at EventStorming er svært nyttig for modellering av programvare, men også for modellering av forretningsprosesser!

Dessverre slo pandemien til. Vi stengte kontoret vårt og begynte å jobbe eksternt. EventStorming dreier seg om å ha en gruppe eksperter i et rom som jobber på en stor, felles flate. Dette var ikke lenger mulig å organisere. Heldigvis innså Alberto Brandolini, grunnleggeren av EventStorming, også dette og organiserte en annen workshop for å løse problemet: Remote EventStorming. Jeg ble med på den, og etterpå ventet jeg på en mulighet til å eksperimentere med EventStorming.

Modellering av utviklingsprosessen vår med EventStorming

I løpet av de siste månedene har vi endret utviklingsprosessen vår mye. Noen ganger sviktet prosessen, og det ble tydelig at ingen lenger hadde full oversikt over prosessen. Den perfekte kandidatprosessen å prøve EventStorming på!

Jeg forteller teamet at jeg ønsker å eksperimentere med EventStorming. Jeg er sikker på at vi kan få en god oversikt over den nåværende utviklingsprosessen ved å gjøre dette. Jeg inviterer et par interesserte utviklere fra begge teamene og oppretter en delt ekstern tavle ved hjelp av Miro. Vi følger standardtrinnene i EventStorming:

1. Kanotisk utforskning: lag huskelapper for alle hendelsene du kan komme på som skjer i prosessen.

2. Forsterk tidslinjen: ordne hendelsene fra begynnelsen av prosessen til slutten.

3. Berikelse av hendelsene: legg til metainformasjon til hver hendelse. Kommandoen (handlingen) som utløser hendelsen, dataene som trengs, systemet som handler, og policyen som sier hva som skal gjøres videre.

Kaotisk utforskning

Til å begynne med føles det litt rart. Men så snart de første lappene dukker opp, øker tempoet, og alle er med.

Vi starter med å gi alle deltakerne hver sin del av tavlen og en farge (men ikke oransje, mer om det senere). De har 25 minutter på seg til å sette opp lapper med alle de hendelsene de kan komme på som har skjedd i løpet av prosessen. En hendelse er noe som har skjedd i fortiden og som ikke lenger kan endres. Derfor skriver du dem ned i fortid. For eksempel "Koden er opprettet" eller "Koden er distribuert til produksjonsmiljøet".

Jeg oppfordrer dem til å "jukse" og se på hendelsene som andre deltakere har skrevet ned, for det kan åpne opp for en helt ny del av prosessen som man ikke hadde tenkt på før. Det er helt greit å legge til hendelser som andre deltakere også har.

Håndheving av tidslinjen

Når jeg ser at det ikke dukker opp noen nye lapper på tavlen, går vi videre til neste trinn. Jeg tegner en strek på tavlen. Så ber jeg alle om å ta sin lapp med den hendelsen som skjer først i utviklingsprosessen, og flytte den over tidslinjen. Vi diskuterer kort hvilken hendelse som egentlig er den første, og plasserer den i begynnelsen av tidslinjen. For å markere at vi alle er enige om denne hendelsen og dens plass på tidslinjen, endrer vi fargen på klistrelappen til oransje (det var derfor det ikke var noen klistrelapper i denne fargen før?). Deretter går vi videre til neste hendelse.

Vi går inn i en lengre diskusjon om en hendelse. For å holde flyten i gang lager jeg en spesiell type klistrelapper som kalles hotspot. På den beskriver jeg problemet, og så går vi videre. Vi kommer tilbake til hotspots senere. Vi støter på en hendelse som flere deltakere har opprettet. Vi beholder den som beskriver hendelsen best, og fjerner de andre. Vi legger også til grener for betingede hendelser. Vi plasserer dem over eller under tidslinjen til den primære prosessen.

Etter to og en halv time stopper vi. Tidslinjen er ferdig, og alle hotspots er løst. Alle er fulle av energi, og vi planlegger umiddelbart neste møte for å gjøre prosessen tydeligere ved å berike hendelsene med metadata.

Berike hendelsene med metadata

Dette trinnet forklares best med et bilde:

I starten av (del)prosessen (stor svart klistrelapp) må vi iverksette tiltak (blå klistrelapp) for å fordele arbeidet. For å gjøre dette trenger vi informasjon (grønn klistrelapp) i form av brukerhistorien vi skal jobbe med. Jira er systemet (stor rosa lapp) vi bruker til dette. Når vi er ferdige, har vi delt brukerhistorien inn i såkalte deloppgaver. Det er en hendelse (oransje klistrelapp). Utviklingspolicyen (stor lilla lapp) forteller oss da hva vi skal gjøre: å sette en deloppgave i fremdrift i Jira.

Vi følger tidslinjen og beriker hver eneste hendelse. Hvis vi er usikre på hvordan vi skal berike en hendelse med metadata, oppretter vi en hotspot og går videre. Senere går vi gjennom alle hotspots på nytt. Noen hotspots kan vi ikke fikse. For eksempel når vi demonstrerer historien, fordi det avhenger av interessentenes planlegging. Eller når vi lager dokumentasjon for historien fordi det ikke er en del av prosessen vår ennå. Det er ok; vi beskriver bare den nåværende situasjonen i prosessen vår. Men det er noe vi kan forbedre!

Eksperimentet fullført med suksess

Alle er begeistret for EventStorming og de resultatene vi har fått ut av det.

Jeg var sikker på at vi kunne få en god oversikt over den nåværende utviklingsprosessen ved å gjennomføre en EventStorm. Til slutt fikk vi faktisk et klart bilde av utviklingsprosessen vår:

Nå er det enkelt å forklare andre hvordan den nåværende utviklingsprosessen vår ser ut. Vi vet også at vi mangler noen viktige deler i den nåværende prosessen.

Jeg gleder meg til å begynne å modellere de andre forretningsprosessene våre!