Teamtage sind etwas Schönes. Hier kann man sich entfalten, neue Erkenntnisse gewinnen und miteinander teilen. Kürzlich hatten wir einen solchen Teamtag mit dem Motto “Topic intensive” und konnten uns losgelöst vom Projektgeschäft fokussiert mit verschiedenen Themen beschäftigen. Als angehender Enterprise Architekt hatte es mich zum Thema Architekturmethoden gezogen.
Geplant war, an konkreten Beispielen – „Projektzeiten buchen” / “Leistungsnachweis“ – verschiedene Methoden des Knowledge Crunching (Event Storming, Domain Storytelling) zu erleben und die bisherigen Erfahrungen im Team auszutauschen.
Unsere Gruppe bestand an diesem Tag aus sieben Architekten/Architektinnen, einer Domain-Expertin aus dem Backoffice und einer Moderatorin, die sich vorab nochmal konkret mit den Methodiken auseinandergesetzt hat. Neben dem Erleben der Methoden wollten wir konkrete Fragestellungen beantworten:
- Welches Problem adressiere ich mit welcher Methodik/Technik?
- Welche Methodiken/Techniken können wir kombinieren, und welche Ergebnisse sind wofür essentiell?
- Welche Tools zur Unterstützung gibt es?
Nach dem obligatorischen Check-in ging es direkt stürmisch und ereignisreich los.
Event Storming
Gestartet haben wir mit Event Storming zum Thema “Projektzeiten buchen”. Hier haben wir uns bewusst nur ein Zeitfenster von einer Stunde vorgenommen, wohlwissend, dass das Thema damit nicht erschöpfend behandelt werden kann.
Event Storming ist eine leichtgewichtige Methode, mit der man Expertenwissen einer Domäne greifbar und verstehbar machen kann. Es hilft dabei, eine gemeinsame Sprache zu finden und alle Beteiligten auf dasselbe Verständnislevel zu heben. Dazu benötigt man keinen Rechner / kein IT-Tool oder Ähnliches, sondern nur eine Wand und Sticky Notes (Stickies). Neben aktuellen Ist-Prozessen, wie in unserem Fall, kann man auch Soll-Prozesse über ein Event Storming ausarbeiten. Wichtig ist hier, dass man sich vorab auf ein Szenario festlegt.
Das Ergebnis ist in der Regel keine fertige Dokumentation à la BPMN-Modell, sondern ein gemeinsames Verständnis der Domäne. Da viel Wissen nur per Diskussion an der Wand geteilt wird, ist auch eine spätere Nachvollziehbarkeit durch Dritte, die nicht dabei waren, nur sehr eingeschränkt möglich. Es gibt zwar Theorien, dass man das Ergebnis nicht festhalten sollte, in der Praxis ist es aber aus meiner Sicht eine gute Grundlage für weitere Schritte.
Für Event Storming ist es wichtig, die richtigen Personen mit Domänen-Expertise zu beteiligen. Bei unserem gewählten Thema sind das Anke aus dem Backoffice, die die Buchungen später weiterverarbeitet, und die Experten/Expertinnen, die buchen oder auch freigeben. Zu Beginn wird in Kurzform allen Teilnehmenden erklärt, was die Idee hinter Event Storming ist (gemeinsames Wissen aufbauen – im Kopf) und welche Stickies (Konzeptelemente) es gibt. In der Regel sind diese farbig codiert und jede Farbe steht für einen Typ.
Man startet mit den Domain Events auf orangefarbenen Stickies. Diese sind als Substantiv und Verb in der Vergangenheit aufgebaut, z.B. “Stunden eingereicht” oder “Stunden geprüft”. (Man beschreibt das “geschehene Ereignis”.) Hintergrund ist, dass man durch abgeschlossene Ereignisse nicht diskutieren muss, wie lange sie dauern oder wann sie konkret beginnen müssen.
Während des Aufklebens der Ereignisse wird schnell klar, wie weit gefasst Menschen über ein Thema denken und was man eigentlich alles braucht, um ein einfaches Thema wie “Projektzeiten buchen” zu bearbeiten. Bei uns begann das mit dem Ereignis “Projekt erstellt”, da ein Projekt notwendig ist, um Zeiten darauf buchen zu können – da wäre ich selbst nie drauf gekommen. Da unsere Time Box nur eine Stunde umfasste und neben dem fachlichen Wissen bereits die Methode an sich diskutiert wurde, kamen wir über die Domain Events nicht viel hinaus.
Beim Aufkleben der Stickies erklärt die Klebende immer, was sie darunter versteht. Dabei kann es bereits zu Diskussionen zum Verständnis kommen. In der Regel werden auch direkt zeitliche Abhängigkeiten an der Wand “modelliert”, indem man die Stickies in eine Reihenfolge bringt. Wir haben am Ende der Stunde noch schnell Actors – Personen, die etwas ausführen (gelb) – und Views – Ansicht, mit der der Actor mit dem System interagiert (hellgrün) – an manche Ereignisse geklebt, um die weitere Vorgehensweise in der Methodik noch etwas greifbarer zu machen.
Interessant ist am Ende vor allem die Frage, ob man alle Domain Events betrachtet/gefunden hat. Um dies herauszufinden, kann man die zeitliche Abfolge einmal von vorn und einmal von hinten durchgehen, um zu prüfen, ob alle Voraussetzungen für ein Event erfüllt sind.
Da wir auch etwas über die Methodik lernen wollten, gab es im Anschluss eine Auswertung des eben Erlebten.
Unsere Erkenntnisse
- Eine Stunde ist selbst für kleine Themen sehr kurz. Wir sind nicht über die Domain Events hinaus gekommen und haben sicher selbst dort noch Lücken. Basierend auf den Erfahrungen der Architekten und Architektinnen, die die Methodik bereits anwenden, sind wir der Meinung, dass 4 bis 8 Stunden pro Thema eingeplant werden sollten.
- Es ist sehr interessant, wie groß selbst ein kleines Thema werden kann, wenn man verschiedene Beteiligte hat. Schwarmintelligenz ist hier ein großer Erfolgsfaktor, um einen umfassenden Blick zu bekommen.
- Es scheint tatsächlich für Techies einfacher zu sein, in Ereignissen zu denken, als für Nicht-Techies. Hatte ich bisher nur gelesen, kann ich aber jetzt nachvollziehen.
- Man sollte, vor allem bei der parallelen Nutzung als richtiger Workshop und Wissenstransfer, die Rollen (Moderator*in, Domänenexperte*in, Architekt*in) klar festlegen. Wenn man diese Technik anwendet, sollte es keine Diskussion zur Methodik (Farbe der Zettel, was ist ein Aggregat und was nicht) geben. Eine gute Moderation ist hier sehr wichtig.
- Trenne Moderation und inhaltliche Mitarbeit. → Wenn Event Storming als Methode funktionieren soll, dann setze den oder die Moderator*in wirklich nur zur Moderation ein. Wenn man fachliche Aspekte mit herausarbeiten und beeinflussen will, dann sollte man zu zweit in den Termin gehen.
- Wenn neben dem Event Storming noch nachgelagerte Architekturarbeit mit den Ergebnissen stattfinden soll, dann muss die oder der Architekt*in zwingend beim Termin anwesend sein. Allein aus dem Output lassen sich in der Regel keine sinnvollen Aussagen ableiten, da das Detailwissen oft eher auf der Tonspur liegt. Architekturarbeit kann z.B. sein: Dokumentation (Hinweis: das Ergebnis des Event Stormings ist noch keine Dokumentation), Ableiten von Risiken, Erkennen von Hot Spots und Redundanzen.
- Ich habe im Nachgang gelesen, dass bis zu 15-20 Personen an einem Event Storming teilnehmen können. Nach der ersten Erfahrung sind das wahrscheinlich zu viele – versuche es mit 5-10, wenn du diese Methodik zum ersten Mal anwendest.
- Man benötigt keine IT-Tools. Eine große Wand und Stickies sind vollkommen ausreichend.
- Bei nachfolgenden Event Stormings hat sich die Variante, dass jeder zu Beginn erst einmal nur drei Events klebt und dann der nächste an der Reihe ist, als sehr effektiv erwiesen. Diese Methode ermöglicht es allen Beteiligten, sich einzubringen und ins Sprechen zu kommen.
Event Storming eignet sich aus meiner Sicht gut als Einstiegslevel auf einer sehr hohen Abstraktionsebene – Big Picture. Man kann das Ergebnis aber auch nutzen, um weiter in die Tiefe zu gehen. Wir haben dies getan, indem wir uns anschließend in zwei Gruppen aufgeteilt haben. Die eine Gruppe hat den Bereich “Leistungsnachweis”, den wir als Hot Spot identifiziert hatten, mittels Domain Storytelling vertieft. Die andere Gruppe wollte das Ergebnis verfeinern und einen weiteren Schritt der Methode zum Unterteilen in Domänen / Bounded Contexts nutzen. Da ich in der Gruppe Domain Storytelling war, wird es jetzt märchenhaft – oder auch nicht so ganz 😀.
Domain Storytelling
Um das Hot-Spot-Thema “Leistungsnachweise” eine Ebene tiefer zu legen und somit besser zu verstehen, haben wir die Methode Domain Storytelling genutzt. Hier erzählt ein oder eine Domänenexperte /-expertin seine Tätigkeiten als Geschichte und das Ganze wird visualisiert. Wir hatten neben der Expertin eine explizite Moderatorin, eine “Visualisiererin” und drei weitere Architekten und Architektinnen, die Wissen beitragen und Fragen zum Verständnis stellen konnten. Auch hier haben wir wieder die Zeit auf eine Stunde begrenzt.
Methodik
Domain Storytelling basiert darauf, dass ein Interview mit einer Person mit Fachexpertise stattfindet. Dabei erzählt der ode die Fachexperte /-expertin eine Geschichte in einfachen Sätzen mit dem Muster <Subjekt – Prädikat – Objekt>. Das Subjekt ist immer ein Actor (Person, System), der etwas (Prädikat) mit einem Objekt tut. Das Tun kann einen weiteren Actor benötigen, der mittels Präposition eingebunden wird. Jeder einzelne Satz wird so lange “diskutiert” bis er von allen als richtig akzeptiert wird. Wenn er dann steht, dann ist die Geschichte bis zu diesem Punkt erzählt.
Das ist etwas anders als beim Event Storming, wo jederzeit alles nochmal hin- und hergeschoben und hinterfragt werden kann. Am Ende entsteht aus den Sätzen die Geschichte. Die Methode kann entweder wieder analog mit Stickies oder mit Toolunterstützung durchgeführt werden.
Tool
Für das Domain Storytelling haben wir das Tool Egon.io eingesetzt, da einige Kollegen*innen hier schon Erfahrungen hatten und es auch auf der Webseite zur Methodik als Unterstützung angepriesen wird.
Sätze werden in egon.io visualisiert, indem man aus einem Set an Actors und Objects wählt, die man mit einem Pfeil verbindet. Der Pfeil erhält automatisch eine Nummer (Zeitpunkt in der Geschichte) und die Beschreibung der Aktivität. Wird ein weiterer Actor einbezogen, zieht man einen zweiten Pfeil zwischen Objekt und Actor, an den man eine Präposition schreibt. Hier wird keine Nummer vergeben.
Gut zu erkennen ist, dass eigene Symbole für Actors und Objects hinzufügt werden können, um die Geschichte individuell zu gestalten. Weiß man, in welchem Umfeld man sich bewegt, kann das auch gut vorbereitet werden.
Entstanden sind am Ende zwei sehr unterschiedliche Varianten derselben Geschichte. Wir wollten ja lernen und ausprobieren.
Die Spinne stellt die gesamte Geschichte in einem Graph dar. Ausgehend vom Mittelpunkt – der erzählenden Person – gehen die Sätze in alle Richtungen ab. Dadurch kann man gut erkennen, wie viele Anwendungen im Einsatz sind, welche Anwendungen häufig benutzt werden und wo Medienbrüche stattfinden. Auch die Tatsache, dass für einen vermeintlich einfachen Schritt mehrere Sätze (extrahiert, exportiert, importiert) und Tools genutzt werden müssen, ist erkennbar.
Es geht aber auch häppchenweise. Diese Vorgehensweise hat ein Kollege ins Spiel gebracht, da er sie schon genutzt hat. Sie entspricht eigentlich nicht der Idee, jeden Actor nur einmal in einer Story zu haben und damit einen verbundenen Graphen zu erzeugen. Hier beschränkt man sich auf 2-3 Aufgaben pro Actor, lässt den Actor mehrfach zu und erzählt damit die Geschichte hintereinander von oben nach unten. Das entzerrt das Bild und ist eher aus der Sicht einer besser lesbaren eigenen Dokumentation sinnvoll.
Unabhängig davon, für welche Methodik man sich entscheidet, bietet egon.io am Ende die Möglichkeit, die Geschichte im Replay Mode schrittweise noch einmal zu erzählen. Dies kann z.B. die Moderatorin tun, um sich noch einmal zu vergewissern, dass alles da ist.
Unsere Erkenntnisse
Auch hier ist es wieder gut, wenn man diese Technik zu zweit anwendet. Eine Person führt durch den Workshop und hält die Geschichte am Laufen, die andere Person visualisiert. Durch die Visualisierung kann der oder die Erzählende direkt Feedback geben, ob es so passt (und ob die visualisierende Person es richtig verstanden hat).
Es kann manchmal schwierig sein, die Wissenden auf das Erzählen einer Geschichte einzustimmen. Hier ist es wichtig, die Anforderung niedrigschwellig zu halten – es muss kein Harry Potter oder die bestmögliche Gute-Nacht-Geschichte für den eigenen Nachwuchs werden. Das Märchenhafte sollte man also nicht übertrieben anpreisen und falsche Vorstellungen bei den Domänenexperten*innen wecken. Wir haben hier durchaus einen Lerneffekt gehabt.
Die Nutzung von egon.io ist intuitiv und geht leicht von der Hand. Man sollte im Termin aber trotzdem nicht das erste Mal mit dem Werkzeug arbeiten. Eigene Symbole einzuführen erleichtert das Verständnis. Weiß man schon im Vorfeld etwas über die Domäne, dann kann man das nutzen, um mit auf den Kunden bzw. die Domänenexperten /-expertinnen zugeschnittenen Symbolen die Geschichte “persönlicher” auszugestalten. Die Möglichkeit die Story am Ende nochmal anhand der Satznummern abzuspielen, ist zum Abklären des richtigen Verständnisses ein sehr tolles Feature.
Und nun?
Auch hier haben die Beteiligten wieder ein gemeinsames Bild auf die Domäne und deren Aufgaben. Das kann man so stehenlassen, für eine spätere Dokumentation oder für eine Analyse von Pain-Points nutzen. Man kann das Ergebnis aber auch dazu verwenden, um neue Teammitglieder zu onboarden, was in der Regel eher in zeitlicher Nähe zum Termin sinnvoll ist. Dann erzählt jemand, der dabei war, die Geschichte nochmal anhand des Bildes. Wichtig ist auch hier, dass es ein Gespräch bleibt und jemand erzählt, der dabei war.
Domänen schneiden / Bounded Contexts
Die zweite Gruppe hat sich mit dem Thema “Kontexte finden” (Bounded contexts) auseinandergesetzt. Konkret ging es um die Themen: Was ist das? Warum braucht man Kontexte? und Wie findet man sie? Da ich hier nur bei der Abschlusspräsentation dabei war, möchte ich euch nur das spannende Ergebnis zeigen und eine kurze Zusammenfassung geben.
Typischerweise ist das Schneiden in Kontexte ein Schritt, um fachlich zusammenhängende Events zu finden, die später als eigenständige Module eine möglichst lose Kopplung innerhalb des Gesamtsystems erlauben und damit Unabhängigkeit bei der Umsetzung mittels Software zu erreichen. Die “lose Kopplung” kann man dabei so auf die Teams übertragen, dass für die Entwicklung wenig Abstimmung mit anderen Teams notwendig ist und wenn, dann nur über vordefinierte Schnittstellen.
Für das Vorgehen zum Schneiden wissen Fachexperten /-expertinnen ziemlich genau, an welcher Stelle eine Begrenzung möglich oder vorhanden ist. Daher sollte man diese Fragen direkt im Eventstorming-Workshop stellen. Grenzen finden sich z.B. dort, wo ein Rollenwechsel (Actor) stattfindet, an zeitlichen Grenzen oder bei Sprachwechseln in Bezug auf das Modell, z.B. wenn unter dem Begriff “Buchung” an zwei Stellen etwas anderes verstanden wird.
Die Events, die die Grenzen zwischen Kontexten überschreiten oder von mehreren Kontexten gebraucht werden, heißen Pivotal Events und eignen sich in der Regel sehr gut, um bei in einer Zielarchitektur zu einer asynchronen Kopplung zwischen den Kontexten zu kommen.
Gesamtfazit
Teamtage sind toll, weil man sich die Zeit nehmen kann, neue Themen zu erschließen und in einem geschützten Raum fokussiert neue Methoden zu “üben”.
Event Storming ist für mich vor allem eine Methodik, um das Big Picture einer Domäne zu zeichnen. In die Tiefe gehen kann man dann mit anderen Methodiken. Ein umfängliches Bild zu erhalten steht und fällt mit den Domänenexperten /-expertinnen. → Man sollte alle relevanten dabei haben.
Mit Domain Storytelling in die Tiefe zu gehen empfand ich als einfach und effektiv – sofern man den Domänenexperten / die Domänenexpertin gut abholt. Entsteht dann ein Bild wie die Spinne bei uns, dann ist der Replay-Mechanismus von egon.io hilfreich, um Schritt für Schritt durchzugehen.
Beide Methoden sind keine Dokumentationswerkzeuge, sondern Wissensvermittlung. Die Einstiegshürde ist sehr niedrigschwellig, da beide einfach zu verstehen und wenig komplex sind.
Probiert es also mal aus.
