# Strategic Eventstorming for Cross-Functional Alignment

**Podcast:** Software Architektur im Stream
**Published:** 2026-07-28

## Transcript

Ein Hinweis in eigener Sache.
Eventstorming 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.
27.
bis 29.
Oktober in der Therme Erding mit Eberhard Wolf und Tom Asel.
23.
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.
Ja, herzlich willkommen zu einer weiteren Episode von Software-Hitik-Tour im Stream.
Diesmal geht es um Event-Storming und kollaborative Modellierung, warum das funktioniert, wie man das in der Praxis hat, 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, Coda, Coach, Consultant rund um alles, was mit Softwarearchitektur 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 Comocamp.
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 Common Camp eigentlich?
Was ist dieses Common 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 ComoCamp, wo ich dich kennengelernt habe, Eberhard.
Also ComoCamp ist dort, wo man Menschen treffen kann, wo man mit Menschen alle 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 orange-nulles Post-it.
Die Farben sind ja wahnsinnig wichtig.
Auf diesem orange-nullen Post-it steht jetzt sowas wie Boto gefunden.
Also ein Event, was wir bei Event-Storming benutzen, wäre eben so ein...
mit einem Hauptwort und einem Verb in der Vergangenheit.
Events sind Dinge, die halt irgendwie passiert sind und das wäre jetzt, ist so ein bisschen der Kern von Eventstorming, 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 sollst du mir erstmal etwas erzählen über die Methode an sich.
Also der Name sagt es ja, Eventstorming.
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 es 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 schon mal was echt Spannendes.
Also jetzt das Beispiel, was du hier gerade zeigst, ist aus einem beliebigen Eventstorming mal rausgegriffen.
zeigt es halt irgendwie eine Reihe von Events.
Oder jetzt sehen wir erstmal 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 in 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 eigentlich 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 Eventstorming ist.
Also was bedeutet das für den Domänexpertinnen und andere Menschen einladen, denen halt Posteblö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 erstmal den zwei, drei Stunden bereit bringen 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 eine 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, würde ich es nennen, ist irgendwie ein ganz wichtiges Ding davon.
Aber es hat trotzdem so ein paar Hürden, über die werden 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.
arbeiten mit erstmal sehr, sehr einfachen Mitteln.
Und ich glaube, so eine Frage, die da auch aufpoppt, ist, was hat denn das jetzt beispielsweise mit Software-Modellierung 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?
Und Spoiler, ja natürlich, das wollen wir uns natürlich nutzbar machen.
Und also 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 erstmal nicht so relevant.
Und das ist halt diese erste Phase mit der Chaotic Exploration, wo man also ...
die Menschen dazu bringen, möglichst viele von diesen Events an die Wand zu bringen und die halt dort dann festzukleben, beziehungsweise 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.
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 Bord drauf bekommen und dann in die Strukturierung gehen können.
Und ich komme nicht umhin, weil ich mir das sozusagen nochmal aufgeschrieben habe.
Also 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 Security Exploration, möglichst viele Sachen an die Wand bekommen.
Und eine Sache, die man ausprobieren kann, ist, die Leute sich sozusagen erstmal warm schreiben zu lassen.
Also eher einen Wettbewerb zu machen, man schreibt halt möglichst viele Postings zu irgendeinem Team.
möglichst viele Postings darüber, wie ein Meeting halt besonders toll laufen kann oder was auch immer, dass man halt dann erstmal ganz viele von diesen, die Leute halt dazu bringt, irgendwie schnell viele Haftnotizen zu produzieren, weil das eben das ist, was sie jetzt irgendwie tun sollten.
Und dann wäre halt der nächste Schritt, dafür zu sorgen, dass man das halt 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 halt dafür, dann in diesem nächsten Schritt dafür, dass sozusagen mehr Ordnung entsteht.
Und da ist es glaube ich auch so, oder 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 dem 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 zu 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 bis wirklich zu formulierten Events?
Das ist ein riesen Unterschied 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 erst mal 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, was eingetreten ist und das wird auch genauso beschrieben.
Und da wollen wir also nicht 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 bzw.
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 erstmal im Stillen für sich und klebt sich den Unterarm voll mit Stickys oder sonst irgendwas und dann werden die halt irgendwie erstmal, 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?
Also dadurch kriegt man halt raus, wer für was Experte oder Expertin ist und wie die Menschen halt irgendwie sozusagen zusammensitzen.
Da was auf die eben, ja, wo man später mehr miteinander reden kann oder wo man halt sicher irgendwie sozusagen nochmal 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.
Diese 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 Wissenshaustausch, was bedeutet, selbst wenn man anschließend das Produkt wegwirft, also sagt, dieses Ergebnis brauche ich halt oder werfe ich halt einfach weg, habe ich trotzdem eine Diskussion und einen Meinungsaustausch und einen 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 Metaebene 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.
Wollen wir dann in dem Prozess sozusagen weiter fortschreiten?
Also wir haben ja gesprochen über dieses Enfros Timeline, also eben dafür sorgen, dass die tatsächlich in einer bestimmten Abfolge sind.
Der MD42 Martin bei YouTube hat geschrieben, statt Duplikate entfernen, das hatte ich ja irgendwie angesprochen, wie er halt etwas, was ich machen kann, ist eine Praktik, die er empfiehlt, Hotspots zu identifizieren.
Das 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, weil eine Begrifflichkeit nicht klar ist oder weil wir mehrere verschiedene konkurrierende Begrifflichkeiten haben.
Also es ist halt die Frage, wollen wir den Prozess aufhalten oder wollen wir das später rausverlegen?
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 und sagen, 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 etwas, 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 dem gleichen Begriff.
Ich habe das jetzt hier auch in dem Schaubild, also das ist ein Trainingsbeispiel, das ist halt ein super einfaches Eventstorming.
Da habe ich jetzt irgendwie so Hotspots nicht, 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 etwas noch unklar ist.
Oder Paketdienst Spedition ausgewählt, da habe ich jetzt eben hingeschrieben, was ist mit zusätzlichen Dienstleistungen?
Das sind also Dinge, die jetzt nicht klar sind, wie man nochmal lösen will.
Da sind lila Post-its, glaube ich, angesagt.
Also das ist halt das, worüber wir da sprechen.
Weil du gerade sagst, lila Post-its, 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...
Also der eine oder andere erwartet jetzt, dass natürlich jetzt die Mapping-Polizei kommt und der 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 halt gerade hat.
Und hier ist es 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 Posts nach den Rollen, die halt diesen Events 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.
Einen Event-Storming muss man nicht daran scheitern, dass wir nicht genug lila Stickies 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.
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 Farmen haben, physikalisch da so 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 unterschiedliche Flughöhen der TeilnehmerInnen zu vereinen.
Na, 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 hier natürlich passieren wird, ist, 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 einem verschränkten Arm dastehen 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 entdecken.
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 über die Frage sinniert und ich frage mich halt, ob die, also diese unterschiedlichen Flughöhen, sind ja, würde ich jetzt mal behaupten, eher ein Feature als ein Bug.
Das heißt also, was wir, die unterschiedlichen Menschen haben, ein unterschiedliches Detaillierungsgrad 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?
Ist es nicht, also ich könnte mir halt gut vorstellen, dass es halt hilfreich ist, zu realisieren, dass da halt irgendwie diese Person ist.
die hat in diesem Bereich super detailliert unterwegs ist und alle Details versteht.
Und ich muss das halt, glaube ich, nicht alles, also ich muss das vielleicht erst mal nicht verstehen, aber ich weiß dann zumindest, dass diese Person halt da ist, die es dann halt irgendwie super detailliert dargestellt hat.
Und ich habe irgendwie eine andere Person, die halt irgendwie einen Überblick hat und dadurch kann ich das einordnen und kann halt versuchen, dort einen Dialogentgange zu setzen.
Aber ich finde, die verschiedenen Flughöhen können durchaus nebeneinander laufen und müssen nicht vereint werden.
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 die nächsten Kommentar auch ganz gut im Chat.
So manchmal denken, werden auch Unbekannte aufgedeckt.
Diese Flughöhen können auch ein Hinweis sein, dass es Lücken gibt und dass es hier Probleme in der Anknüpfung gibt.
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 bezogen hast, von Astrid Sabatsky.
Und zwar sagt sie, manchmal decken diese am Thema vorbei, in Anführungsstrichen Gespräche, auch ein Problem, auf das sie 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 ja 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 Enforce-Timeline?
Sonst würde ich mal wieder sozusagen auf das Miro-Board gehen.
Gehen wir rüber, wir können später noch ein bisschen was über Storing erzählen.
Genau, und zwar, wenn man sich das jetzt irgendwie anguckt, dann sieht man hier halt, dass das irgendwie strukturiert ist.
Also hier sind eben diese Post-its.
Wir haben...
Ich zeige das jetzt mal, weil ich mir sonst halt sozusagen 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 halt irgendwie reden kann.
Und hier sieht man jetzt, dass eben so ein Event hier...
hervorgehoben ist, das ist irgendwie Bestellung eingegangen.
Hier hinten ist noch so ein Event, was ich hervorgehoben habe, durch so einen senkrechten Strich.
Das ist Lieferung an Paketdienst-Peditionen übergeben.
Also wir haben halt offensichtlich irgendeinen Bestellprozess.
Das ist immer 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 rein tun 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 tatsächlich einmal sehr fundamental geändert und deswegen ist es eben ein, würde ich behaupten, Pivotal Event.
Da gibt es eine ganze Menge Heuristiken.
um solche Pivotal Events zu identifizieren, was halt wiederum bedeutet, dass das nicht so super, 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 würden wir jetzt versuchen zu identifizieren.
Also so eine Charakteristik von so einem Pivotal Event, du hast gerade gesagt, danach ist die Welt eine andere.
Also 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 also auch eine ganz wichtige Sache.
Vorhin habe ich also die Frage aufgeworfen, was hat denn das eigentlich mit Software oder Software Design zu tun?
Und hier kann man schon erahnen, also 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.
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 einen 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 halt eben heben können.
Ich glaube, eine spannende Heuristik, auch wie findet man bivituelle 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 Business-to-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 drauf schauen könnte.
Genauso nicht, so was vielleicht Lieferungen am Paket ins Spedition übergeben.
Und danach ist die Welt halt eine andere, weil ich jetzt irgendwie nicht mehr sagen kann, also weil 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 halt vielleicht dort genauso eine Übergabe.
Genau, und 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 halt sagt, okay, ich schicke halt eine Rechnung raus.
und kümmere mich halt um die Bezahlung.
Das nehme ich halt an, ist eine Swimlane und ich habe halt die andere Swimlane, die halt 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 ja idealerweise will, dass halt 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 Swimlands 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 Pivotal Event?
Das ist eben, 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 halt 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...
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 Swimlains 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 da sind ganz unterschiedliche Reihenfolgen.
Ich habe noch eine, genau, damit haben wir das, glaube ich, so im Groben durchdiskutiert, wie so ein, mindestens Design-Level-Event-Storming aussehen kann.
Ich habe eine Anmerkung, frage wir auch immer, auch von dem MD42 Martin bei YouTube.
Hybrid-Setup ist bestimmt auch eine Herausforderung.
Was ist mit Hybrid gemeint?
Also Hybrid klingt für mich, ich habe sowohl als auch.
Also das würde ich komplett vermeiden.
Ja, ich nehme an Menschen, die über dieses Internet miteinander kollaborieren und Menschen, die vor Ort sind.
Also das würde ich gar nicht machen.
Also Leute im Raum haben und welche dann, die halt 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.
Also ich glaube, die klassische Entscheidung ist, schaffen wir das halt irgendwie, alle Leute in einen Raum zu kriegen.
Klar, Eventstorming 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.
Also zum Beispiel kann ich Dinge halt leichter duplizieren, kann sie leichter kopieren, kann sie leichter hin und her schieben.
Also Dinge, die halt in der realen Welt nicht so einfach sind.
Auf der anderen Seite haben wir dann halt technische Hürden.
In so einem Format, wo ich mit Breakout-Räumen arbeiten muss, habe ich halt nicht diese freie Diskussion, wo sich dann irgendwie Klüngel bilden.
Drei Leute stehen physisch vor dem gleichen Ausschnitt von so einer langen Wand.
Also da haben wir jetzt gar nicht drüber gesprochen.
Ich habe einen gewissen Platzbedarf.
Also ihr seht es ja auch hinter mir.
Das sind so Artefakte von so einem Event-Storming, die übrig geblieben sind.
Ich brauche Platz, also irgendwie Wand bekleben mit Packstreifen und sowas.
Und wir stehen da halt physisch davor und reden über die Dinge, die da kleben.
Und das nachzubilden rein remote ist schwierig.
Ich habe Ansätze gesehen mit so Sachen wie Gather Town, das ist cool, da können dann Leute wirklich irgendwo beieinander stehen, man kann das nachbilden, aber es ist halt nicht das Gleiche.
Also das sind so eher, naja, schön genau, das ist so eine Inaction von so einem Board.
Also ihr seht ja, da sind sogar nochmal eine Ebene oben drüber, da ist richtig viel gemacht worden.
Es steckt halt wahnsinnig viel Potenzial da drin, dass die Leute sich miteinander spontan vor so ein paar Stickys stellen können und darüber diskutieren.
Und das irgendwie nachzubilden, remote, ist eine Herausforderung.
Heißt nicht, dass es nicht geht.
Es gibt auch mittlerweile so Patterns, die einzelne Leute beschreiben, wie man halt irgendwie mit Event-Stormings auch remote gut arbeiten kann.
Also ich kann das von mir aus sagen, ich mache das am ehesten mit Teams, die schon mal zusammen ein Storming gemacht haben, die also 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 etwas wie sieben, acht Leute, die sich etwas Kleineres angucken und wo wir das viel besser steuern können.
Aber das ist Geschmackssache, also so mache ich das hier.
Das kann man sicherlich auch ganz anders tun.
Ich würde auch denken, es gibt da halt Vor- und Nachteile.
Was ich an den digitalen Formaten gut finde, ist, dass es automatisch archiviert ist.
Ich kann es wieder rausholen.
Ich kann später daran noch mal arbeiten.
Aber da werden ja schon diskutiert, dass die Artefakte vielleicht nicht so das Zentrale sind.
Ich würde bei einem hybriden Setup versuchen, so wie du ja auch gesagt hast, diese informellen Möglichkeiten zum Austausch zu erzeugen.
Die Diskussionen über das Mittagessen sind nicht möglich.
Also müssen wir irgendetwas machen.
um halt diese Sachen halt irgendwie rauszukitzeln und halt irgendwie auf die Reihe zu bekommen.
Also eben nochmal fragen, was ist euch irgendwie aufgefallen?
Gibt es Dinge, die ihr diskutieren wollt?
Möglichkeiten bieten, diese Sachen halt irgendwie nachzuempfinden, um halt zu versuchen, 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 halt andere Trade-offs hat.
Wenn ich eine verteilte Organisation habe und die Menschen halt irgendwie über verschiedene Standorte verteilt sind, bedeutet das, die müssen halt irgendwie reisen.
Dann bedeutet das, ich muss halt innerhalb von ein oder zwei Tagen komprimiert das halt irgendwie alles machen.
Dann bin ich mir durchaus unsicher, ob es nicht schlauer ist, das halt weniger komprimiert zu machen und dafür irgendwie virtuell muss man sich halt irgendwie die Karten legen.
Aber hybrid, also halte ich auch für, würde ich halt auf keinen Fall machen.
Wegen dieser Kommunikationsasymmetrie.
Also die Menschen, die halt vor Ort sind, werden halt besser miteinander kommunizieren als der Rest.
Und das ist, glaube ich, tödlich.
Also 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 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 dieses 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 Cross-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.
Achso, und es gibt dann irgendwie noch das, also man kann es noch weiter ausdifferenzieren, man kann also jetzt irgendwie auch noch anfangen und kann da runtergehen auf Aggregates.
versuchen halt irgendwie Command-Sort 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 halt irgendwie interessant, dieser, zumindest aus einer Software-Architektur-Perspektive, dieser Bereich, der halt irgendwie eingegrenzt wird von so Pivotal Events und von Swimlanes, ist halt auf jeden Fall verhältnismäßig unabhängig von anderen, weil er ja parallel ist zu Dingen, die halt parallel arbeiten, weil sich durch den Pivotal Event ja die Welt sehr stark geändert hat.
Das heißt, wenn wir dieses Ding nehmen und das halt als Modul unserer Software identifizieren, sind die Chancen relativ gut, dass das eben ein praktisch unabhängiges Teil unserer Software ist und das ist so ein bisschen die Softwarearchitekturperspektive.
Man muss trotzdem nochmal darüber nachdenken, ob das, also man kann es nicht einfach rauskopieren und halt sagen, das ist es jetzt.
Ein Standardbeispiel ist halt, wenn ich jetzt irgendwie Retouren habe, ist halt die Frage, ob halt das Versenden von Retouren so ähnlich ist, wie das Wegschicken aus meinem Lager, sodass ich das irgendwie mit demselben Modul erledigen will.
Weiß ich nicht genau und ich bin halt auch zum Beispiel nicht sicher, ob ich halt dieses da hinten mit die Lieferung hat, irgendwie das Lager verlassen, ob ich da tatsächlich irgendwie ein neues Modell brauche, um das halt irgendwie abzudecken oder ob ich halt damit hinreiche, das Modell zu benutzen, was ich für den Teil davor hatte.
Hier ist eine Frage.
Also ich weiß nicht, ob ihr da ergänzen wolltet, sonst würde ich zu der Frage übergehen.
Ich wollte eigentlich nur noch einen Satz dazu sagen, was du vorher noch angesprochen hattest, also mit den anderen Farben.
Bei dem minimalen Beispiel sieht man, da sind 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.
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.
Und das dann weiter in eine Richtung zu treiben, wo wir dann zum Beispiel einen Prozess oder eben ein Software-System mit...
mitgestalten können.
Das ist halt eben auch eine Option und das ist, glaube ich, die, die die Leute am meisten vor dem Auge haben, wenn sie Eventstorming hören.
Deswegen sei einfach mal gesagt, es kann auch ganz, 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 halt eben Bereiche haben.
Dann können wir, glaube ich, zu der Frage kommen.
Genau, also die Frage kommt von TheNameless555666 bei YouTube und er oder sie sagt, als Fan von Eventstorming, wie überzeuge ich meine Führungsebene, das Zeit und gegebenenfalls auch Geld für vor Ort zu investieren, um Eventstorming möglich zu machen.
Und die Ergänzung ist dann natürlich die Kunden, dass das sinnvoll investizierte Zeitbudget aus ihrem Topf ist.
Daniel, ich habe so viel geredet.
Sag doch du auch mal was dazu.
Ich kann ja gar nicht was zu ergänzen, aber fang da du mal an.
Also ich finde das eine ganz schöne Frage.
Ich kenne die Herausforderung und ich versuche immer mit einem Beispiel bei sowas anzufangen.
Also 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, mit 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 denn du ergänzen?
Was ist denn so dein Magic?
Wie würdest du das angehen?
Das ist so 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 halt jetzt nochmal 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, halt mal 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 halt überzeugend ist, ich finde eure Wege da sehr gut, aber die eine Sache, die mir dabei auffällt, ist, Wir reden über ein Projekt, was halt Monate oder Jahre oder so dauert.
Also wir reden ja über ein komplexes Setup.
Und da irgendwie ein oder zwei Tage, zwei Tage zu opfern, um mal strukturiert miteinander zu reden, ist keine signifikante Investition.
Also im Gesamtprojektbudget ist das halt verschwindend.
Man kann es kombinieren mit sowas wie einem Kick-Off.
Dann hat es nämlich auch den Vorteil, dass man dort die die Menschen sich sozusagen kennenlernen und das könnte dann sozusagen noch ein zusätzliches Bonbon sein an der Stelle.
Und damit wir, also ich werde nicht müde, das zu erzählen, ich weiß nicht, ob es halt hilft, aber das Involvement von Domänexpertinnen ist einer der zentralen Erfolgsfaktoren für Softwareprojekte und wir wissen das seit den 50er oder den 60ern.
Also ich habe eine Episode gemacht zu diesem, zu dem, Zu dem Projekt, wo es halt das erste größte Projekt, was wir als Menschheit gemacht haben in Form von Softwareentwicklung, 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 Royce Paper aus Ende der 60er, wo es halt angeblich um Wasserfall geht, darum geht es da nicht, es geht um iterative Entwicklung, sagt halt, ein wichtiger Punkt ist Kundeninvolvement.
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 eben ein Team, nämlich Aston Martin im Moment gar nicht so gut dasteht.
Und offensichtlich haben die zu wenig mit ihren Fahrern geredet und haben die Autos an den Fahrern irgendwie vorbei entwickelt.
So jedenfalls das YouTube-Shop, was ich gestern gehört habe.
Was halt irgendwie bedeutet, dass halt auch in so super technischen Bereichen, wo man es halt gar nicht denkt.
nicht miteinander reden und halt auf Kunden hören vielleicht wichtig ist.
Und 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 ist, 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 uns ja das Event-Storming macht, das Visuelle, das sehen können.
Also etwas zu sehen, das funktioniert im Hirn auch ganz anders, wenn man sich das ein bisschen damit beschäftigt.
Diese Validierung über sehen und diese Simulation, die da passiert, die macht einfach ganz was 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 Eventstorming 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 Riesenvorteil und auch das ist 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 lass das das Ding sein, was die Lawine ins Rollen bringt.
Ja, super hinweis.
Wir können auch mal kurz in den Chat gucken.
Also Pilosaurus bei Twitch hat gesagt, wir hatten wiederholt Probleme in einem Themenbereich, Bugs, überzogene Tickets.
Das habe ich zum Anlass für ein Mini-Event-Storming, Domain-Modeling genommen.
Passt ja genau in das, was wir schon diskutiert hatten, also was du insbesondere darum gesagt hast.
Dann hat MD42 Martin geschrieben, eine Idee kann auch sein, Tech-Leads auf die Pro-Event-Storming-Seite zu bekommen, zum Beispiel Stickies.
Und die Perfect-Events können ein Hinweis auf einbauende Kontext sein.
Ja, also nicht, das kann der Einstieg in Design sein.
Und Astrid hat geschrieben, viele Benutzer verstehen beim Event-Storming erst, wie komplex auch ein einfacher ständiges Problem wird.
wenn man es so genau definieren muss, wie es zur Programmierung notwendig ist.
Viele Programmierer 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 TheNameDes schreibt noch, danke für die Antworten, werde auch nochmal versuchen, die Kurve zum Programmieren als Modellbildung versuchen in meiner Argumentation.
Genau, dazu gibt es auch eine Episode zu der Theoriebildung, die ich halt vor einiger Zeit geführt habe.
Wie fange ich denn an damit?
Wie startet man?
Prinzipiell sind die Voraussetzungen natürlich super.
Also Eventstormings 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...
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 jetzt 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 Szenen 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 Orangefarben, Stickies, ich greife das direkt auf.
Das ist tatsächlich...
Das ist ein Problem und es gibt, 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, ausreinend orange Problem des 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 Eventstormings mit, dann muss man sich da weniger Gedanken machen und da sind dann halt eben genug davon drin.
Wir haben dafür einen Deal mit 3M gemacht.
Also 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 halt übrig hatte, dann muss man sich halt klar sein, okay, die müssen halt nicht orange sein.
Heute in der Session sind sie halt mal blassblau.
Weil das sind halt die, die wir halt immer übrig hatten von was anderem oder sowas.
Das geht natürlich auch.
Also ich finde es gut und richtig, dass du halt auf das Buch hinweisst und darauf, also es gibt ja auch Sachen, die man halt im Internet finden kann.
Und die nur, wie soll ich sagen, wir hatten vorhin schon diskutiert über dieses Programmierung als Theoriebildung.
Und eins von den Dingen, die halt nauer hat in dem Paper diskutiert ist, dass er der Meinung ist, dass man Softwareentwicklung, Programmierung eigentlich nur so lernen kann, wie man halt ein Instrument lernt, indem man halt tatsächlich gemeinsam sich das halt erarbeitet.
Und ich glaube, es ist halt relativ klar, dass man von niemandem erwarten würde, der jetzt irgendein Instrument spielen soll, dass die Person das halt einfach tut, indem man ein Buch liest.
Und Nauer diskutiert das halt irgendwie über Programmierung.
Da kann man jetzt irgendwie länger drüber diskutieren.
Und hier ist es, glaube ich, 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 halt zu machen, weswegen da eigentlich so ein bisschen die externe Hilfe und ich glaube, deswegen setzt man ja auch hier eine Rolle spielt.
Ich glaube, je weiter man sich in der Organisation bewegt, je mehr Menschen man mit hineinnimmt.
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.
Und ich glaube, genau solche Situationen zu üben ist das A und O, um...
um da auch sicher auftreten zu können und auch eine diverse Gruppe auch gut anleiten zu können.
Und ich glaube, das ist auch noch ein wichtiger Punkt.
Das gilt, glaube ich, auch so für Moderation und so für Meetings im Allgemeinen.
Vorbereitung ist ein wichtiger Punkt.
Die Methodik selber ist gar nicht so sehr das Thema vielleicht, beziehungsweise anders gesagt, wenn man sozusagen in einem Meeting ist und jetzt irgendwie anfängt, das erste Sticky zu malen.
ist der größte Teil der Arbeit eigentlich schon getan.
Das Problem ist halt irgendwie davor, das halt auf die Reihe zu bekommen, dass eben die Umgebung entsprechend gesetzt ist.
Der Marco hat noch geschrieben, der übliche Struggle zwischen einer Standardlegende für weniger Man to Load versus Farbenverfügbarkeit und pragmatischer Legende, if I had a penny for every time, also schlägt sich da halt auch auf die Seite von, würde ich jetzt mal sagen, von den Menschen, die halt etwas flexibler sind.
Man hat im Weiteren noch geschrieben, Üben ist wichtig, machen ist wichtiger, lieber starten und lernen, was klappt, also versuchen, das Wissen zu perfektionieren, bevor man sich darauf zu facilitäten.
Man könnte es halt nicht in einem Safe Space sozusagen selber erstmal ausprobieren, das ist sicherlich eine gute Idee.
Ansonsten stehen wir auch zur Verfügung und diskutieren da gerne mit euch.
Ich packe sozusagen, also es gibt von uns eine Kontaktmöglichkeit über das Internet beziehungsweise sich da irgendwie Zeit zu buchen oder eine Anfrage zu stellen.
Das wäre die eine Möglichkeit.
Und das andere, was wir ja gemacht haben oder was wir tun, ist eben, wir haben ein Training dafür.
Einmal bei Sokreatori zu diesem Thema und dann Zum anderen auch bei dir, Daniel, bei Tech Talk.
Ich zeige erst mal kurz noch den Hinweis auf den Betonien-Caffee beziehungsweise auf die Möglichkeit, einen Termin mit Tom sich zu buchen.
Und dann gibt es eben die Möglichkeit, ein Training zu machen bei Sokretori.
Da gibt es bis zum 4.10.
auch 20% Rabatt für.
Und analog hast du, Daniel, da auch ein Training.
Und wir haben die Unterlagen halt alle gemeinsam erstellt.
Das heißt, das ist sozusagen inhaltlich sehr stark überschneidend, fast identisch.
Also es hängt ja immer davon an, wer sozusagen die Trainerin ist.
Und das wären halt Möglichkeiten, da sozusagen zu starten an der Stelle.
Vielleicht noch wichtig zu erwähnen dazu, also die Trainings, da geht es nicht nur um das Eventstorming.
Also wir haben ein größeres Feld, wir sagen kollaborative Modellierung ist wertvoll, ist sinnvoll und ist halt eben mehr als nur die Praktik oder die Methode.
Also erstmal sprechen wir über mehr Methoden als nur das Eventstorming, aber vor allem über die Erfolgsfaktoren.
Also 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?
Also vielleicht genau die Sachen, die man nicht so über Buchwissen rausbekommt und die man, du hast es gerade so schön genannt, im Safe Space einfach mal ausprobieren kann.
Das war so ein Ding, was wir bei dem Training halt in den Fokus mit reingerückt haben.
Halt eben 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.
Und das ist das, was halt eben oftmals zu kurz kommt.
Das kann man in dem Training, glaube ich, wunderschön vermitteln.
Und da würden wir uns freuen, wenn wir viele von euch da drin begrüßen dürfen.
Ich habe das damals als erstes mit einer Freundin ausprobiert, dann mit einer Freundesgruppe, dann erst im Profiraum.
Das finde ich auch einen interessanten und spannenden Hinweis.
Das ist übrigens auch so ein Grundsatz, den ich irgendwie habe, wenn ich halt irgendwas erstelle, eine Übung oder so, versuche ich die erstmal selber zu machen.
Weil man dann irgendwie nochmal merkt, was halt so an Schwierigkeiten ist.
Und Markus schreibt halt, dass er versucht, dem Drang zu widerstehen, seine eigenen Links zu seinen eigenen Trainings hier hinzuschreiben.
Dann Jason Thelron schreibt, Tipps für Toolings, wie die Ergebnisse zu persistieren, damit man das gemeinsame Verständnis nachschlagen kann.
Wie macht ihr das?
Da hat vielleicht jeder so ein paar andere Ansätze.
Also ich mache das ganz klassisch.
Ich fotografiere Sachen am Ende und je nachdem, was da auch vorher besprochen wurde, wird es dann nochmal in eine andere Form überführt oder es bleibt bei den Fotos.
Also das Spannende sind halt eben auch die Diskussionen, die da halt eben mit rauskommen oder halt das, was man da raus exzerpt.
Aber ja, vielleicht habt ihr noch andere Ansätze dazu.
Ich warte ja darauf, dass jemand irgendwie so eine tolle AI-Cam macht, die einem das alles schön auf Miro-Board digitalisiert.
Also Daniel.
Also mit der AI-Camp bin ich noch nicht dabei, aber auch das, also in meinem Kopf schwebt das drinnen, dass wir so den virtuellen Stick hier 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 Artefakte 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 ein oder andere AI-Recording mitzumachen, um auch den Diskussionskontext aufzuheben, um danach wieder abfragen zu können.
Das ist aber sehr herausfordernd, weil es natürlich in Unternehmen nicht immer möglich ist, da auf diese Technologien zurückzugreifen.
Aber das ist auch ein Thema, wo man, glaube ich, auch mit den neuen modernen AI-Themen was machen kann.
Genau, Marco schreibt gerade, Cloud Code mit Miro MCP ist enorm gut darin, wird es good to explain colors in Zeitstrahl.
Also meine Antwort wäre halt, ein bestimmtes Ergebnis ist ja Persistenz.
Also in dem Sinne, dass wenn ich halt ein Miro-Bot zum Beispiel habe, ist das Miro-Bot halt persistent und da kann ich halt wieder hingehen.
Man kann Fotos machen, wie ihr schon sagtet.
Und ich muss gestehen, dass ich...
Also ich habe immer noch diesen Gedanken mit, ist das Artefakt eigentlich das Relevante?
Und ich finde, die Tätigkeit, das nochmal aufzuschreiben, zusammenzufassen in irgendeiner anderen Form, ist etwas, was, also zu persistieren, ist meiner Ansicht nach nicht purer Overhead, weil man es dabei sozusagen nochmal durchdenkt.
Und ich bin nicht sicher, ob...
diese Persistierung nicht nochmal die Möglichkeit tatsächlich bietet, die Chance bietet, sich das nochmal sozusagen zu vergegenwärtigen, wenn man das denn tatsächlich will.
Und wenn man die Ergebnisse nicht persistiert, hat man trotzdem im Ergebnis eben den Austausch.
Und das ist ja nur der erste Schritt.
Also das Artefakt, was wir, vielleicht ist das so ein bisschen der Punkt, das Artefakt, was wir eigentlich erzeugen wollen, ist halt ein System, das bestimmte Features hat.
Also noch nicht mal Code.
Wir wollen eigentlich ein System haben, das halt irgendetwas tut.
Wenn wir das ohne Code machen könnten, wäre das halt irgendwie gut.
Alles, was wir da vortun, ist nur eine Vorbereitung da drauf.
Und deswegen ist für mich eher die Frage, ob man halt das gemeinsame Wissen und das gemeinsame Verständnis hat, in einer Form, die halt nützlich und notwendig ist.
Und nicht so sehr, ob man jetzt das Artefakt kreieren kann.
Und das wäre halt das, was ich da mitgeben würde.
Und wenn man halt das gemeinsame Verständnis hat, kann man halt...
verbessern dadurch, dass man Dinge selber tatsächlich nochmal zusammenfasst oder zusammenschreibt möglicherweise.
Gut, da ist auf jeden Fall was drin.
Also das ist ja nicht nur das Persistieren des Artefakts aus dem Workshop, sondern eigentlich schon das Prozessieren von dem, was da rauskam.
Und manchmal ist das halt eben die Folgeaktivität.
Also an einem Tag macht man das Eventstorming und am nächsten Vormittag trifft man sich und arbeitet mit den Ergebnissen.
Das ist so eine Möglichkeit, wie so ein Workshop aufgebaut sein kann.
Und ja, das ist müßig, ob das jetzt das Artefakt selber ist oder ob das schon die Folgetätigkeit ist.
Am Ende kommt ein besseres Verständnis raus und das ist eigentlich das, wo wir hinwollen.
Gut.
Noch Dinge, die wir sozusagen besprechen müssen, sollen, wie auch immer, irgendwelche Sachen ich 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 so einen kompakten Überblick über, was ist denn das eigentlich, ist es hilfreich und Getting Started, haben wir gegeben.
Genau.
Ja, dann würde ich sagen, vielen Dank für die Aufmerksamkeit.
Vielen Dank, dass ihr dabei wart.
Und vielleicht sehen wir uns dann halt im Rahmen von einer Beratung oder von einem Training in diesem Bereich.
Und der Ausblick ist, dass wir Freitag, denke ich, ein Video live nehmen werden, aber keinen Livestream haben werden.
Ich müsste jetzt, ich gucke tatsächlich mal kurz selber auf den Plan.
Ich meine, das Nächste, was wir geplant haben, ist im Moment, Genau, das Ende August.
Aber da passiert vielleicht zwischenzeitlich auch irgendwie nochmal was.
Achso, hier ist noch ein inhaltlicher Hinweis, dass von der Astrid Persistieren mache ich möglichst im Pair mit einer weiteren Teilnahme.
Das finde ich auch eine gute Idee.
Gut.
Dann würde ich sagen, vielen Dank nochmal.
Und schon, ja, das Wochenende fast.
Dafür ist es etwas früh.
Genau, bis dahin und viel Erfolg mit Eventstorming.
Ein Hinweis in eigener Sache.
Eventstorming 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.
27.
bis 29.
Oktober in der Therme Erding mit Eberhard Wolf und Tom Asel.
23.
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.