Hur vi använder EventStorming för att tydliggöra våra processer

Liksom alla andra företag har vi många processer på Easy LMS. Till exempel hur vi hanterar supportärenden eller utvecklar nya funktioner. Vi använder Improvement Kata för att optimera våra processer. Ett av de första stegen är att specificera den nuvarande situationen. Det visar sig dock att alla har sin egen syn på vad den aktuella situationen är. EventStorming är en teknik som vi använder för att definiera våra processer på ett entydigt sätt.

Tänk dig att du är nyanställd på ett företag. Du paras ihop med en mer erfaren teammedlem och går igenom alla affärsprocesser, som oftast är odokumenterade. Du skapar en mental modell av processen genom att ställa frågor och läsa dokumentation. Ju mer erfarenhet du får, desto färre frågor behöver du ställa och desto mindre dokumentation behöver du läsa. Det mesta kommer du att göra (halv)automatiskt.

Mindre uppdaterad dokumentation om en process leder till större variation i de mentala modeller som medarbetarna har av den processen.

Om du sedan jämför hur du hanterar processen med en annan teammedlem kommer du att märka att ni gör vissa saker på helt olika sätt. Detta beror på att era mentala modeller skiljer sig åt.

När man optimerar en process med hjälp av Improvement Kata kan det vara svårt att beskriva nuläget när de mentala modellerna skiljer sig åt markant. Om vi ändå hade ett sätt att omvandla dessa mentala modeller till dokumentation.

Hur vi kom till EventStorming

I början av 2020 deltog jag i Domain-Driven Design Europ-konferensen för att lära mig mer om hur vi kan modellera vår programvara bättre. En workshop som jag ville gå med i handlade om EventStorming. Jag läste om det tidigare och jag trodde att det kunde hjälpa oss att få domänspecifik kunskap ur våra experters huvuden på ett sätt som är lätt att dela med utvecklarna. Vilket skulle betyda att vi kunde bygga bättre programvara. Det visade sig att EventStorming är mycket användbart för att modellera programvara, men också för att modellera affärsprocesser!

Tyvärr drabbades vi av pandemin. Vi stängde vårt kontor och började arbeta på distans. EventStorming går ut på att ha en grupp experter i ett rum som arbetar på en stor gemensam yta. Detta var inte längre möjligt att organisera. Lyckligtvis insåg Alberto Brandolini, grundaren av EventStorming, också detta och organiserade en annan workshop för att lösa detta problem: Remote EventStorming. Jag deltog i den och väntade sedan på ett tillfälle att få experimentera med EventStorming.

Modellering av vår utvecklingsprocess med EventStorming

Under de senaste månaderna har vi förändrat vår utvecklingsprocess en hel del. Ibland misslyckades processen, och det blev uppenbart att ingen längre hade en total överblick över processen. Den perfekta kandidatprocessen att prova EventStorming på!

Jag berättar för teamet att jag vill experimentera med EventStorming. Jag är övertygad om att vi kan få en bra överblick över den nuvarande utvecklingsprocessen genom att göra detta. Jag bjuder in ett par intresserade utvecklare från båda teamen och skapar en delad fjärrwhiteboard med Miro. Vi följer standardstegen i EventStorming:

1. Kootisk utforskning: skapa klisterlappar för alla händelser du kan tänka dig som händer i processen.

2. Förstärk tidslinjen: ordna händelserna från början av processen till slutet.

3. Berika händelserna: lägg till metainformation till varje händelse. Kommandot (åtgärden) som utlöser händelsen, de data som behövs, systemet som agerar och policyn som säger vad som ska göras härnäst.

Kaotisk utforskning

Till en början känns det lite tafatt. Men så fort de första klisterlapparna dyker upp ökar tempot rejält och alla är med på noterna.

Vi börjar med att ge alla deltagare en egen bit av whiteboardtavlan och en färg (men inte orange, mer om det senare). De har 25 minuter på sig att skapa klisterlappar för alla händelser de kan komma på som inträffar under processen. En händelse är något som har hänt i det förflutna och som inte längre kan ändras. Det är därför man skriver ner dem i förfluten tid. Till exempel "Kodförvar skapades" eller "Kod distribuerades till produktionsmiljön."

Jag uppmuntrar dem att "fuska" och titta på de händelser som andra deltagare skriver ner eftersom det kan öppna upp en helt ny del av processen som du inte tänkt på tidigare. Det är helt okej att lägga till händelser som andra deltagare också har.

Verkställighet av tidslinjen

När jag märker att inga nya klisterlappar dyker upp på tavlan går vi vidare till nästa steg. Jag drar en linje på whiteboardtavlan. Sedan ber jag alla att plocka sin lapp med den händelse som inträffar först i utvecklingsprocessen och flytta den över tidslinjen. Vi diskuterar kort vilken händelse som verkligen är den första och placerar den i början av tidslinjen. För att markera att vi alla är överens om denna händelse och dess plats på tidslinjen ändrar vi färgen på lappen till orange (det var därför det inte fanns några lappar i den färgen tidigare?) Sedan går vi vidare till nästa händelse.

Vi kommer in på en mer omfattande diskussion om en händelse. För att hålla igång flödet skapar jag en speciell typ av klisterlapp som kallas hotspot. På den beskriver jag problemet och sedan går vi vidare. Vi återkommer till hotspots senare. Vi stöter på en händelse som flera deltagare skapade. Vi behåller den som beskriver händelsen bäst och tar bort de andra. Vi lägger också till grenar för villkorliga händelser. Vi placerar dem över eller under tidslinjen för den primära processen.

Efter två och en halv timme slutar vi. Tidslinjen är klar och alla hotspots är lösta. Alla har fått ny energi och vi planerar omedelbart nästa möte för att göra processen tydligare genom att berika händelserna med metadata.

Berika evenemangen med metadata

Det här steget förklaras bäst med hjälp av en bild:

I början av vår (del)process (stor svart klisterlapp) måste vi vidta åtgärder (blå klisterlapp) för att dela upp arbetet. För att göra detta behöver vi information (grön klisterlapp) i form av den user story vi ska arbeta med. Jira är det system (stor rosa klisterlapp) vi använder för detta. När vi är klara har vi delat in user storyn i så kallade sub-tasks. Det är en händelse (orange klisterlapp). Utvecklingspolicyn (stor lila klisterlapp) talar då om för oss vad vi ska göra härnäst: lägga in en deluppgift i progress i Jira.

Vi följer tidslinjen och berikar varje händelse. Om vi är osäkra på hur vi ska berika en händelse med metadata skapar vi en hotspot och går vidare. Senare går vi igenom alla hotspots igen. Vissa hotspots kan vi inte åtgärda. Till exempel när vi demonstrerar storyn, eftersom det beror på intressenternas planering. Eller när vi skapar dokumentation för storyn eftersom det inte är en del av vår process ännu. Det är okej; vi beskriver bara den nuvarande situationen i vår process. Men det är något vi kan förbättra!

Experimentet slutfört framgångsrikt

Alla är entusiastiska över EventStorming och de resultat vi fick ut av det.

Jag var övertygad om att vi skulle kunna få en bra överblick över den nuvarande utvecklingsprocessen genom att göra en EventStorm. I slutändan har vi verkligen en tydlig bild av vår utvecklingsprocess:

Det är nu lätt att förklara för andra hur vår nuvarande utvecklingsprocess ser ut. Vi vet också att vi saknar vissa väsentliga delar i vår nuvarande process.

Jag längtar efter att få börja modellera våra andra affärsprocesser!