„Oma, erzähl mal von früher“ – In wem steckt dieses Kind nicht noch, das gern Geschichten aus Sicht von jemandem hört, der mit dabei war? Jemand, dem man glaubt, dass er oder sie Ahnung hat von dem Erzählten. Eine Person mit Expertise halt, die durch genügend Erfahrung auch frei erzählen kann. Und die von 100 Nachfragen nach Details eher erfreut als genervt ist und gern auch bei offenen Fragen wiederholt. Keine Oma zur Hand? Eine Person mit Domain-Expertise oder eine Gruppe davon tut es auch.
Das Schönste an der ganzen Sache ist für Leute wie mich, dass es kaum feste Regeln oder Vorbereitungen gibt.
Was braucht man fürs “Domain Storytelling”?
Als „Ausstattung“ braucht man grundsätzlich:
- ein Blatt Papier samt Malwerkzeug (naja, vielleicht auch ein Whiteboard, Miro, egon.io oder Ähnliches),
- neugierige Architekt*innen oder Entwickler*innen
- und mindestens eine Oma. Oder wie bereits erwähnt alternativ eine oder einen Domänen–Experten oder -Expertin.
Und schon stellt sich die erste Frage: Was ist eine Domäne? An dieser Stelle weiche ich aus und hoffe, dass meine Kolleg*innen bald einen Blogpost zu diesem Thema verfassen. Für das Domain Storytelling ist die Domäne einfach das Thema oder der Arbeitsbereich der Erzählenden, den man gern umfassend verstehen will.
Was braucht man noch? Domain Driven Design? Das ist definitiv keine Voraussetzung für diese Methode. Man kann damit wunderbar die Fachlichkeit und die Anforderungen unabhängig vom Lösungsdesign einer Anwendung erforschen.
Eine Kurzeinführung in die Notation sollte auch nicht fehlen.
Also Oma erzählt und der oder die interessierten Zuhörer*innen schreiben “visuell” mit, nach dem Schema: Wer (Akteur) macht was (Aktivität) womit (Arbeits-Objekt) – optional noch mit wem (andere Akteure), Kommentare inklusive. Akteure können dabei Personen, Gruppen und Softwaresysteme sein.
Bevor es nun wirklich losgeht, gibt es eine Handvoll Punkte beziehungsweise Fragen, die ich mir gern ins Gedächtnis rufe.
Frontbeschallung?
Definitiv nein. Für das „Geschichten erzählen“ sind aktives Zuhören, Aufmalen und Rephrasing Teil der Geschichte. Schließlich geht es nicht um pure Unterhaltung, sondern „verstehendes Hören“.
Flow
Auch wenn der oder die Erzähler*in gerade voll im Fluss ist, die Geschichte geht erst weiter, wenn das Gemalte von allen abgenickt und verstanden ist. Offene Details, die gerade nicht für den Hauptstrang der Geschichte relevant sind, können gern temporär ungeklärt bleiben. – Wozu gibt es Sticky Notes? 😉
Fragen == evil?
Definitiv nicht – sondern ein Muss beim Storytelling! Fragen bedeuten Interesse und „Hinterfragen“ und dürfen nicht als „Infragestellen“ bewertet werden. Verwerten und nicht Bewerten ist die Devise. Wer keine Fragen hat, ist entweder auch schon Experte*in oder hält sich nur dafür.
Anfang und Ende der Geschichte
Grenzt den Rahmen der Geschichte vorab etwas ab. In einer gänzlich neuen Domäne für einen Teil der Teilnehmenden (natürlich nicht für die Erzählenden) kann das auch spätestens während der Erzählung passieren – einvernehmlich im Team.
Abschweifen
Das ist durchaus erlaubt und führt manchmal zu überraschenden Erkenntnissen. Es ist auch nicht so einfach, eine Flughöhe beizubehalten und sich nicht zu sehr in Details zu verstricken.
Beim Storytelling kann man sich auch als Notekeeper im Tool oder in der Notation verlieren – dann heißt es: pragmatische Ansätze und zurück zur Fachlichkeit. Dabei dürfen sowohl Erzähler*in als auch Zuhörende freundlich die Notbremse ziehen.
Leider ist uns das auch schon passiert – aber jeder Fehler ist ja bekanntlich eine Erfahrungslücke und kein Problem.
Handwerkszeug? Schon, und Handwerk will gelernt sein.
Wie man eine Domain Story bildlich und textlich fest hält, ist auf vielen Seiten beschrieben. Nichtsdestotrotz gilt auch hier: „Tailor your method“. Wir haben im Team verschiedene – zum Teil auch entgegensetzte – Erfahrungen gemacht. Und wie im Handwerk üblich, taugt das beste Werkzeug nur für den richtigen Zweck.
Und wie viele Handwerker*innen sind optimal? Ich meine, alles zwischen zwei bis maximal sechs Teilnehmende ist ok, jedoch schätze ich hier: Weniger ist mehr (effektiver).
Stichwort Werkzeug: Wir arbeiten gern mit egon.io – vor allem um die Story hinterher nochmal „abzuspielen“. Vor dem Einsatz sollte man jedoch schon mal die Zeichenkiste mit den richtigen Icons bestücken. Und ein Nachteil ärgert uns als Team, das gern gemeinsam modelliert: Es gibt leider bisher keine Möglichkeit kollaborativ zu arbeiten.
Hilfe, ich male ein Spinnennetz!
Wenn die Geschichte doch etwas länger dauert und viele Aktionen von einer Akteur*in ausgehen oder eingehen, dann sieht die Story aus wie ein Spinnennetz. Alternativ haben wir auch erprobt, die Aktionen von links nach rechts oder von oben nach unten immer neu anzusetzen oder auch mal nach maximal drei Aktionen zu splitten.
Der richtige Ansatz hängt nach meiner Erfahrung davon ab, was im Fokus stehen sollte und wie viele Akteure und Akteurinnen beteiligt sind. Ich wähle am liebsten kleine Netze untereinander – möglichst schon ein klein wenig fachlich getrennt.
Eine neue Akteur*in oder ein Medienbruch bietet sich gern als Trenner an.
Hauptpfad und Nebenstrecken?
Das ist ein Fallstrick, in den ich mehrmals gelaufen bin, selbst als mir die Theorie dazu bewusst war und ich mit einem Kollegen genau darüber schon diskutiert hatte. Man erzählt und modelliert immer (erstmal) eine Version der Geschichte, so wie Oma auch. Im Normalfall ist das der „happy path“, außer man will eben genau einen anderen Fall verstehen.
Das ist einfacher gesagt als getan und manchmal darf man auch schummeln – zum Beispiel mit einem Bild daneben. Als „Techi“ denkt man eben doch ziemlich oft in alternativen Abläufen.
Es war einmal? Gegenwart oder Zukunft?
Fallstrick Nummer zwei – zumindest, wenn man vergisst, diese Frage vorab zu klären: Erzählt und modelliert man den IST-Zustand oder Ideal-Abläufe für die Zukunft? Typische Architektenantwort: „It depends“ – aber immer nur eins von beiden in einer Story. Allerdings finde ich es wesentlich passender, einen IST-Zustand damit zu modellieren. Für ein Design einer möglichen Ziel-Lösung ist die Methode nicht immer passend, außer die erzählende Person hat eine genaue Wunschvorstellung. Dann lassen sich mit dieser Methode auch Hintergründe und Details einfach erfragen.
Beim IST-Zustand ist es dabei nicht immer einfach, die Interaktion von oder mit Softwaresystem-Akteuren mit der richtigen Flughöhe zu versehen. Was hier “richtig” bedeutet, kann von “Feld X in der Formular-Seite Y” bis hin zu “System X” reichen.
Wissenstransfer oder Dokumentation?
Oder liegt die Wahrheit irgendwo dazwischen? – Möglichst jedoch mit Tonspur eines Teilnehmenden. Und nicht für lange Zeit. Eine neue Story soll umgesetzt werden? Dann darf ein zugehöriges Domain – Story – Bild gern angehängt werden.
Be an expert
Jeder Koch und jede Köchin sollte einmal die eigenen Gerichte essen. Warum also nicht selbst als Experte oder Expertin agieren?
Wir haben das Ganze im Team beim Onboarding eines neuen Teammitglieds erprobt und das Ergebnis auch für zukünftige neue Kollegen*innen festgehalten. Die Domäne? In diesem Fall: der generelle Weg vom Requirement durch unseren Product Owner bis zum Go-Live eines neuen Features in unserem Projekt.
Während des Erzählens haben wir die Geschichte dann doch nach dem ersten Kapitel beendet und einen zweiten Geschichtenkreis einberufen. Allerdings waren wir mit sieben Experten und Expertinnen und zwei „Neuen“ beim zweiten Kapitel definitiv nicht optimal aufgestellt. Erschwerend kam hinzu, dass wir vormittags bereits zwei Stunden Architekturdiskussion hinter uns hatten. Damit gestalteten sich das Erzählen und auch das Zuhören echt zäh.
Mein Fazit: Domain Storytelling ist ein weiteres Tool, um Bilder UND Worte sprechen zu lassen. Wenn man jedoch auf relativ hoher Flughöhe unterwegs ist und das Glück hat, mehrere Domänen-Experten*innen an Board zu haben, würde ich zum Wohle der Schwarmintelligenz eher zum Event Storming greifen. Wenn man jedoch Details von jemandem erfahren will, dann nehme ich mir gern einen Teil der Event-Kette und gehe zum Domain Storytelling über, gegebenenfalls in kleinerer Runde.
An einem Team-Tag haben wir unser Backoffice als Oma eingeladen, um unser Handwerkszeug auch intern zu verbessern. Wer mag, kann Details dazu hier lesen.
