"Ich öffne die Büchse der Pandora" – Interview mit Alberto Brandolini
Seite 2: Die Erfindung von EventStorming
heise Developer: Im Jahr 2013 hast du dein Workshop-Konzept EventStorming vorgestellt, das die DDD-Philosophie in Gruppenzusammenarbeit und eine leichtgewichtige Modellierungstechnik übersetzt. Wie bist du darauf gekommen?
Brandolini: EventStorming war keine geplante Erfindung. Das erste Mal, dass ich mit farbigen Haftnotizen auf einem Stück Papier modellierte, war während eines kleinen Treffens der italienischen DDD-Community. Mein Freund Emanuele Delbono moderierte den Workshop und beschrieb den Prozess, den er untersuchen wollte. Dann teilten wir uns in Gruppen auf.
Ich musste schnell ein paar Grundlagen festhalten, also nahm ich eine Papierrolle, fing an, mit DDD- und CQRS-Bausteinen (Command Query Responsibility Segregation) zu skizzieren, was ich verstanden hatte, und hatte innerhalb weniger Minuten etwas fertig. Währenddessen hatten die anderen Teams noch nicht einmal angefangen.
Wichtig hierfür war das Umfeld: Es war keine Business-Umgebung, ich befand mich in Gegenwart kluger Freunde. Die Kombination gab mir die größtmögliche Experimentierfreiheit: Ich konnte die Einführung überspringen und gleich ins Eingemachte gehen. Wir warten dort, um uns auszutauschen, und Mängel, die in einem Experiment auftreten würden, sprach man gleich an.
Dann fing ich an, diesen Ansatz – ursprünglich Event-Based Modeling genannt – zu verwenden, um Anfängern DDD-Bausteine zu vermitteln, ohne die traditionellen Definitionen durchzugehen. Das funktionierte und überzeugte. Der eigentliche Durchbruch geschah, als Vaugh Vernon mich als Special Guest zu seiner IDDD-Tour in Leuwen und Krakau einlud. Das war nicht nur ein Kurs, es war ein Raum mit 50 bis 70 erstaunlichen Menschen, die EventStorming liebten, es in ihren Jobs und in ihren lokalen Communitys ausprobierten und unglaublich wertvolles Feedback, Ideen und Varianten lieferten.
Alberto Brandolini bringt sein EventStorming-Konzept im Oktober und November 2019 nach Deutschland: In den beiden Workshops in Hamburg und München lernen die Teilnehmer, ihre Domäne ganzheitlich aus der Perspektive aller beteiligten fachlichen Experten zu betrachten und zu verstehen. Mehr Informationen und Tickets finden sich auf der codecentric-Website.
heise Developer: Du hast EventStorming schon mal mit Pizzabacken verglichen – was angesichts der Komplexität der Probleme, die gelöst werden sollen, erschreckend trivial erscheint.
Brandolini: Ich bin Italiener und weiß, wie komplex die Herstellung einer guten Pizza wirklich ist. Ein guter Freund von mir ist im Feinschmecker-Pizza-Business, und man braucht definitiv eine Menge Wissen, um ein unvergessliches Produkt aus scheinbar einfachen Zutaten herzustellen.
Was ich mit der Pizza-Metapher sagen möchte, ist, dass kooperativ validiertes Business Storytelling eine Plattform für anspruchsvollere Überlegungen ist. Es gibt Varianten des Grundrezepts (big picture recipe), die verschiedene Workshops ermöglichen – sie haben alle dieselbe Grundlage, aber die Vorgehensweisen können sehr unterschiedlich sein.
Was mich begeistert, ist die Möglichkeit, einzelne Elemente aus den Disziplinen aller Beteiligten zu einem sehr flexiblen und leistungsfähigen Werkzeug zu kombinieren. Würde man zu orthodox mit dem Rezept umgehen, würde man vieles von dem verhindern, was auf magische Weise entsteht. Natürlich werden einige Leute schlechte Rezepte machen, aber andere werden dafür mit einem hervorragenden Rezept aufwarten.
heise Developer: Acht bis sechzehn Teilnehmer in einem Raum, die sich oft zum ersten Mal persönlich begegnen, alle mit subjektiven Ansichten und sogar Vorurteilen zur Anwendungsdomäne – wie schafft man es, in diesen geradezu chaotischen Zuständen ein kohärentes Gesamtbild zu erstellen?
Brandolini: Das ist Aufgabe der Moderation. Niemand will derjenige sein, der nur Haftnotizen an die Wand klebt und sie in einem chaotischen Raum zurücklässt. Wir können uns also darauf verlassen, dass jeder im Raum daran interessiert ist, das Chaos zu beseitigen.
Die strukturiertere Antwort ist: Schritt für Schritt. Wir fangen chaotisch an, besser gesagt, mit vereinzelt einheitlichen Ereignisclustern innerhalb eines uneinheitlichen Ganzen. Dann versuchen wir, Struktur hineinzubringen. Wir erkennen dann, dass unsere anfängliche Struktur naiv war und wenden ausgereiftere Methoden an, bis wir zu einer Ordnung gelangen, die für alle im Raum zufriedenstellend ist.
Das Chaos gemeinsam zu beseitigen ist ein Vorgang, der irgendwo zwischen Lernen und Teambuilding liegt. Aber er dient auch dazu, den Status quo in Frage zu stellen: Das anfängliche Chaos ermutigt kritische Stimmen, die nicht so leicht laut würden, wenn man mit einer aufgezwungenen Struktur anfangen würde.
Kohärenz ist nicht unbedingt mein Ziel. Besonders beim Gesamtbild muss ich den aktuellen Stand unseres Verständnisses des Geschäftsfeldes visualisieren. Wenn unser Geschäftsfeld inkohärent ist, muss ich es realistisch darstellen, nicht irgendeine geschönte Version davon. Dabei bin ich ein besonderer Freund von Hot Spots: Alle Meinungsverschiedenheiten werden visualisiert, einige können behoben werden, aber nicht alle.
heise Developer: Es gibt weitere Ansätze wie Domain Storytelling, die sich vor allem darauf konzentrieren, Empathie zwischen den Beteiligten herzustellen. Wie gehst du mit der emotionalen Seite von Teilnehmern um, die diskutieren, Meinungsverschiedenheiten, unterschiedliche Dringlichkeiten und Prozessabläufe haben?
Brandolini: Emotionen sind kontextabhängig, und Menschen sind immer wieder für eine Überraschung gut. Ein Rezept, das den Umgang mit Emotionen genau vorschreibt, halte ich also für eine schlechte Idee. Aber als Moderatoren können wir mit solchen Systemen umgehen: Eine chaotische Runde, in der Probleme und Möglichkeiten angesprochen werden, wird jedem die Gelegenheit und manchmal auch die Anonymität geben, Dissens visuell darzustellen, ohne den Chef offen herauszufordern.
Ich beobachte die Teilnehmer, bitte diejenigen, die sich nicht beteiligen, leise um Feedback, und verfolge die Körpersprache, um zu sehen, ob etwas schiefläuft. Einige Dinge mache ich bewusst, zum Beispiel wähle ich einen informellen Ton, sodass Hierarchien und Distanzen wenig Raum haben, und ich vermute, dass ich auch einiges unbewusst tue, um den Teilnehmern ein Gefühl von Sicherheit zu geben.
Aber ich muss sagen, dass das Ganze oft ein kleines Wunder bewirkt: Es ist schwer, sich über seine Kollegen zu ärgern, die trotz ihrer Einschränkungen eindeutig ihr Bestes geben. Ich öffne zwar schon die Büchse der Pandora – aber was herauskommt, ist mehr Versöhnung als Streit.
heise Developer: Größere Unternehmen haben oft ein einzigartiges Regelwerk, das dem freien Informationsfluss zwischen Entwicklern und Domänenexperten Abbruch tun und gemeinsame Workshops erschweren kann. Wie gehst du mit einer solchen Unternehmenspolitik um?
Brandolini: Gar nicht. Ich mache nur ihre Wirkung sichtbar. Normalerweise werde ich nicht in eine Organisation gerufen, um eine Revolution zu starten. Es gibt Einschränkungen und Vorschriften? Machen wir sie sichtbar! Lasst uns die Auswirkungen sehen. Lasst uns sehen, ob unsere Wettbewerber das gleiche Problem haben oder ob sie genau die gleichen Einschränkungen haben. Sobald diese sichtbar und Teil des Problems sind, können wir "Was-wäre-wenn" spielen.
Ich persönlich habe festgestellt, dass es oft Diskrepanzen zwischen der Einschränkung und ihrer letztlichen Umsetzung gibt. Es gab immer einfache Lösungen, die sich vorbildlich an die Regel hielten, wenn die Einschränkung einen rechtlichen Hintergrund hatte, oder mit dem Grundgedanken zu vereinbaren waren, wenn der Einschränkung eine Unternehmensvorschrift zugrunde lag.
Im Lösungsraum gibt es eine Vielzahl von Möglichkeiten, die angewendet werden können: Unscharf definierte Prozesse können dem Geist einer Regel treu bleiben, ohne in starre Mechanik zu verfallen.
heise Developer: Welches Problem löst EventStorming und wie wird das erreicht? Wann ist es nützlich und für wen?
Brandolini: EventStorming ist nicht auf ein bestimmtes Problem ausgerichtet. Es ist eine Plattform, die Rezepte bereitstellt, die für ein breiteres Spektrum an Problemen nützlich sind. Die offensichtlichsten Probleme, die es adressiert, rühren von der Zusammenarbeit zwischen mehreren Silos her, da es hier an Sichtbarkeit, Transparenz und einer gemeinsamen Sprache mangelt und gegenseitige Schuldzuweisungen üblich sind. Immer dann, wenn eine Zusammenarbeit über Abteilungsgrenzen hinweg erforderlich ist, kann die Kombination aus ereignisgesteuertem Storytelling und Visualisierung unglaublich nützlich sein.
Die Fragen stellte Tobias Goeschel. Als Principal Consultant und Trainer bei der codecentric AG hilft er Kunden nicht nur dabei, ihre Produkte zu verbessern, sondern auch die Art und Weise, wie sie gebaut werden. (bbo)
