Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren

Folge 326 - Kollaborative Modellierung - warum und wie funktioniert Event Storming in der Praxis Ein Hinweis in eigener Sache.

Event-Storming ist nur der Anfang.

Mit unserem brandneuen Training meisterst du in drei Tagen kollaborative Modellierung.

Von der Vorbereitung bis zur Moderation.

Sei dabei und sichere dir jetzt 20% Premiere-Rabatt.

1. bis 29.

Oktober in der Therme Erding mit Eberhard Wolff und Tom Asel.

1. bis 25.

November in Wien mit Daniel Sack.

Alle Infos wie immer auf software-architektur.tv.

Denn Architektur entsteht nicht im Stillen, sondern im Team.

Herzlich Willkommen zu einer weiteren Episode von Software-Architektur im Stream.

Diesmal geht es um Event-Storming und kollaborative Modellierung.

Warum das funktioniert, wie man das in der Praxis tatsächlich auf die Reihe bekommt und so weiter.

Und dazu sitze ich zusammen mit Daniel und Tom.

Ich glaube, wir können anfangen mit einer Vorstellungsrunde.

Tom, möchtest du ein paar Worte über dich sagen?

Ja, sehr gerne.

Tom Asel.

Ich bin Trainer oder Coach, Consultant rund um alles, was mit Software-Architektur zu tun hat.

Ich interessiere mich ganz besonders für kollaborative Methoden und das führt uns auch hier in dieser Runde zusammen.

Genau.

Daniel, möchtest du noch etwas zu dir sagen?

Ja, hallo.

Ich bin der Daniel.

Also ich kann mich dem Tom nur anschließen.

Kollaborative Modellierung ist, glaube ich, ein Thema, wofür ich brenne.

Deswegen organisiere ich auch jetzt schon seit einigen Jahren das Como-Camp und in meinem Day-to-Day-Job bin ich vor allem in der Beratung unterwegs und jetzt auch im Training, wo ich dann auch ein bisschen Insights geben kann über kollaborative Modellierung, wie das funktioniert.

Und ich freue mich schon auf den Stream heute.

Was ist denn dieses Como-Camp eigentlich?

Was ist dieses Como-Camp?

Das ist ganz spannend.

Da treffen sich einmal im Jahr genau die Menschen, die sich mit dem Thema kollaborative Modellierung beschäftigen.

Und ich glaube, das war auch da, wo Tom und ich diese Idee gehabt hatten, da mal was gemeinsam zu machen.

Ich kann mich noch erinnern am ersten Como-Camp, wo ich dich kennengelernt habe, Eberhard.

Also Como-Camp ist dort, wo man Menschen treffen kann, wo man mit Menschen neue Sachen ausprobieren kann im Bereich der kollaborativen Modellierung.

Und dann passiert etwas, wo man dann gemeinsam vielleicht das ein oder andere Projekt hat.

So würde ich das jetzt mal beschreiben.

Sehr schön.

Genau, wir wollen loslegen mit dem Thema, mit dem Event-Storming.

Also was ist denn das eigentlich?

Und dazu haben wir tatsächlich sozusagen was vorbereitet.

Und das ist ein Ausschnitt aus einem Miro-Board.

Da sehen wir jetzt also ein orangenes Post-it.

Die Farben sind ja wahnsinnig wichtig.

Auf diesem orangenen Post-it steht jetzt sowas wie Produkt gefunden.

Also ein Event, was wir bei Event-Storming benutzen, wäre eben so ein Prostit mit einem Hauptwort und einem Verb in der Vergangenheit.

Events sind Dinge, die passiert sind.

Und das ist so ein bisschen der Kern von Event-Storming, würde ich jetzt mal behaupten.

Wie geht es dann weiter?

Oder habt ihr da Sachen, die ihr ergänzen wollt?

Ja, ich glaube, vielleicht soll ich erst mal etwas erzählen über die Methode an sich.

Also der Name sagt es ja, Event-Storming.

Die Events sind halt eben der Kern davon.

Aber was die Methode halt ausmacht, ist, dass wir mit Leuten zusammen sind, die ein bestimmtes Wissen haben.

Und das oftmals auch Leute sind, die wir halt vielleicht nicht direkt so im Team im Zugriff hätten.

Und mit denen sich dann Gedanken zu machen, welche Ereignisse denn eigentlich aus einer fachlichen Sicht bedeutsam sind.

Das alleine ist schon mal was echt Spannendes.

Also jetzt das Beispiel, was du gerade zeigst, ist aus einem beliebigen Event-Storming mal rausgegriffen und zeigt es halt irgendwie eine Reihe von Events.

Oder jetzt sehen wir erst mal nur eins, aber man kann es erahnen, es geht halt eben nicht nur um ein einziges.

Es geht darum, dass wir eine Menge von Events finden, die bedeutsam sind und die eine bestimmte Ordnung bringen.

Und uns das was sagt.

Also der Prozess der Erstellung ist das Interessante.

Es geht nicht um das Event an sich oder dieses eine.

Es geht eher darum, dass wir uns Gedanken darüber machen in der Gruppe, was ist denn bedeutsam und daraus dann etwas formen.

Das sollte man vielleicht vorweg schicken für die zwei Personen, die es da draußen vielleicht noch gibt, die noch nicht direkt wissen, was ein Event-Storming ist.

Also was bedeutet das, wenn wir den Domänen-Expertinnen und andere Menschen einladen, denen Brüsteblöcke in die Hand geben und die sollen dann solche Sachen schreiben.

Und also eben Events aufschreiben.

Und der Vorteil ist eben diese Kollaboration.

Das heißt, man macht es eben gemeinsam.

Es ist eine parallele Aktivität.

Das heißt, alle können Events schreiben und das ist eben Low-Tech.

Das heißt, wir haben jetzt nicht so ein Problem, wo wir jetzt die Menschen erst mal den zwei, drei Stunden irgendwie abbreiten müssen, was UML ist.

Sondern es ist eben, ich hätte jetzt fast gesagt barrierefrei, wobei das eigentlich genau genommen nicht stimmt, weil es sehr visuell ist.

Aber es ist eben die niedrige Barriere, um da sozusagen loszulegen.

Und jetzt könnten wir eben alle Events schreiben.

Das ist so ein bisschen die Idee dabei.

Genau.

Also dieses Niederschwellige, so würde ich es nennen, ist irgendwie ein ganz wichtiges Ding davon.

Aber es hat trotzdem so ein paar Hürden, über die wir nachher noch reden.

Also es ist natürlich nicht damit getan, dass wir einfach sagen, wir pappen da jetzt irgendwas an die Wand.

Sondern das folgt schon einer gewissen Struktur, einer gewissen Ordnung.

Aber im Herzen ist es eigentlich das, die richtigen Leute treffen sich in einem Raum, wie auch immer das zustande kommt.

Darüber reden wir vielleicht noch und arbeiten mit erst mal sehr, sehr einfachen Mitteln.

Und ich glaube, eine Frage, die da auch aufpoppt, ist, was hat das jetzt beispielsweise mit Softwaremodellierung zu tun?

Oder warum machen wir das denn überhaupt?

Also ist das nur, weil das Fun macht oder irgendwie ein paar Ideen offenbart?

Oder steckt da vielleicht auch noch ein bisschen was Tieferes dahinter?

Spoiler, ja natürlich.

Das wollen wir uns natürlich nutzbar machen.

Und wenn wir sozusagen auf das Verfahren weiter eingehen, dann wäre es eben so, dass wir im ersten Schritt tatsächlich sagen würden, okay, schreibt halt bitte möglichst viel, möglichst an Events einfach auf.

Und werft ja sozusagen gegen die Wand, logischerweise.

Oder es ergibt sich eigentlich sogar automatisch, dass man dabei versucht, so ein bisschen das zu ordnen, von links nach rechts in einer chronologischen Reihenfolge.

Aber das ist jetzt erst mal nicht so relevant.

Und das ist halt diese erste Phase mit der Chaotic Exploration, wo man also die Menschen dazu bringt, möglichst viele von diesen Events an die Wand zu bringen und die halt dort dann zu kleben, beziehungsweise halt in ein Euroboard.

Ich finde das auch immer sehr spannend, diese erste Phase.

Ich glaube, man kann die auch so ein bisschen als die Brainstorming-Phase bezeichnen, wo man auf einmal anfängt, einmal die Sachen aus dem Kopf hinaus zu bekommen und einmal aufzuschreiben.

Und ich glaube, dieser erste Schritt des Aufschreibens, das ist so einer der Key-Aspekte, warum diese Art von Methoden so gut funktionieren.

Weil wir die Information einmal aus vielen Köpfen gemeinsam, wenn wir das als Gruppe machen, visualisieren und aufs Board drauf bekommen und dann in die Strukturierung gehen können.

Ich komme nicht umhin, weil ich mir das nochmal aufgeschrieben habe.

Tatsächlich, der Begriff Storming sagt es ja, das ist eine Aktivität, die halt im hohen Maße dynamisch sein soll.

Und eigentlich wollen wir jetzt in dieser Phase, deswegen heißt es Chaotic Exploration, möglichst viele Sachen an die Wand bekommen.

Und eine Sache, die man ausprobieren kann, ist, die Leute sich erst mal warmschreiben zu lassen.

Also ein Wettbewerb zu machen, mitschreibt möglichst viele Postings zu irgendeinem Thema.

Also möglichst viele Postings darüber, wie ein Meeting besonders toll laufen kann oder was auch immer.

Dass man dann erst mal ganz viele von diesen, die Leute dazu bringt, schnell viele Haftnotizen zu produzieren, weil das eben das ist, was sie jetzt tun sollten.

Und dann wäre der nächste Schritt, dafür zu sorgen, dass man das in eine chronologische Reihenfolge bekommt.

Also dann tatsächlich schaut, ob diese Sachen in einer chronologischen Reihenfolge schon sind.

Und wenn nicht, sortiert man die halt eben nochmal, eliminiert dabei Duplikate, diskutiert über das Ganze und sorgt dann in diesem nächsten Schritt dafür, dass sozusagen mehr Ordnung entsteht.

Und da ist es halt auch so, dass es von der Gruppe her was anderes ist, weil man da es eben gemeinsam durchgeht, also eben mit einem Moderator oder so.

Was den Vorteil hat, dass dann eben tatsächlich das Wissen in den Köpfen aller sich sozusagen manifestiert und dass man dort eben dann tatsächlich ein gemeinsames Verständnis aufbaut.

Habe ich das so richtig gesagt oder habe ich da was vergessen?

Ich würde da gerne was ganz Essentielles ergänzen.

Und zwar, also wie kommen wir denn überhaupt wirklich zu formulierten Events?

Es ist ein Riesenunterschied zwischen, wir schreiben jetzt Stickys auf zum Beispiel zu der Frage, wie organisiert man irgendwie ein Meeting?

Das kann so ein guter Icebreaker sein, um die Leute erstmal dazu zu kriegen, tatsächlich, wie Du es gesagt hast, auch erstmal was an die Wand zu kriegen.

Aber dann haben wir erstmal etwas an der Wand und nicht notwendigerweise ein Event, wie wir es im Eventstorming verwenden wollen.

Und was wir dann auch später dann erst in eine chronologische Reihenfolge führen.

Das heißt also, so ein Warm-up kann halt sein, okay, wie wird irgendwie ein Meeting organisiert?

Und dabei dann aber halt auch gleich erklären, also ein Event ist halt was, was wir in der Vergangenheitsform formulieren.

Also etwas, was stattgefunden hat, etwas Eingetretenes und das wird auch genauso beschrieben.

Und da wollen wir also nicht irgendwie einfach nur Buzzwords draufstehen haben.

Also da muss nicht irgendwie Teilnehmer-Ausrufezeichen draufstehen oder Einladungen oder sowas, sondern tatsächlich Ereignisse, die man auch sinnvoll ordnen kann.

Und das geht halt eben wunderbar, wenn wir über Dinge sprechen, die zu einem bestimmten Zeitpunkt stattgefunden haben, beziehungsweise abgeschlossen sind.

Also so wie jetzt hier steht, Produkt gefunden, das sagt was aus.

Also dass irgendetwas passiert, das kann was Technisches sein, das kann was völlig anderes sein.

Aber das Wichtige ist, das hat einen zeitlichen Bezug.

Und ich kann dieses Ereignis, das kann ich jetzt zum Beispiel dann halt eben auch relativ zu anderen Ereignissen dann später ordnen.

Aber das kommt auch erst später.

Und dieses Coole bei dieser Storming-Phase ist halt dieses kreative Chaos am Anfang.

Also jeder schreibt erst mal im Stillen für sich und klebt sich den Unterarm voll mit Stickys oder sonst irgendwas.

Und dann werden die halt irgendwie erst mal rein chaotisch an eine Wand geworfen.

Und dann sind die natürlich nicht in irgendeiner Reihenfolge.

Und wir haben natürlich ganz viel Doppelung und wir haben natürlich ganz viel drüber diskutieren.

Also ist jetzt irgendwie Produkt gefunden, das Gleiche wie Produkt gewählt.

Und das ist eigentlich schon das Tollste.

Noch bevor wir anfangen zu sammeln, geht dann so eine dynamische Diskussion los, die an mehreren Plätzen gleichzeitig stattfindet.

Und das macht Spaß.

Ja, und ich glaube, damit hast du halt noch zwei wichtige Sachen halt irgendwie sozusagen indirekt darauf hingewiesen.

Also ein wichtiger Hinweis, den man daraus bekommt, ist eben, wer schreibt eigentlich welche Stickys.

Dadurch kriegt man halt raus, wer für was Experte oder Expertin ist und wie die Menschen halt irgendwie sozusagen zusammensitzen.

Wo man später mehr miteinander reden kann oder wo man halt sicher noch mal tiefere Einblicke rausholen kann.

Und das andere ist, ich glaube, das haben wir tatsächlich im letzten Stream schon diskutiert, lustigerweise aus einer ganz anderen Perspektive.

Also eine Diskussion ist halt irgendwie wichtig und essentiell und die kommt halt da irgendwie in Gange.

Dadurch, dass man jetzt irgendwie sagt, ich habe halt hier irgendwie diese Events, ich muss hier halt irgendwie die Duplikate entfernen und halt die Timeline da irgendwie auf die Reihe bekommen.

Und diese Diskussion führt irgendwie zu einem Wissensaustausch, was bedeutet, selbst wenn man anschließend das Produkt wegwirft, also sagt, dieses Ergebnis brauche ich halt oder werfe ich halt einfach weg, hat trotzdem eine Diskussion und einen Meinungsaustausch und Wissensaustausch gehabt.

Und das ist, also ich rate nicht unbedingt dazu, die Ergebnisse wegzuwerfen, aber ich finde es halt wichtig zu sagen, wir haben eben nicht nur Artefakte, sondern wir haben irgendwie auch einen Prozess, der halt dazu führt, dass halt was in den Köpfen passiert.

Und das ist vielleicht sogar das wichtigere Ergebnis.

Also da möchte ich gleich ergänzen, weil ich glaube, Tom hat das schon ganz gut jetzt plakativ hergezeigt, wie das ist, wenn man anfängt zu diskutieren und dann vielleicht auch über Begriffe diskutiert, wie nennen wir was, also was auch mit der Sprache passiert.

Und das ist das eine, dass sich die Sprache entwickelt.

Und was ich sehr oft beobachte, ist nicht nur, dass das Wissen sich verteilt, die Sprache sich entwickelt und wir dann vielleicht diese Prozessvisualisierungen haben, die Menschen kommen auch zueinander.

Also es fängt auf einmal an, dass die Menschen sich besser in die Lage versetzen können, wie geht es eigentlich meinem Gegenüber in der Situation, was heißt das in der Zusammenarbeit, wo haben wir Missverständnisse drinnen.

Und da passiert ganz viel auch auf der Meta-Ebene bei diesen Methoden, um gemeinsam besser zusammenarbeiten auch zu können.

Also das sind so die Nebeneffekte, die dann auch passieren und die sehr oft, glaube ich, auch übersehen werden.

Gut, wollen wir dann in dem Prozess sozusagen weiter fortschreiten?

Also wir haben ja gesprochen über dieses M-Force Timeline, also eben dafür sorgen, dass die ja tatsächlich in einer bestimmten Abfolge sind.

Der MD42Martin bei YouTube hat geschrieben, statt Duplikate entfernen, das hatte ich ja angesprochen, wäre etwas, was ich machen kann, ist eine Praktik, die er empfiehlt, Hotspots zu identifizieren.

Was sind Hotspots?

Ja, Hotspots sind generell Punkte, über die man nochmal reden muss.

Vielleicht auch gar nicht in dieser Session.

Oftmals ist es eine gute Idee zu sagen, okay, wir machen nur erkenntlich, dass hier irgendwas ist, was wir diskutieren wollen.

Also zum Beispiel, wenn eine Begrifflichkeit nicht klar ist oder wenn wir mehrere verschiedene konkurrierende Begrifflichkeiten haben.

Also es ist halt die Frage, wollen wir den Prozess aufhalten oder wollen wir das auch später raus verlegen?

Hotspots markieren ist also eine gute Möglichkeit zu sagen, wir haben hier identifiziert, da ist was zu klären, nicht notwendigerweise jetzt innerhalb dieser Stunde oder was auch immer, wo wir zusammen sind.

Und ich finde, der Kommentar hat absolut seine Berechtigung, aber ich denke, es braucht beides.

Also wir haben also oftmals so Sachen, dass wir feststellen, da ist eine Begrifflichkeit redundant und dann hilft allein schon mal zu erkennen, der eine sagt halt irgendwie auswählen, der andere sagt selektieren, der dritte sagt irgendwie XY ist passiert.

Wir meinen dasselbe und können uns idealerweise direkt darauf einigen, sagen so okay, jetzt haben wir eine gemeinsame Begrifflichkeit.

Aber gerade bei Fachprozessen kommt dann oftmals so dieses, aber eigentlich aus einer bestimmten Perspektive heraus ist es halt doch nicht das gleiche und reden wir jetzt noch über den gleichen Prozess.

Das ist super spannend und das wäre zum Beispiel auch so was, wo ich dann wahrscheinlich wie Martin entsprechend einen Hotspot kleben würde und sagen würde, da schauen wir noch mal ein bisschen tiefer drauf rein.

Hier ist irgendwie zum Beispiel noch nicht geklärt, was verbirgt sich in einem gleichen Begriff.

Ich habe das jetzt hier irgendwie auch in dem Schaubild, also das ist ein Trainingsbeispiel, das ist halt irgendwie ein super einfaches Eventstorming.

Da habe ich jetzt irgendwie so Hotspots, also da habe ich jetzt zum Beispiel das Event Paketdienst Spedition gebucht.

Dann habe ich hier irgendwie so eine Frage mit, muss man was für Retouren beachten, das ist also etwas, wo jetzt was noch unklar ist.

Und da Paketdienst Spedition ausgewählt, da habe ich jetzt irgendwie hingeschrieben, was ist mit zusätzlichen Dienstleistungen.

Das sind also Dinge, die jetzt irgendwie nicht klar sind, die man nochmal lösen will.

Und da sind lila Postings, glaube ich, angesagt.

Also das ist halt das, worüber wir da sprechen.

Weil du gerade sagst lila Postings, das ist auch so eine beliebte Frage.

Also es gibt halt so eine kanonische Zuordnung, welche Farben haben welche Bedeutung.

Das ist super, das macht es uns halt einfacher, mit so einem visuellen Vokabular zu arbeiten.

Aber natürlich muss das nicht immer genau diese Bedeutung haben und diese Farbe.

Also es kann jetzt passieren, dass der eine oder andere erwartet jetzt, dass natürlich jetzt die Mapping-Polizei kommt und auf die Finger haut und sagt, das muss aber eigentlich ein um 90 Grad gedrehtes rotes Sticky sein oder sowas.

Je nach Möglichkeit nimmt man halt das, was man gerade hat.

Und hier ist jetzt ein lila Posting.

Also ich habe tatsächlich eben in einem Kontext, ich glaube, das war sogar eine vorherige Version von diesem Ding hier, die postet nach den Rollen, die halt diesen Event sozusagen auslösen, differenziert.

Und ich muss gestehen, ich hatte halt ein schlechtes Gewissen, weil es gibt ja irgendwie diese festgelegte Semantik.

Aber ich fand das halt in dem Kontext hilfreich und habe es dann halt irgendwie gemacht.

Völlig legitim, das gilt wie bei allem.

Also idealerweise haben wir eine Legende, wo halt irgendwo steht, diese Farbe hat diese Bedeutung.

Und ja, dann ist das auch schon wieder vom Tisch.

Also bei einem Event-Storming muss man natürlich daran scheitern, dass wir nicht genug lila Stickys bekommen haben oder die roten gerade nicht in dem Sammelpack drin waren, den wir geholt haben.

Dann nehmen wir die Farbe, die wir nutzen wollen und schreiben es irgendwo hin.

An der Stelle vielleicht auch noch eine Überlegung, weil wir bei den Farben sind.

Ich arbeite in einem Bereich, wo auch Accessibility ein Thema ist.

Also da gibt es auch so Themen wie Rot und Grün, schaut vielleicht nicht, schaut für manche Menschen gleich aus.

Also an der Stelle vielleicht auch ein Hinweis, immer ein bisschen auf die Gruppe schauen, mit der man das macht.

Was erkennt denn wer, wie erkennt man was?

Man kann sich da auch mit Tricks helfen, in Form von Post-its zu nehmen, die vielleicht andere Farben haben, physikalisch da ein bisschen anzupassen.

Also da gibt es viele Mechanismen und ich glaube, da muss man sehr stark auch auf die Menschen schauen, was gerade das passende Werkzeug ist.

Und dann die Legende, so wie Tom gesagt hat, zu anlegen.

Der Alexander Herold hat bei YouTube geschrieben, ich finde es immer wieder schwierig, die unterschiedlichen Flughöhen der TeilnehmerInnen zu vereinigen.

Da sage ich mal kurz was dazu.

Also das ist tatsächlich so eine Herausforderung, die du immer hast und ich sehe es aber gleichzeitig als Chance.

Also du möchtest ja im Raum alle Leute dabei haben, die was sagen können und das heißt, so viele Perspektiven da reinkriegen wie möglich.

Also idealerweise halt nicht bloß die Entwickler und irgendwie die Leute, die direkt an dem Softwareprodukt arbeiten, sondern auch vielleicht die Leute, die es später nutzen.

Die Leute, die halt die Fachprozesse besser kennen, als wir Entwickler, Architekten, you name it.

Das bedeutet automatisch, wir haben da unterschiedliche Perspektiven, Flughöhen, wie du es gerade genannt hast.

Das ist eine Herausforderung bei der Facilitation.

Also was ja natürlich passieren wird, da wird es eine kleine Gruppenbildung geben.

Da werden jetzt die Techies drüber sinnieren, wie würde ich denn jetzt X umsetzen?

Und das ist gar nicht die Frage, die wir hier stellen.

Also da muss man dann bei der Moderation zum Beispiel ein bisschen drauf eingehen, wenn es fruchtbar ist, das laufen lassen.

Aber wenn wir halt merken, wir entfernen uns zu sehr von dem, was wir hier eigentlich vorhaben, dann muss man das auch entsprechend ein bisschen in die richtige Richtung schubsen.

Und Gleiches ist natürlich auch mit den Leuten, die vielleicht eher mit verschränkten Armen da stehen und sagen, ja, was soll ich denn da jetzt machen?

Ich bin ja erst in der Fachabteilung und ich habe ja davon gar keine Ahnung.

Und die dann ranzuholen und ihnen zu zeigen, okay, du kannst aber dein Fachwissen hier mit reinbringen und wir wollen das haben.

Wir wollen ja an deinem Wissen, was in deinem Kopf sitzt, dein mentales Modell, das öffnen wir jetzt hier.

Wir wollen die Sachen erfahren, an die zum Beispiel deine technischen Kollegen bislang nicht gedacht haben.

Also das ist wahnsinnig viel mit Fingerspitzengefühl, eine Diskussion von einer großen Gruppe leiten.

Und das ist herausfordernd.

Also das hast du richtig gesehen, richtig erkannt.

Und ich glaube, auch wenn man irgendwie 500 Eventstormings gemacht hat, ist das nicht ein Selbstläufer, weil das sind halt Menschen und Menschen reagieren unterschiedlich und jede Gruppe ist unterschiedlich.

Aber da steckt halt was drin.

Und gerade beim Eventstorming, das ist das Tolle an dieser Methode, machen wir das halt nutzbar und greifbar.

Also was woanders vielleicht hinderlich ist, ist eigentlich hier so ein Winning Factor, den man entsprechend heben kann, nutzen kann.

Aber es erfordert was.

Ich habe nochmal irgendwie über die Frage sinniert und ich frage mich, also diese unterschiedlichen Flughöhen sind ja, würde ich jetzt mal behaupten, eher ein Feature als ein Bug.

Das heißt also, die unterschiedlichen Menschen haben ein unterschiedliches Detailierungsgrad und unterschiedliche Perspektiven.

Und da steht ja irgendwie Verein.

Ich weiß nicht, ob ich das muss.

Also muss ich das tatsächlich, die Sachen vereinen?

Also ich könnte mir halt gut vorstellen, dass es halt hilfreich ist zu realisieren, dass da halt irgendwie diese Person ist, die halt in diesem Bereich halt super detailliert unterwegs ist und halt alle Details versteht.

Und ich muss das halt, glaube ich, nicht alles, also ich muss das vielleicht erstmal nicht verstehen, aber ich weiß dann zumindest, dass diese Person halt da ist, die es dann halt irgendwie super detailliert dargestellt hat.

Oder ich habe irgendwie eine andere Person, die halt irgendwie einen Überblick hat und dadurch kann ich das einordnen und kann halt versuchen, dort eine Dialogentgange zu setzen.

Aber ich finde, die verschiedenen Flughöhen können durchaus nebeneinander laufen und müssen nicht vereint werden.

Da sehe ich da irgendwas falsch.

Ich finde auch ganz gut, was man da vielleicht von der Formulierung her, das anders formulieren könnte, wäre anknüpfungsfähig.

Also ich glaube, gerade wenn wir mit unterschiedlichen Flughöhen sprechen, dann ist das, und da finde ich den nächsten Kommentar auch ganz gut im Chat, so manchmal denken, werden auch Unbekannte aufgedeckt.

Also gerade diese Flughöhen können auch ein Hinweis sein, dass es Lücken gibt, und das ist ja ein Problem in der Anknüpfung, und möglicherweise müssen wir genau in diese Lücken hineingehen, um das anknüpfbar zu machen, und vielleicht heißt es einfach vereinen, gemeinsam ergänzend anknüpfbar die Sachen hinzubekommen, und was das im Konkreten bedeutet, dann gemeinsam auch herauszufinden.

Genau, ich lese es noch kurz vor den anderen Kommentar, auf den du dich hat bezogen hast, von Astrid Sabatski, und zwar sagt sie, manchmal decken diese am Thema vorbei, in Anführungsstrichen, Gespräche auch ein Problem auf, das immer gestört hat, aber unentdeckt blieb, und das bestätigt vielleicht, dass diese Vereinheitlichung nicht so notwendig ist.

Genau, und Alexander hat sich da noch bedankt.

Gut, damit haben wir ganz viel auch schon diskutiert, darüber, was jetzt eigentlich so, wie soll ich sagen, Herausforderungen sind, und halt Schwierigkeiten.

Wollen wir weitermachen mit den nächsten Schritten von dem Event-Storming, oder haben wir noch irgendwas zu diesem Endforce Timeline?

Sonst würde ich mal wieder sozusagen auf das Miro Board gehen.

Also gehen wir mal rüber, wir können später noch ein bisschen was über das Doing erzählen.

Genau, und zwar, wenn man sich das jetzt anguckt, dann sieht man ja, dass das irgendwie strukturiert ist.

Also hier sind eben diese Post-its.

Ich zeige das jetzt mal, weil ich mir sonst halt so ein bisschen komisch vorkomme.

Also im wirklichen Leben habe ich halt deutlich, deutlich mehr, und das ist halt auch irgendwie in einem deutlich größeren Umfang.

Ich habe halt dieses eine Beispiel mal zusammengebaut, um halt einfach mal was zu haben, worüber man irgendwie reden kann.

Und hier sieht man jetzt, dass eben so ein Event hier hervorgehoben ist, dass die Bestellung eingegangen ist.

Hier hinten ist noch so ein Event, was ich hervorgehoben habe, durch so einen senkrechten Strich.

Das ist Lieferung an Paketdienst, Spedition übergeben.

Also wir haben halt offensichtlich irgendeinen Bestellprozess.

Das ist mal so mein Hello World Beispiel.

Und das sind halt diese Pivotal Events.

Pivotal ist so ein Begriff aus dem Englischen, der halt sagt, dass etwas sich so fundamental ändert.

Und Bestellung eingegangen ist halt, würde ich behaupten, ein Pivotal Event, weil sich die Welt ändert.

Also danach gibt es eben tatsächlich die Bestellung.

Danach passieren irgendwelche Prozesse.

Davor war es noch so, dass ich irgendwie Dinge in den Einkaufswagen reintun kann und rausnehmen kann.

Das kann ich jetzt nicht mehr.

Den Einkaufswagen gibt es auch nicht mehr.

Das heißt, die Welt hat sich irgendwie einmal sehr fundamental geändert.

Und deswegen ist es eben ein Pivotal Event.

Da gibt es eine ganze Menge an Heuristiken, um solche Pivotal Events zu identifizieren.

Was wiederum bedeutet, dass das nicht so super krass exakt definiert ist, was denn nun ein Pivotal Event von was anderem unterscheidet.

Würde ich jetzt jedenfalls behaupten.

Aber es ist eben so, dass danach die Welt deutlich anders aussieht.

Also das wäre so ein Pivotal Event.

Und eben würden wir jetzt versuchen, sowas zu identifizieren.

Also eine Charakteristik von so einem Pivotal Event.

Du hast gerade gesagt, danach ist die Welt eine andere.

Das bedeutet zum Beispiel, dass jetzt ein neues Geschäftsobjekt da ist oder dass ein Geschäftsobjekt seine Form geändert hat.

Also was vorher irgendwie in einer Form da war, ist jetzt in einer anderen.

Zum Beispiel, weil wir über eine andere Entität reden, die jetzt irgendwo verarbeitet wird.

Und das ist auch eine ganz wichtige Sache.

Vorhin habe ich die Frage aufgeworfen, was das eigentlich mit Software oder Software Design zu tun hat.

Und hier kann man schon erahnen, wir reden ja hier darüber, dass wir einzelne Bereiche finden, die in sich geschlossen sind.

Also wo eine Fachlichkeit in einem bestimmten Bereich existiert und die dann über ein Event an einen anderen Bereich kommuniziert werden kann.

Und das ist natürlich eine tolle Sache.

Auf die Weise können wir zum Beispiel unsere Prozesse strukturieren oder feststellen, dass ein Prozess, der irgendwie Ende zu Ende da ist und der wahnsinnig komplex ist, dass der aber halt irgendwelche Grenzen hat, die für uns greifbar sind.

Und was so regelmäßig passiert ist, dass man feststellt, dass die angenommenen Grenzen, so wie wir es bisher gelebt haben, vielleicht gar nicht die optimalen sind oder gar nicht die sind, die so ein Prozess haben sollte.

Also gerade wenn man sowas macht, nicht auf der grünen Wiese, sondern um einen bestehenden Prozess zu verstehen und mal wirklich alle Leute dazu zu holen, die damit zu tun haben, dann findet man diese Pivotal Events, man findet Grenzen und man stellt fest, okay, die Welt, wie wir sie kennen, ist gar nicht so, wie wir sie jetzt hier gerade anfangen zu modellieren.

Und das wirft Fragen auf.

Also zum Beispiel hätten wir einen Vorteil davon, etwas anders zu machen.

Eine Modellierung hilft uns ja zu erkennen, wie es zum Beispiel sein könnte.

Und das ist so ein netter Effekt, den wir da eben heben können.

Ich glaube, eine spannende Heuristik, auch wie findet man Pivotal Events in der Praxis, ist, also was ich gerne mache, ist, ich beobachte Arbeitsprozesse und überall dort, wo Übergaben passieren, das könnte ein Hinweis sein mit, möglicherweise ist das ein Pivotal Event.

Also nämlich in der Praxis, Übergaben zwischen Menschen, Übergaben zwischen Organisationen, Abteilungen und so weiter, das könnten alles so Hinweise sein, wo man ein bisschen genauer draufschauen könnte.

Genauso, nicht so was, vielleicht Lieferungen an Pakete in Speditionen übergeben und danach ist die Welt halt eine andere, weil ich jetzt nicht mehr sagen kann, also das Paket mir sozusagen nicht mehr gehört und weil ich es jetzt auch nicht einfach nicht mehr rausschicken kann, sondern es ist eben draußen.

Ich kann es halt höchstens nochmal irgendwie sozusagen zurückbekommen.

So was wäre vielleicht dort genauso eine Übergabe.

Das andere sind so Swimlanes, also parallele Aktivitäten.

Habe ich jetzt in diesem Beispiel, wie gesagt, das ist halt bewusst einfach und reduziert, habe ich halt im Prinzip eine Swimlane, die hat sagt, okay, ich schicke eine Rechnung raus und kümmere mich um die Bezahlung.

Das nehme ich halt an, ist eine Swimlane und ich habe die andere Swimlane, die irgendwie dafür sorgt, dass das Zeug zum Kunden kommt und das sind halt im Wesentlichen parallele, relativ unabhängige Aktivitäten.

Also dazwischen gibt es halt dann schon ein paar Berührungspunkte und die sind dann, also weil ich halt idealerweise will, dass eine Rechnung rausgeht, das Ding bezahlt wird und es halt außerdem noch beim Kunden ankommt.

Das heißt, ich werde da schon ein bisschen Kommunikation untereinander haben, aber es sind eben im Wesentlichen relativ unabhängige Aktivitäten.

Ich habe ehrlich gesagt, ich weiß gar nicht, wie ihr es seht, das Gefühl, dass das mit den Swimlanes sich manchmal schon bei der Timeline ergibt, während das mit den Pivotal Events für mich schwieriger zu sein scheint.

Und da hat eher so Diskussionen entstehen, die halt sagen, ist das jetzt wirklich ein Pivotal Event, wie ihr es seht.

Also Diskussionen hast du auf jeden Fall und das ist halt auch genau das Fruchtbare.

Ich glaube, es gibt nicht den Algorithmus oder nicht irgendwie das, was sagt, man hat zuerst das eine oder das andere und so findet man die.

Ich kenne beides.

Also ich kenne noch Sachen, wo du gar keine Swimlanes brauchst oder halt auch welche, wo relativ früh klar wird, eigentlich sind hier völlig unabhängige Dinge, die parallel passieren und dann sind diese Swimlanes natürlich wunderbar, um das zu strukturieren und dem Ganzen halt ein bisschen eine Ordnung zu geben, was dann zum Beispiel auch diese Diskussion erleichtert.

Also vielleicht finden wir diese Idee, es gibt so drei parallel stattfindende Swimlanes, bevor wir halt nennenswert weit sind in der Ordnung unserer Events.

Bislang gesagt, dann werden die halt irgendwie zeitlich geordnet, aber das ist ja der Knackpunkt.

Also diese Ordnung überhaupt mal zu finden, das ist so dieser Teil, der ganz viel Diskussion beinhaltet und die wird manchmal dadurch einfacher, dass wir zumindest verstehen, okay, es gibt so verschiedene Sachen, die wir so in diesen Swimlanes unterbringen können, also zum Beispiel Teams, die unterschiedliche Aufgaben zeitgleich erledigen oder sowas und dann ist es natürlich deutlich einfacher zu verstehen, okay, dieses Event gehört irgendwie vor ein anderes, aber nicht notwendigerweise in der gleichen Swimlane oder um das andere sinnvoll zu machen, halt eben gerade genau da in die gleiche mit rein.

Also das zu erkennen, ist sehr hilfreich, aber es ist jetzt nicht so ein Selbstläufer oder irgendwie das Ding, wo man sagt, das ist die Heuristik, die mir immer sagt, ich brauche diese Swimlane oder die muss da sein.

Das ergibt sich typischerweise aus dieser dynamischen Diskussion heraus.

Was ich auch sehr oft beobachte, ist, wenn man anfängt, die Swimlanes einzuziehen, dass dann so Diskussionen starten mit, gehört das zusammen, gehört das auseinander, haben wir eine Abhängigkeit?

Heute haben wir eine Abhängigkeit, wollen wir eine Abhängigkeit haben?

Eigentlich nicht.

Was bedeutet das?

Also viele Sachen, die bisher eher unbewusst und implizit waren, auf einmal explizit werden und auf einmal entscheidbar werden.

Das sind so die ersten Schritte, die dann passieren und das in ganz unterschiedlichen Reihen folgen.

Ich habe noch eine, damit haben wir das glaube ich so im Groben durchdiskutiert, wie so ein Mindestens-Design-Level-Event-Storming aussehen kann.

Ich habe eine Anmerkung, fragen wir auch immer, auch von dem MD42Martin bei YouTube.

Hybrid-Setup ist bestimmt auch eine Herausforderung.

Was ist mit Hybrid gemeint?

Hybrid klingt für mich, ich habe sowohl als auch.

Das würde ich komplett vermeiden.

Ich nehme an, Menschen, die über dieses Internet miteinander kollaborieren und Menschen, die vor Ort sind.

Das würde ich gar nicht machen.

Leute im Raum haben und welche, die nur über eine Kamera zugucken, das kann ich mir gar nicht vorstellen, wie das funktionieren soll.

Ich weiß nicht, ob da jemand Erfahrung mitgemacht hat.

Ich glaube, die klassische Entscheidung ist, schaffen wir das, alle Leute in einen Raum zu kriegen.

Klar, Event-Storming funktioniert am besten, physisch im gleichen Raum haptisch das Ganze zu machen.

Es gibt natürlich die Variante, das auch remote zu machen, auf sowas wie einem Miro-Board.

Da habe ich sogar ein paar Vorteile.

Zum Beispiel kann ich Dinge leichter duplizieren, leichter kopieren, leichter hin- und herschieben.

Dinge, die in der realen Welt nicht so einfach sind.

Auf der anderen Seite haben wir technische Hürden.

In einem Format, in dem ich mit Breakout-Räumen arbeiten muss, habe ich nicht diese freie Diskussion, wo sich Klüngel bilden.

Drei Leute stehen physisch vor dem gleichen Ausschnitt von einer langen Wand.

Darüber haben wir noch nicht gesprochen.

Ich habe einen gewissen Platzbedarf.

Ihr seht es auch hinter mir.

Das sind Artefakte von Event-Storming, die übrig geblieben sind.

Ich brauche Platz.

Wand bekleben mit Packstreifen und sowas.

Wir stehen physisch davor und reden über die Dinge, die da kleben.

Das nachzubilden, rein remote, ist schwierig.

Ich habe Ansätze gesehen mit so Sachen wie Gather-Town.

Das ist cool.

Da können Leute wirklich irgendwo beieinander stehen.

Man kann das nachbilden, aber es ist nicht das gleiche.

Das ist eine Inaction von einem Board.

Ihr seht, da ist eine Ebene oben drüber.

Da ist richtig viel gemacht worden.

Es steckt wahnsinnig viel Potenzial darin, dass die Leute sich miteinander spontan vor ein paar Stickys stellen können und darüber diskutieren.

Das nachzubilden, ist eine Herausforderung.

Das heißt nicht, dass es nicht geht.

Es gibt mittlerweile Patterns, die einzelne Leute beschreiben, wie man mit Event-Storming remote gut arbeiten kann.

Ich kann das von mir aus sagen.

Ich mache das am ehesten mit Teams, die schon mal zusammen ein Storming gemacht haben, die die Mechanik an sich kennen, die das Ganze machen und dann eher kleine Sachen.

Also nicht 30 Leute in einem virtuellen Raum, sondern eher so was wie sieben, acht Leute, die sich etwas Kleineres angucken und wo wir das viel besser steuern können.

Aber das ist Geschmackssache.

So mache ich das eher.

Das kann man sicherlich auch ganz anders tun.

Ich würde auch denken, es gibt Vor- und Nachteile.

Was ich an den digitalen Formaten gut finde, ist, dass es automatisch archiviert ist.

Ich kann es wieder herausführen.

Ich kann später daran noch mal arbeiten.

Aber es wird ja schon diskutiert, dass die Artefakte nicht das Zentrale sind.

Ich würde bei einem hybriden Setup versuchen, diese informellen Möglichkeiten zum Austausch zu erzeugen.

Diskussionen über das Mittagessen sind nicht möglich.

Also müssen wir irgendetwas machen, um diese Sachen rauszukitzeln und die Reihe zu bekommen.

Also eben noch mal fragen.

Was ist euch aufgefallen?

Gibt es Dinge, die ihr diskutieren wollt?

Möglichkeiten bieten, diese Sachen nachzuempfinden, um diesen Nachteil zu kompensieren.

Ich bin nicht sicher, ob ich unterschreiben würde, dass ich auf jeden Fall Präsenz machen wollen würde, weil das andere Trade-offs hat.

Wenn ich eine verteilte Organisation habe, die Menschen über verschiedene Standorte verteilt sind, bedeutet das, dass sie reisen müssen.

Das bedeutet, ich muss innerhalb von ein oder zwei Tagen komprimiert alles machen.

Da bin ich mir durchaus unsicher, ob es nicht schlauer ist, das weniger komprimiert zu machen.

Dafür muss man sich virtuell die Karten legen.

Aber hybrid würde ich auf keinen Fall machen, wegen dieser Kommunikationsasymmetrie.

Die Menschen, die vor Ort sind, werden besser miteinander kommunizieren als der Rest.

Das ist, glaube ich, tödlich.

Ich glaube, zusammenfassend, was man da sagen kann, ist, dass Hybrid-Setups oder Online-Setups einfach eine andere Form der Facilitation brauchen und eine andere Art der Vorbereitung.

Allein schon aufgrund der Zeitdauer, die man darin verbringen kann, aufgrund der Parallelität der Gespräche, die man technisch nicht so gut führen kann.

Also ich höre, was die andere Gruppe da drüben gerade sagt, und ich kann darauf reagieren, das geht im digitalen Raum heute einfach nicht so gut.

Also dieses Großvernetzen.

Und das sind so die kleinen Mechaniken, die im Event-Storming aber irrsinnig viel ausmachen und die man dann kompensieren muss mit einer guten Facilitation, mit einem guten Setup, mit anderen Gruppengrößen vielleicht, die man dann auch aufbaut.

Vielleicht auch mehr durch ein moderiertes System.

Da gibt es ganz unterschiedliche Mechaniken, die man da nutzen kann, auf die man da zurückgreifen kann.

Gut.

Also man kann es auch weiter ausdifferenzieren.

Man kann also jetzt irgendwie auch noch anfangen und kann da runtergehen auf Aggregates und versuchen, halt im Command-Suite externe Systeme und so weiter zu modellieren.

Das wollten wir, glaube ich, irgendwie nicht diskutieren hier im Stream, aber das ist eine Möglichkeit, da noch weiter zu differenzieren.

Und das ist ja auch schon so ein bisschen angeklungen.

Ein mögliches Ergebnis ist eben, oder deswegen ist es interessant, dieser, zumindest aus einer Software- Strukturperspektive, dieser Bereich, der eingegrenzt wird von so Pivotal Events und von Swimlanes, ist auf jeden Fall verhältnismäßig unabhängig von anderen, weil er parallel ist zu Dingen, die parallel arbeiten, weil sich durch den Pivotal Event die Welt sehr stark geändert hat.

Das heißt, wenn wir dieses Ding nehmen und das als Modul unserer Software identifizieren, sind die Chancen relativ gut, dass das eben ein fachlich unabhängiges Teil unserer Software ist.

Und das ist so ein bisschen die Software-Strukturperspektive.

Man muss trotzdem noch mal darüber nachdenken, ob das, also man kann es nicht einfach raus kopieren und sagen, das ist es jetzt.

Ein Standardbeispiel ist, wenn ich jetzt Retouren habe, ist die Frage, ob das Versenden von Retouren so ähnlich ist, wie das Wegschicken aus meinem Lager, dass ich das mit demselben Modul erledigen will.

Und ich bin halt auch zum Beispiel nicht sicher, ob ich da hinten mit der Lieferung das Lager verlassen, ob ich da tatsächlich ein neues Modell brauche, um das abzudecken, oder ob ich damit hinreiche, das Modell zu benutzen, was ich für den Teil davor hatte.

Hier ist eine Frage.

Ich weiß nicht, ob ihr da ergänzen wollt, sonst würde ich zu der Frage übergehen.

Ich wollte eigentlich noch einen Satz dazu sagen, was du vorher noch angesprochen hattest, also mit den anderen Farben.

Bei dem minimalen Beispiel sieht man, da gibt es wirklich nur Events und das kann in vielen Fällen reichen.

Das heißt, das kann super niederschwellig sein, sowas mal eben schnell zu machen.

Das heißt nicht, dass wir jetzt auch gleich Buy-In bekommen.

Das geht ein bisschen auf die Frage ein, dass Leute auch dann dazukommen.

Aber im einfachsten Fall sieht ein Event-Storming tatsächlich so einfach und einfarbig aus.

Aber man kann das natürlich weiter treiben.

Das dann in eine Richtung treiben, wo wir zum Beispiel einen Prozess oder ein Software-System mitgestalten können.

Das ist eben auch eine Option.

Das ist die, die die Leute am meisten vor dem Auge haben, wenn sie Event-Storming hören.

Deswegen sei einfach mal gesagt, es kann auch ganz easy aussehen und sich wirklich auf die Events alleine konzentrieren.

Allein das bringt schon mal einen Mehrwert, zum Beispiel in Form von diesen Grenzen finden oder Bereiche haben.

Dann können wir zu der Frage kommen.

Die Frage kommt von TheNamless555666 bei YouTube.

Er oder sie sagt, als Fan von Event-Storming, wie überzeuge ich meine Führungsebene, das Zeit und gegebenenfalls auch Geld für vor Ort zu investieren, um Event-Storming möglich zu machen?

Die Ergänzung ist dann natürlich die Kunden, dass das sinnvolle und justizierte Zeitbudget aus ihrem Topf ist.

Ich habe so viel geredet.

Sag doch du auch mal was dazu.

Ich kann ja garantiert was ergänzen, aber fang doch du mal an.

Ich finde das eine ganz schöne Frage.

Ich kenne die Herausforderung.

Ich versuche immer mit einem Beispiel bei sowas anzufangen.

Ich glaube, wir kennen das alle, diese vielen Meetings, in denen wir sitzen, wo ein Protokoll nach dem anderen zusammengeschrieben wird und wir damit nicht weiterarbeiten können und diese Meetingzeiten, die überhand nehmen.

Und ich glaube, da ist die Frage, was könnte eine sinnvolle Alternative sein, um in eine strukturiertere Kommunikation zu gehen und eine strukturiertere Ausarbeitung.

Und das ist für mich ein Hebel, der eigentlich sehr gut funktioniert, in solchen Situationen herzugehen und zu sagen, wir können diese Informationen, diese Art der Zusammenarbeit auch ein bisschen besser strukturieren und auch den Teilnehmern damit Zeit zurückgeben.

Und ich glaube, das ist das, was wir überall beobachten.

Zeit hat heute keiner mehr und Zeit einsparen zu können und Kommunikation zu strukturieren, ist total hilfreich.

Und ich glaube, das ist auch etwas, was nachvollziehbar ist.

Tom, was möchtest du ergänzen?

Was ist denn dein Magic?

Wie würdest du das angehen?

Also der Indikator, wir kommen nicht weiter.

Also wir haben jetzt das dritte Meeting gemacht.

Das kostet ja auch tierisch Zeit.

Und dann kann man durchaus fragen, also gibt es nicht ein anderes Format, was uns einfach mehr helfen kann?

Das erfordert trotzdem ab und zu mal Mut.

Es ist nicht jeder dafür offen, dass wir sagen, wir gehen jetzt auch mal über Teamgrenzen und über Abteilungsgrenzen hinweg und holen uns da Leute raus.

Aber es ist halt auf der Hand, wir können damit eine bessere Entscheidungsgrundlage schaffen.

Also statt, dass wir jetzt noch mal irgendwie das vierte Meeting machen, wo wieder zehn Leute Däumchen drehen, während sich zwei über die gleiche Sache streiten.

Dann ist das vielleicht ein guter Einwand zu sagen, Mensch, wir machen was, was also direkt auch visualisiert.

Was haben wir denn hier für verschiedene Sichtweisen und Perspektiven?

Und ich glaube, dass da wahnsinnig viel drinsteckt.

Das ist so eine Sache, die als Selling Point durchaus funktionieren kann.

Also damit würde ich es zum Beispiel mal probieren.

Gemeinsames Verständnis aufbauen, aber auch konkret die verschiedenen Perspektiven reinkriegen.

Also ich finde das gut.

Ich finde Daniels Idee mit sozusagen zu sagen, wir sparen halt, passt halt gut, weil das sozusagen genau die Frage ist, die sozusagen im Raum steht.

Ich habe bei dir Tom irgendwie rausgehört, sowas wie, wenn es halt gescheitert ist, hat man ein leichteres Spiel.

Finde ich auch eine gute Idee.

Eine allgemeine Bemerkung an der Stelle, also die eine Sache, die ich halt, ich weiß nicht, ob das überzeugend ist, ich finde Eurowiga sehr gut, aber die eine Sache, die mir dabei auffällt ist, wir reden über ein Projekt, was Monate oder Jahre oder so dauert, also wir reden ja über ein komplexes Setup und da irgendwie ein oder zwei Tage, zwei Tage miteinander zu reden, ist keine signifikante Investition.

Also im Gesamtprojektbudget ist das halt verschwindend.

Man kann es kombinieren mit so etwas wie einem Kick-Off, dann hat es nämlich auch den Vorteil, dass man dort die Menschen sich sozusagen kennenlernt und das könnte dann sozusagen noch ein zusätzliches Bonbon sein an der Stelle.

Ich werde nicht müde, das zu erzählen, ich weiß nicht, ob es halt hilft, aber das Involvement von Domain-Expertinnen ist einer der zentralen Erfolgsfaktoren für Software-Projekte und wir wissen das seit den 50er oder den 60ern.

Also ich habe eine Episode gemacht zu dem Projekt, wo es halt das erste größere Projekt, was wir als Menschheit gemacht haben in Form von Software-Entwicklung, da ging es halt um das Luftverteidigungssystem in den USA.

Da war irgendwie eine von den Lessons learned.

Wir sollten halt mehr mit Kundinnen reden.

Die andere Erfahrung, also nicht das Rolls-Paper aus Ende der 60er, wo es halt angeblich um Wasserfall geht, darum geht es da nicht, es geht um iterative Entwicklung, sagt halt, wichtiger Punkt ist Kunden-Involvement und ich könnte jetzt noch die Formel-1-Anekdote erzählen, aber ich glaube, das spare ich mir.

Also die Formel-1-Anekdote ist, dass ein Team, nämlich Aston Martin, im Moment gar nicht so gut dasteht und offensichtlich haben die zu wenig mit ihren Fahrern geredet und dann haben die Autos an den Fahrern irgendwie vorbei entwickelt.

So jedenfalls YouTube-Shop, was ich gestern gehört habe, was halt bedeutet, dass auch in so super technischen Bereichen, wo man es halt gar nicht denkt, nicht miteinander reden und halt auf Kunden hören, der vielleicht wichtig ist.

Da ist das halt zentral und ich glaube auch, deswegen sitzen wir hier, weil uns das eben subjektiv wichtig ist und eben auch eine Sache, die halt relativ gut funktioniert, glaube ich.

Ich glaube, weil du jetzt auch gerade viel gesprochen hast von Reden und Hören, dass es sehr oft einfach auch hilfreich ist und das ist das, was ein Event-Storming macht, dass Visuelle das sehen können.

Also etwas zu sehen, das funktioniert im Gehirn auch ganz anders, wenn man sich ein bisschen damit beschäftigt.

Diese Validierung über Sehen und diese Simulation, die da passiert, die macht einfach etwas ganz anderes draus und das ist eine andere Form der Informationskonsumation, die halt auch super wichtig ist.

Vielleicht auch noch mal kurz was dazu sagen und zwar so ein Event-Storming kann selber ein Pivotal-Event sein und zwar in der Art, wie wir zusammenarbeiten.

Also das heißt, wenn wir alle uns einig sind, es wäre besser, wir reden mehr mit der Fachabteilung oder die reden mehr mit uns oder wir reden mehr gemeinsam.

Das haben wir bisher nicht hinbekommen, weil es in diesen Meetings nicht klappt.

Dann kann das genau das Event sein, was das ändert, denn da sitzen die Leute, stehen die Leute besser gesagt im gleichen Raum und reden zum ersten Mal vielleicht wirklich miteinander über Dinge, wo es vorher nicht geklappt hat.

Was man oft sieht, also das bekomme ich oft als Feedback dann hinten raus, das hält an.

Also das war dann nicht nur in diesem Raum so, zu dieser Zeit so, sondern jetzt haben die Leute sich kennengelernt und wissen, mit wem sie zum Beispiel zu bestimmten Themen immer wieder auch mal reden können.

Sei es mal am Mittagstisch oder halt auch tatsächlich die Meetings danach sind zielgerichteter, weil wir neue Kommunikationswege überhaupt mal gezeigt haben oder erfahren haben und das ist, wie ich finde, ein riesen Vorteil und auch das ein Selling Point.

Also gerade an den Punkten, wenn ihr merkt, alle wissen, es müsste anders gehen, da ist eigentlich eine Bereitschaft da, es fehlt nur an der Idee, wie.

Dann lasst das das Ding sein, was die Lawine ins Rollen bringt.

Wir können noch mal kurz in den Chat gucken.

Also Pilosaurus bei Twitch hat gesagt, wir hatten Wiederholprobleme in einem Themenbereich, Bugs, überzogene Tickets.

Das habe ich zum Anderen für ein Mini-Event-Storming-Domain-Modeling genommen.

Passt ja genau in das, was wir schon diskutiert hatten, also was du insbesondere gesagt hast.

Dann hat MD42Martin geschrieben, eine Idee kann auch sein, Tech-Leads auf die Pro-Event-Storming-Seite zu bekommen, zum Beispiel Stickies.

Und die Pivoted Events können ein Hinweis auf voranbauende Kontext sein.

Ja, also nicht, das kann der Einstieg in Design sein.

Und Astrid hat geschrieben, viele BenutzerInnen verstehen beim Event-Storming erst, wie komplex auch ein einfaches Problem wird, wenn man es so genau definieren muss, wie es zur Programmierung notwendig ist.

Viele ProgrammiererInnen verstehen erst, dass sie eben nicht verstanden haben, was das eigentlich Problem ist.

Das finde ich auch sehr schön und sehr hilfreich.

Mein Beispiel ist ja immer die Anforderung, wir brauchen ja nur eine Checkbox in der Software.

Und wenn man sich das dann genauer anschaut, sind das dann oft Workflow-States und dann auch noch Folge-Events, die dann entstehen und so weiter und so weiter.

Und auch dieses mit Fachabteilungen dann das Durchdenken und Durcharbeiten zu können und auch da gute Lösungen dann gestalten zu können, das ist dann halt etwas, was dann auch viel leichter geht, wenn man das gemeinsam macht.

Also daneben, das schreibt noch, danke für die Antworten.

Ich werde auch nochmal versuchen, die Kurve zum Programmieren als Modellbildung zu versuchen in meiner Argumentation.

Genau dazu gibt es eine Episode zu der Theoriebildung, die ich vor einiger Zeit geführt habe.

Wie fange ich denn an damit?

Wie startet man?

Prinzipiell sind die Voraussetzungen natürlich super.

Event-Stormings und Technik, ich glaube, die ist 2017 so angefangen worden zu beschreiben oder ich glaube aus der Zeit kommen so die ersten Dinge.

Es ist seitdem sehr, sehr viel geschrieben worden.

Es gibt dieses noch immer nicht fertige Buch von Alberto, das wird wahrscheinlich nie fertig werden, aber es ist auch in dem Zustand einfach super brauchbar und quasi die Referenz drauf, günstig zu haben, plus tausende Blogposts.

Also da mal reinzukommen und sich Sachen anzugucken, ist easy, aber trotzdem ist natürlich eine Hürde da.

Und wir haben ja schon ein bisschen darüber gesprochen.

Also es gibt diese organisatorischen Hürden, die uns vielleicht davon abhalten, so viele Leute zusammenzukriegen.

Plus man muss sich natürlich bewusst machen, ganz, ganz viel.

Danke Marco.

Wir haben ja einen der Protagonisten der Szene hier im Chat mit dabei, 2015.

Dann habe ich glaube ich einfach nur vorher mich dafür noch nicht interessiert.

Also es gibt es halt alles schon lange und die eigentlichen Hürden, die kommen tatsächlich eher so, wenn es darum geht, wie kriegen wir das Ganze in die Organisation rein, das hatten wir angesprochen gehabt.

Und wesentlich hängt das Ganze natürlich davon ab, dass wir eine Facilitation brauchen und die muss einigermaßen funktionieren, damit diese Kommunikation gut funktioniert.

Also das Ganze lebt halt davon, dass wir dieses kreative Chaos haben.

Und das zulassen zu können, das trotzdem ein bisschen zu steuern, also am Anfang so dieses Divergieren, wir gehen auseinander mit vielen verschiedenen Ideen und wir konvergieren dann, das muss man vielleicht ein bisschen geübt haben.

Und das ist je nach Organisation einfacher oder schwieriger, je nach Fallhöhe.

Also vielleicht verzeiht man das eher, wenn man sagt, okay, wir üben das mal im kleinen Kreis und wenn es nicht funktioniert, dann probieren wir es nochmal.

Aber gerade wenn ihr merkt, oh, das sollte sitzen beim ersten Mal, gerade weil viele Stakeholder dabei sind, gerade weil da vielleicht viele Kritiker dabei sind, dann ist der Einstieg daraus natürlich ein bisschen schwieriger und dann holt man sich vielleicht jemanden dazu, der es schon mal gemacht hat.

Oh ja, das Thema mit den orangefarbenen Stickys, ich greife das direkt auf.

Das ist ein Problem und Material ist halt so ein Ding.

Es gibt genau einen Hersteller, der vernünftige Stickys anbietet.

Ich glaube, die Werbung darf man machen.

Das sind 3M-Superstickys, alles andere funktioniert nicht, weil es spätestens nach ein paar Stunden von der Wand bröselt.

Astrid schrieb gerade, das Schwierigste ist, aus rein orangefarbenen Stickys zu bekommen.

Ja, genau.

Das ist durchaus eine Hürde.

Also was macht man da?

Wir sind dazu übergegangen, wir machen halt einfach so Sets, Box Awesome nennen wir die, da haben wir alles drin, die bringen wir zu Event-Stormings mit.

Dann muss man sich da weniger Gedanken machen und da sind genug davon drin.

Wir haben dafür einen Deal mit 3M gemacht.

Das ist die schwierige Variante.

Aber ja, das Material zu kriegen, das ist manchmal eine Herausforderung.

Man braucht viele Stickys und man kann natürlich auch die nehmen, die man übrig hatte.

Dann muss man sich klar sein, die müssen nicht orange sein.

Heute in der Session sind sie halt mal blassblau, weil das sind die, die wir immer übrig hatten von etwas anderem.

Das geht natürlich auch.

Also ich finde es gut und richtig, dass du auf das Buch hinweist.

Es gibt ja auch Sachen, die man im Internet finden kann.

Wir hatten vorhin schon diskutiert über dieses Programmierung als Theoriebildung und eines von den Dingen, die Nauer in dem Paper diskutiert hat, ist, dass er der Meinung ist, dass man Softwareentwicklung und Programmierung eigentlich nur so lernen kann, wie man ein Instrument lernt, indem man sich das gemeinsam erarbeitet.

Ich glaube, es ist relativ klar, dass man von niemandem erwarten würde, der jetzt ein Instrument spielen soll, dass die Person das einfach tut, indem man ein Buch liest.

Nauer diskutiert das über Programmierung.

Darüber kann man länger diskutieren.

Hier ist es tatsächlich so, dass man in dem Bereich ist, das klang so ein bisschen an, wo ich mir nicht sicher bin, ob ich mir das antun wollen würde, alleine, gerade wenn es halt sozusagen darauf ankommt, das zu machen, weswegen da eigentlich so ein bisschen die externe Hilfe und ich glaube, deswegen spielt es mir auch hier eine Rolle.

Ich glaube, je weiter man sich in der Organisation bewegt, je mehr Menschen man mit hinein nimmt, desto herausfordernder wird es vor allem für die Facilitation, für den, der die Facilitation macht.

Da gibt es sehr viele Möglichkeiten, um sich das zu vereinfachen.

Da gibt es sehr viele Tipps und Tricks, sehr viele Haptiken, was man in der Vorbereitung machen kann, was man währenddessen machen kann, um die Menschen zu aktivieren.

Das sind, so wie du gerade gesagt hast, Sachen, die kann man gut lernen.

Die kann man lernen und üben.

Ich glaube, genau solche Situationen zu üben, ist das A und O, um da auch sicher auftreten zu können und auch eine diverse Gruppe gut anleiten zu können.

Ich glaube, das ist auch noch ein wichtiger Punkt.

Das gilt, glaube ich, auch so für Moderationen und so für Meetings in Allgemeinheit.

Vorbereitung ist ein wichtiger Punkt.

Die Methodik selber ist gar nicht so sehr das Thema, beziehungsweise anders gesagt, wenn man in einem Meeting ist und anfängt, das erste Sticky zu malen, ist der größte Teil der Arbeit eigentlich schon getan.

Das Problem ist, das auf die Reihe zu bekommen, dass die Umgebung entsprechend gesetzt ist.

Der Marco hat noch geschrieben, der übliche Struggle zwischen einer Standardlegende für weniger Mental Load versus Farbenverfügbarkeit und pragmatischer Legende, if I had a penny for every time.

Er schlägt sich da auch auf die Seite von den Menschen, die etwas flexibler sind.

Er hat im Weiteren noch geschrieben, üben ist wichtig, machen ist wichtiger, lieber starten und lernen, was klappt, versuchen das Wissen zu perfektionieren, bevor man sich darauf zu facilitaten.

Man könnte es halt nicht in einem Safe Space sozusagen selber erst mal ausprobieren.

Das ist sicherlich eine gute Idee.

Ansonsten stehen wir auch zur Verfügung und diskutieren da gerne mit euch.

Es gibt von uns eine Kontaktmöglichkeit, sich über das Internet Zeit zu buchen oder eine Anfrage zu stellen.

Das wäre die eine Möglichkeit.

Das andere, was wir gemacht haben oder was wir tun, ist, wir haben ein Training dafür.

Einmal bei Socratory zu diesem Thema und dann zum anderen auch bei dir, Daniel, bei Tech Talk.

Ich zeige erst mal kurz noch den Hinweis auf den Bitterene Kaffee beziehungsweise auf die Möglichkeit, einen Termin mit Tom sich zu buchen.

Dann gibt es die Möglichkeit, ein Training zu machen bei Socratory.

Da gibt es bis zum vierten, zehnten auch 20% Rabatt für.

Analog hast du, Daniel, da auch ein Training.

Wir haben die Unterlagen alle gemeinsam erstellt.

Das heißt, das ist inhaltlich sehr stark überschneidend, fast identisch.

Das hängt davon ab, wer die Trainerin ist.

Das wären Möglichkeiten, da zu starten an der Stelle.

Vielleicht noch wichtig zu erwähnen, die Trainings.

Da geht es nicht nur um das Event-Storming.

Wir haben ein größeres Feld.

Wir sagen, kollaborative Modellierung ist wertvoll und sinnvoll.

Es ist mehr als nur die Praktik oder die Methode.

Erst mal sprechen wir über mehr Methoden als nur das Event-Storming, aber vor allem über die Erfolgsfaktoren.

Genau dieser Struggle, wie kriege ich das in die Organisation rein?

Wie sorge ich für einen nachhaltigen Erfolg?

Wie bereite ich das vor?

Wie bereite ich das nach?

Vielleicht genau die Sachen, die man nicht so über Buchwissen herausbekommt und die man, du hast es gerade so schön genannt, in einem Safe Space einfach mal ausprobieren kann.

Das war so ein Ding, was wir bei dem Training in den Fokus mit reingerückt haben.

Nicht nur dieses, wie klebe ich jetzt mit 20 Leuten im Raum Stickys an die Wand, sondern was braucht es, damit das auch einen Effekt hat?

Das ist das, was oftmals zu kurz kommt.

Das kann man in dem Training, glaube ich, wunderschön vermitteln.

Da würden wir uns freuen, wenn wir viele von euch darin begrüßen dürfen.

Ich habe das damals als erstes mit einer Freundin ausprobiert, dann mit einer Freundesgruppe, dann erst im Profi-Raum.

Das finde ich auch einen interessanten und spannenden Hinweis.

Das ist übrigens auch so ein Grundsatz, den ich habe, wenn ich etwas erstelle, eine Übung oder so, versuche ich die erst mal selber zu machen, weil man dann nochmal merkt, was so an Schwierigkeiten ist.

Und Marco schreibt, dass er versucht, dem Drang zu widerstehen, seine eigenen Links zu seinen eigenen Trainings hinzuschreiben.

Dann Jason Thelrum schreibt, Tipps für Toolings, wie die Ergebnisse zu persistieren, damit man das gemeinsam mit Verständnis nachschlagen kann.

Wie macht ihr das?

Da hat vielleicht jeder ein paar andere Ansätze.

Ich mache das ganz klassisch, ich fotografiere Sachen am Ende und je nachdem, was da vorher besprochen wurde, wird es dann nochmal in eine andere Form überführt oder es bleibt bei den Fotos.

Das Spannende sind eben auch die Diskussionen, die da mit rauskommen oder das, was man daraus exzerbt.

Aber vielleicht habt ihr noch andere Ansätze dazu.

Ich warte ja darauf, dass jemand eine tolle AI-Cam macht, die einem das alles schön auf Miro-Board digitalisiert.

Also mit der AI-Cam bin ich noch nicht dabei, aber auch das, in meinem Kopf schwebt das drinnen, dass wir so den virtuellen Stick schieben können.

Das wäre schon ganz cool.

Ich versuche sehr viel mit Versionierung zu arbeiten, also auch die Sachen, die du hast, als Artifakte aufzuheben und über die Zeit auch aufzuheben, damit wir ein bisschen in die Vergangenheit schauen können, was hat sich entwickelt, was lernen wir darüber hinaus und auch, wenn wir im digitalen Raum sind, vielleicht einmal das eine oder andere AI-Recording mitzumachen, um auch den Diskussionskontext aufzuheben und danach wieder anfragen zu können.

Das ist aber sehr herausfordernd, weil es natürlich in Unternehmen nicht immer möglich ist, auf diese Technologien zurückzugreifen, aber das ist auch ein Thema, wo man mit den neuen, modernen AI-Themen etwas machen kann.

Genau.

Marco schreibt gerade, Cloud-Code mit Miro-MCP ist enorm gut darin.

Wird das gilt für Explain-Colors und Zeitstrahlen?

Meine Antwort wäre, ein bestimmtes Ergebnis ist Persistenz.

In dem Sinne, dass wenn ich ein Miro-Board habe, ist das Miro-Board persistent und da kann ich wieder hingehen.

Man kann Fotos machen, wie ihr schon sagtet.

Ich muss gestehen, dass ich immer noch diesen Gedanken habe, ob das Artifakt eigentlich das Relevante ist.

Ich finde, die Tätigkeit, das nochmal aufzuschreiben, zusammenzufassen in einer anderen Form zu persistieren, ist meiner Ansicht nach nicht purer Overhead, weil man es dabei nochmal durchdenkt.

Ich bin nicht sicher, ob diese Persistierung nicht nochmal die Chance bietet, sich das nochmal zu vergegenwärtigen, wenn man das tatsächlich will.

Wenn man die Ergebnisse nicht persistiert, hat man trotzdem im Ergebnis den Austausch.

Das ist ja nur der erste Schritt.

Das Artifakt, das wir eigentlich erzeugen wollen, ist ein System, das bestimmte Features hat.

Wir wollen eigentlich ein System haben, das irgendetwas tut.

Wenn wir das ohne Code machen könnten, wäre das gut.

Alles, was wir davor tun, ist nur eine Vorbereitung darauf.

Deswegen ist für mich eher die Frage, ob man das gemeinsame Wissen und das gemeinsame Verständnis in einer Form hat, die nützlich und notwendig ist, und nicht so sehr, ob man das Artifakt kreieren kann.

Das wäre das, was ich da mitgeben würde.

Das gemeinsame Verständnis kann man verbessern, dadurch, dass man Dinge selber tatsächlich nochmal zusammenfasst oder zusammenschreibt.

Gut, das trägt auf jeden Fall was drin.

Es ist nicht nur das Persistieren des Artifakts aus dem Workshop, sondern eigentlich schon das Prozessieren von dem, was daraus kam.

Manchmal ist das die Folgeaktivität.

An einem Tag macht man das Event-Storming und am nächsten Vormittag trifft man sich und arbeitet mit den Ergebnissen.

Das ist eine Möglichkeit, wie ein Workshop aufgebaut sein kann.

Dann ist es müßig, ob das das Artifakt selber ist oder ob das schon die Folgetätigkeit ist.

Am Ende kommt ein bisschen das Verständnis raus.

Das ist eigentlich das, wo wir hinwollen.

Noch Dinge, die wir besprechen müssen, sollen, wie auch immer, die ich nicht vergessen habe, zu erzählen oder zu fragen?

Ich glaube, wir könnten da noch zwei, drei Stunden draufpacken, um mehr darüber zu reden.

Aber einen kompakten Überblick darüber, was das eigentlich ist, ist hilfreich und was das Getting Started ist, haben wir gegeben.

Dann würde ich sagen, vielen Dank für die Aufmerksamkeit.

Vielen Dank, dass ihr dabei wart.

Vielleicht sehen wir uns dann im Rahmen einer Beratung oder von einem Training in diesem Bereich.

Der Ausblick ist, dass wir Freitag ein Video live nehmen werden, aber keinen Livestream haben werden.

Ich gucke tatsächlich mal kurz selber auf den Plan.

Das Nächste, was wir geplant haben, ist Ende August.

Hier ist noch ein inhaltlicher Hinweis.

Von der Astrid persistieren mache ich möglichst im Pair mit einer weiteren Teilnehmerin.

Das finde ich auch eine gute Idee.

Gut, dann würde ich sagen, vielen Dank nochmal.

Dafür ist es etwas früh.

Bis dahin und viel Erfolg mit dem Event-Storming.

1. bis 29.

Oktober in der Therme Erding mit Eberhard Wolff und Tom Asel.

1. bis 25.

November in Wien mit Daniel Sack.

Alle Infos wie immer auf software-architektur.tv.

Denn Architektur entsteht nicht im Stillen, sondern im Team.