Wie wir EventStorming nutzen, um unsere Prozesse klar zu machen

Wie jedes andere Unternehmen haben auch wir bei Easy LMS viele Prozesse. Zum Beispiel, wie wir Support-Tickets bearbeiten oder neue Funktionen entwickeln. Wir verwenden das Verbesserungs-Kata um unsere Prozesse zu optimieren. Einer der ersten Schritte besteht darin, die aktuelle Situation zu bestimmen. Es stellt sich jedoch heraus, dass jeder seine eigene Auffassung von der aktuellen Situation hat. EventStorming ist eine Technik, die wir einsetzen, um unsere Prozesse eindeutig zu definieren.

Stellen Sie sich vor, Sie sind ein neuer Mitarbeiter in einem Unternehmen. Sie werden mit einem erfahreneren Teammitglied zusammengebracht und gehen alle, meist nicht dokumentierten, Geschäftsprozesse durch. Sie erstellen ein mentales Modell des Prozesses, indem Sie Fragen stellen und die Dokumentation lesen. Je mehr Erfahrung Sie sammeln, desto weniger Fragen müssen Sie stellen und desto weniger Dokumentation müssen Sie lesen. Die meisten Dinge werden Sie (halb-)automatisch erledigen.

Eine weniger aktuelle Dokumentation eines Prozesses führt zu mehr Variationen in den mentalen Modellen, die die Mitarbeiter von diesem Prozess haben.

Wenn Sie dann vergleichen, wie Sie den Prozess mit einem anderen Teammitglied handhaben, werden Sie feststellen, dass Sie einige Dinge ganz anders machen. Das liegt daran, dass sich Ihre mentalen Modelle unterscheiden.

Wenn Sie einen Prozess mit Hilfe der Verbesserungs-Kata optimieren, kann es schwierig sein, die aktuelle Situation zu beschreiben, wenn sich die mentalen Modelle erheblich unterscheiden. Wenn wir nur eine Möglichkeit hätten, diese mentalen Modelle in eine Dokumentation umzuwandeln.

Wie wir zu EventStorming gekommen sind

Anfang 2020 besuchte ich die Domain-Driven Design Europ Konferenz, um mehr über die bessere Modellierung unserer Software zu erfahren. Ein Workshop, an dem ich teilnehmen wollte, handelte von EventStorming. Ich hatte schon vorher darüber gelesen und dachte, dass es uns helfen könnte, domänenspezifisches Wissen aus den Köpfen unserer Experten herauszuholen, und zwar auf eine Art und Weise, die leicht an die Entwickler weitergegeben werden kann. Das heißt, wir könnten bessere Software entwickeln. Es stellte sich heraus, dass EventStorming sehr nützlich für die Modellierung von Software, aber auch für die Modellierung von Geschäftsprozessen ist!

Leider schlug die Pandemie zu. Wir schlossen unser Büro und begannen aus der Ferne zu arbeiten. Bei EventStorming geht es darum, eine Gruppe von Experten in einem Raum zu haben, die an einer großen gemeinsamen Oberfläche arbeiten. Das war nicht mehr zu organisieren. Glücklicherweise erkannte dies auch Alberto Brandolini, der Gründer von EventStorming, und organisierte einen weiteren Workshop, um dieses Problem zu lösen: Remote EventStorming. Ich nahm daran teil und wartete danach auf eine Gelegenheit, mit EventStorming zu experimentieren.

Modellierung unseres Entwicklungsprozesses mit EventStorming

In den letzten Monaten haben wir unseren Entwicklungsprozess stark verändert. Manchmal scheiterte der Prozess, und es wurde deutlich, dass niemand mehr den vollen Überblick über den Prozess hatte. Der perfekte Kandidatenprozess, um EventStorming auszuprobieren!

Ich sage dem Team, dass ich mit EventStorming experimentieren möchte. Ich bin zuversichtlich, dass wir auf diese Weise einen guten Überblick über den aktuellen Entwicklungsprozess bekommen können. Ich lade ein paar interessierte Entwickler aus beiden Teams ein und erstelle mit Miro ein gemeinsames Remote-Whiteboard. Wir folgen den Standardschritten von EventStorming:

1. Chaotische Erkundung: Erstellen Sie Haftnotizen für alle Ereignisse, die Ihnen im Prozess einfallen.

2. Zeitleiste erzwingen: Ordnen Sie die Ereignisse vom Beginn des Prozesses bis zum Ende.

3. Anreicherung der Ereignisse: Fügen Sie jedem Ereignis Metainformationen hinzu. Der Befehl (Aktion), der das Ereignis auslöst, die benötigten Daten, das System, das handelt, und die Richtlinie, die besagt, was als nächstes zu tun ist.

Chaotische Erkundung

Am Anfang fühlt es sich ein wenig unbeholfen an. Aber sobald die ersten Haftnotizen auftauchen, nimmt das Tempo richtig Fahrt auf und alle sind mittendrin.

Wir beginnen damit, dass wir allen Teilnehmern ein eigenes Stück der Tafel und eine Farbe geben (aber nicht Orange, dazu später mehr). Sie haben 25 Minuten Zeit, um alle Ereignisse, die ihnen während des Prozesses einfallen, auf Haftnotizen zu notieren. Ein Ereignis ist etwas, das in der Vergangenheit passiert ist und nicht mehr geändert werden kann. Deshalb schreibt man sie in der Vergangenheitsform auf. Zum Beispiel: "Code-Repository erstellt" oder "Code in der Produktionsumgebung bereitgestellt".

Ich ermutige sie, zu "schummeln" und sich die Ereignisse anzusehen, die andere Teilnehmer aufgeschrieben haben, denn das kann einen ganz neuen Teil des Prozesses eröffnen, an den man vorher nicht gedacht hat. Es ist völlig in Ordnung, Ereignisse hinzuzufügen, die andere Teilnehmer auch haben.

Durchsetzung des Zeitplans

Nachdem ich festgestellt habe, dass keine neuen Haftnotizen an der Tafel erscheinen, gehen wir zum nächsten Schritt über. Ich ziehe eine Linie auf der Tafel. Dann bitte ich alle, ihren Zettel mit dem Ereignis, das als erstes im Entwicklungsprozess eintritt, zu nehmen und ihn über die Zeitleiste zu schieben. Wir diskutieren kurz darüber, welches Ereignis wirklich das erste ist und setzen es an den Anfang der Zeitleiste. Um zu signalisieren, dass wir uns alle über dieses Ereignis und seinen Platz auf der Zeitleiste einig sind, ändern wir die Farbe des Klebezettels in Orange (deshalb gab es vorher keine Klebezettel in dieser Farbe ?). Dann fahren wir mit dem nächsten Ereignis fort.

Wir kommen in eine längere Diskussion über ein Ereignis. Um den Fluss aufrechtzuerhalten, erstelle ich eine spezielle Art von Haftnotiz, die Hotspot genannt wird. Darauf beschreibe ich das Problem, und dann gehen wir weiter. Wir werden später auf die Hotspots zurückkommen. Wir stoßen auf ein Ereignis, das mehrere Teilnehmer erstellt haben. Wir behalten denjenigen, der das Ereignis am besten beschreibt, und entfernen die anderen. Wir fügen auch Zweige für bedingte Ereignisse hinzu. Wir platzieren sie über oder unter der Zeitleiste des primären Prozesses.

Nach zweieinhalb Stunden hören wir auf. Der Zeitplan ist fertig und alle Hotspots sind gelöst. Alle sind begeistert, und wir planen sofort das nächste Treffen, um den Prozess klarer zu gestalten, indem wir die Ereignisse mit Metadaten anreichern.

Anreicherung der Ereignisse mit Metadaten

Dieser Schritt lässt sich am besten mit einem Bild erläutern:

Zu Beginn unseres (Teil-)Prozesses (große schwarze Haftnotiz) müssen wir Maßnahmen ergreifen (blaue Haftnotiz), um die Arbeit aufzuteilen. Dazu benötigen wir Informationen (grüner Zettel) in Form der User Story, an der wir arbeiten werden. Jira ist das System (großer rosa Zettel), das wir dafür verwenden. Wenn wir fertig sind, haben wir die Benutzergeschichte in sogenannte Teilaufgaben unterteilt. Das ist ein Ereignis (orangefarbene Haftnotiz). Die Entwicklungsrichtlinie (große lila Haftnotiz) sagt uns dann, was wir zu tun haben: eine Teilaufgabe in Jira in Arbeit zu nehmen.

Wir folgen der Zeitachse und reichern jedes Ereignis an. Wenn wir uns nicht sicher sind, wie wir ein Ereignis mit Metadaten anreichern können, erstellen wir einen Hotspot und gehen weiter. Später überprüfen wir alle Hotspots erneut. Einige Hotspots können wir nicht beheben. Zum Beispiel, wenn wir die Story vorführen, denn das hängt von der Planung der Stakeholder ab. Oder wenn wir eine Dokumentation für die Story erstellen, weil das noch nicht zu unserem Prozess gehört. Das ist in Ordnung, wir beschreiben ja nur die aktuelle Situation unseres Prozesses. Aber das ist etwas, das wir verbessern können!

Experiment erfolgreich abgeschlossen

Alle sind begeistert von EventStorming und den Ergebnissen, die wir damit erzielt haben.

Ich war zuversichtlich, dass wir durch die Durchführung eines EventStorm einen guten Überblick über den aktuellen Entwicklungsprozess erhalten würden. Am Ende haben wir tatsächlich ein klares Bild von unserem Entwicklungsprozess:

Es ist jetzt einfach, anderen zu erklären, wie unser aktueller Entwicklungsprozess aussieht. Wir wissen auch, dass uns in unserem derzeitigen Prozess einige wesentliche Teile fehlen.

Ich kann es kaum erwarten, mit der Modellierung unserer anderen Geschäftsprozesse zu beginnen!