Wir trafen uns am Freitag, dem 17., mit sechs netten Leuten, alle professionelle Trainer in ihren jeweiligen Themen, und wir haben gemeinsam versucht, in einem Event Storming herauszufinden: Wie kommt ein professioneller Trainer von einer Trainingsidee bis zum fertigen Trainingskonzept?

Dabei fanden wir heraus, dass Event Storming nicht immer die beste Methode ist, um eine Domäne zu erforschen.

Dies ist das leicht editierte Transkript meines folgenden "Erzählvideos". (Ich habe beim Transkribieren die Sätze ein wenig auf Verständlichkeit getrimmt, Zwischen-Überschriften und Zeitmarken eingefügt):

Das "Erzähl-Video", das nach dem Event Storming entstand

Video-Transkript

[00:19] Wir haben uns auf einen Zeitslot von drei Stunden getroffen, jeweils eine Stunde 20 haben wir mit Arbeiten verbracht, dann eine Kaffeepause, dann noch einmal eine Stunde 20 – so ungefähr war der Zeitrahmen.

Hier seht Ihr unser Event Storming Überblicks-Board, da seht Ihr, wie viel wir da in der kurzen Zeit geleistet haben:

Hintergrund

Wir fingen an, haben uns alle gegenseitig ein bisschen vorgestellt, dann haben wir festgestellt, dass wir aus sehr unterschiedlichen Kontexten kommen:

  • Einige von uns geben öffentliche Trainings, einige von uns geben Inhouse-Trainings (wobei man ja "Inhouse" heutzutage in Corona-Zeiten nicht mehr so richtig behaupten kann – auch die finden häufig remote statt). Mit Inhouse meinten wir dann eben Trainings, bei denen nur Leute von einer Firma kommen, die speziell im Auftrag eines Kunden gemacht werden.
  • Dann gibt es Leute, die machen akkreditierte Trainings, das bedeutet:  Der Lehrplan wird von einer Organisation (wie zum Beispiel dem iSAQB) herausgegeben und steht schon vor dem Training fest.
  • Und: Einige Leute machen Workshops, das sind eher Trainings, die sich an einer groben Agenda orientieren, aber kurz vor dem Training noch zwischen Teilnehmern und Trainer ausgemacht werden. Auch die Zeit über während das Trainings stattfindet, kann nicht unbedingt einer festen Agenda, sondern eher einem gemeinsamen Arbeiten entsprechen.

Öffentliche Trainings, Inhouse-Trainings, akkreditierte oder nicht akkreditierte, Workshops oder eben feststehende Schulungen: Das waren unsere Kontexte, aus denen wir kommen. Manche von uns machen mehr als eins von diesen.

Erste Brainstorming-Runde

[02:24] In der ersten Brainstorming-Runde haben wir viele wichtige Events (Ereignisse) gesammelt, die von einer entstandenen Trainingsidee oder einem festgestellten Kundenbedürfnis bis hin zu einem Schluss-Event reichen, wie "erstes Training durchgeführt" und "Feedback eingeholt", "Training eventuell revidiert", "Agenda mit Teilnehmern nochmals neu verhandelt" und so weiter.

Das Trainingskonzept für's erste echte Training ist abgeschlossen. An dem Tag interessierte uns also der Bereich zwischen der Idee und dem Konzeptabschluss.

Wir haben alle möglichen Events gesammelt, wir haben auch Systeme gesammelt (die rosa oder pink Tickets). Das sind Systeme, mit denen gearbeitet wird, wobei beim Event Storming ein System nicht unbedingt nur Software oder Hardware ist, sondern vielleicht auch eine andere Organisation oder eine Gruppe von Menschen.

Diese Magenta Tickets hier, die deuten Probleme oder Schmerzen an, also zum Beispiel: Hier bei diesem Event hängt ein Zettel daneben, der sagt, das ist aber viel Arbeit, was da stattfindet, oder hier zum Beispiel das Thema nervige technische Infrastruktur tauchte auch öfters auf. Gerade bei Trainings, die mit Software zu tun haben, muss man im Vorfeld einiges an Infrastruktur aufbauen.

Identifizieren der "pivotal events"

[04:20] O.k. ... Events haben wir gesammelt, dann haben wir uns gefragt: Was wären denn die Events, die einen entscheidenden Charakter haben? In der Methodik heißen sie "pivotal events", also die, die so ein bisschen Schwung in die sache bringen.

Also zum Beispiel fangen wir einmal hier vorne an: Es wäre doch schon mal toll, wenn man die Stakeholder für das Training identifiziert hätte. Man kommt auch ganz gut weiter, wenn man das Thema mal endlich eingegrenzt hat. Dann wäre es doch nicht schlecht, wenn man mal die Menge der Unterthemen definiert hätte, die alle in dem Hauptthema stecken, so dass man eine vorstellung davon bekommt, wie viel nun eigentlich in dem Training stecken muss.

Hier passiert plötzlich sehr viel ... und das endet mit "Folien erstellt" (Folien steht jetzt hier eher in Anführungszeichen, weil ... es handelt sich bei den Trainingsunterlagen natürlich nicht nur um Folien, sondern auch um Übungen und Beispielcode, Wallpaper, um Quizzes und alles Mögliche). Die Folien standen für uns eher als Sinnbild für "Der Ablauf des Trainings steht fest". Die Folien würden ja den den Ablauf auch sehr beeinflussen. Also "Folien erstellt" wäre wiederum so ein entscheidendes Event.

Dann hätten wir hier "Erstes Training durchgeführt". Das wäre ja auch etwas, das Schwung in die Sache bringt. Wir haben ziemlich gelacht, als wir feststellten: Trainings werden ja eigentlich niemals fertig. Irgendwo stand hier noch so ein "Fertig"-Event. Das hat man dann wieder weggelöscht, weil wir gesagt haben: "Erstes Training durchgeführt", ja, da ist es in gewissem Sinne das erste Mal "fertig", aber von da an wird es natürlich ständig revidiert. Zum Beispiel hier steht ja auch schon wieder "revidiert".

Also: Diese Events, die so einen gelben Post-It-Streifen hinter sich haben, die sorgen so für eine Art Phasenaufteilung des Prozesses. Sie bringen Schwung in den Prozess, in dem sie einen wirklichen, echten Übergang darstellen.

[06:31] Das reichte uns erst einmal als Überblick, und was mich, als Einladenden zu diesem Event Storming, natürlich besonders interessiert hat, ist genau diese Phase hier: von "Menge der Unterthemen wurde definiert" bis "Folien erstellt", das heißt: Wie wird aus einer Themen Sammlung, von der man sich relativ leicht vorstellen kann, dass man die erstellt, wie wird daraus jetzt ein konkretes Training? Was muss man dafür alles tun?

Wir hatten Ideen wie zum Beispiel...

  • inhaltlich ausarbeiten
  • Übungen müssen ausgewählt und erstellt werden
  • es muss eine Übungsinfrastruktur geschaffen werden
  • für jedes Lernziel müssen vielleicht diese "4C" von Sharon Bowman festgelegt werden (concept, connection, concrete practice und conclusion), lauter solche Dinge, die die Teilnehmer durchmachen müssen, bis sie ein Lernziel so richtig begriffen haben

Also: Allerlei interessante Dinge, die jetzt wirklich in der konkreten Ausarbeitung des Trainings stattfinden.

Eine Stufe absteigen zum Prozessmodell

[08:02] Jetzt hatte ich erwartet, dass wir von diesem Überblicks-Level einfach so rein springen könnten in einen Trainings-Design-Prozess (Anmerkung: ich meinte die Modellierung dieses Prozesses). Ich wechsele auf ein anderes Miro-Board:

Ich war da optimistisch und habe einfach diese beiden Events, die ich aus dem Überblicks-Level gewonnen hatte, nämlich

  • "Fluss durch die Themen identifiziert" (also dem Trainer ist jetzt klar, wie seine Themen zusammenhängen und wie er da einen Fluss dadurch gestalten möchte)
  • und "Menge der Unterthemen definiert"

als Input genommen. Auf der rechten Seite, als Ergebnisse, hatte ich mir vorgestellt:

  • "Trainingsmodul ist definiert", weil ... so ein training besteht ja vielleicht aus mehreren Modulen, und
  • zu jedem dieser Module gibt es eben die "didaktischen Elemente", also zum Beispiel ein Stückchen Vortrag, ein Stück Übung, ein Beispiel, etwas Code und so weiter. Was man alles an didaktischen Elementen braucht, um irgendwas zu unterrichten oder mit den Teilnehmern zusammen zu arbeiten.

All das hier zwischen existierte noch nicht (Anmerkung: gemeint ist der Bereich zwischen "Input" und "Ergebnisse").

Denkste!

[09:22] Ich dachte so, jetzt würden wir einfach von den weiteren Events ausgehen und mit Hilfe von diesen anderen Zetteln ("User", "Command" und "System") würden wir uns da hineinarbeiten.

Also: Der User wäre ja in der Regel der Trainer. Der würde irgendwelche Commands an irgendwelche Systeme geben (zum Beispiel an die Tools mit denen er arbeitet) und: Heraus kämen wieder irgendwelche Zwischen-Events.

Das passierte jetzt interessanterweise gar nicht:

Die Trainerinnen und Trainer, die teilgenommen haben, waren sich eigentlich einig, dass die Tools oder Systeme (sagen wir mal, diese rosa Zettel hier) eine untergeordnete Rolle spielen und die Hauptsache des Training-Designs (das Ganze heißt ja Trainings-Designprozess) sich ja im Kopf von Trainerin oder Trainer abspielte, während sie oder er dieses Training erarbeitet.

[10:34] Einer der Trainer sagte das so schön prägnant: "Als erstes muss ich mal irgendwie in meine Hängematte und mache ein bisschen hammock-driven design, dieses 'mal ganz in Ruhe durch den Kopf gehen lassen und frei assoziieren solange bis ich glaube, dass ich mein Unterthema irgendwie verstanden habe'". Also, das war mal sehr interessant: Dafür braucht er noch keine Tools und keine anderen Systeme, und erst dann würde er anfangen, mit Dingen wie zum Beispiel Freemind eine Mindmap zu erstellen, oder mit Roam-Tools gemäß Zettelkasten-Methode (so einen gefüllten Zettelkasten wie Meister Luhmann zu haben).

[11:17] Dann kam dieses Geschichtenerzählen ins Spiel: Eine gute Idee für Trainings ist es zum Beispiel, einmal tatsächlich eine Geschichte aufzuschreiben, in der die Teilnehmer vorkommen, um praktisch den Weg zu einer Herausforderung [zu beschreiben], die man an die Teilnehmer gibt,

  • wo sie dann eben mögliche Lösungen identifizieren müssen
  • und eine Lösung für die Schulung dann auswählen und sagen "ja, so würde ich das machen"
  • und schließlich in irgendeinem Whiteboard-Tool vielleicht ein Umsetzungsrezept aufzuschreiben

Geholfen bei dieser Denkweise haben uns (...C.G. Jung war das, glaube ich, der diese warum was wie und wohin noch Fragen gestellt hat*)

(*Anmerkung: Nach dem Transkribieren habe ich noch einmal nachgeschaut: Nein, C.G. Jung war es nicht! Es war Bernice McCarthy mit dem 4-Mat-Modell, das auf der Typenlehre von C.G. Jung aufbaut)

  • "Warum": das ist die Suche nach dem Sinn, warum unterrichtet man das? Warum ist das ein tolles Thema?
  • "Was": das ist die Frage nach ... was steckt da alles drin in diesem Thema?
  • "Wie": das ist die Frage nach ... Wie mache ich das, was sind die Handlungsanweisungen, die to-do-Listen und so weiter.
  • "Wohin noch?": Diese Frage ist dieses ... Wohin bringt uns das alles von der Vision her, wenn wir das alles meinetwegen 2-3 Jahre lang so machen?

Oder die vier C's aus Training from the Back of the Room von Sharon Bowman können uns da eben auch als Gliederungshilfen zur Seite stehen.

Der Ausweg: Event Storming verlassen

[12:46] Das bedeutet: Wir haben uns relativ schnell von der Event Storming-Methodik für diese Detailarbeit hier verabschiedet und gesagt, es schränkt uns eher ein, wir halten nur mal die zentralen Schritte fest, die die Trainerin oder der Trainer ungefähr gehen würde, um zu einer (wie soll man sagen) "unterrichtbaren Geschichte" und zu einer "unterrichtbaren Einheit" zu kommen.

Rückbetrachtung

Ja, das war ein interessantes Erlebnis! Wir sprachen in der Runde darüber: Warum hat Events Storming jetzt hier nicht so richtig seine Stärken ausspielen können? Und eine Trainerin sagte dazu, sie glaubt, dass es daran liegt, dass Event Storming für kollaborative Prozesse gemacht wurde.

Also nehmen wir an, in einem Unternehmen gibt es Einkauf, Lagerhaltung, Verkauf. Im Lager geht irgendein Artikel aus. Ein Kunde hat ihn aber bestellt, also muss der Einkauf den Artikel nachkaufen. Wenn der Artikel dann kommt, muss das Lager ihn für den Versand bereitstellen usw. Also: Kollaborative Prozesse in denen eine Menge Events eine Rolle spielen, die auch zeitlich verzögert auftreten und wo zwischendurch Zustand gehalten werden muss, also die Bestellung des Kunden zum Beispiel wechselt mehrfach den Zustand.

[14:08] All das wären jetzt Dinge, wo Event Storming so richtig schön glänzen kann, während hier, wo alles im Kopf eines Menschen passiert und viel eher die Ordnung im Vordergrund steht, die man da erst einmal reinbringen muss, da ist Event Storming vielleicht nicht die allerbeste geeignete Methode. Wie gesagt, wir haben uns dann relativ schnell davon getrennt und die orangen Zettel halten jetzt praktisch nur noch die Ereignisse im Kopf des Trainers oder der Trainerin fest.

Mögliche IT-Unterstützung

[14:39] Gut, dann gab es eine Abschlussrunde, wo wir gesagt haben: Wo könnte denn jetzt ein IT-System auch unterstützen? Wo könnte man mit einem Tool für den Trainer oder mit einer Software-as-a-service für den Trainer ansetzen und der Trainerin oder dem Trainer helfen, diesen Prozess hier zu bewältigen?

Und da kamen mögliche, Wert stiftende, Features eines Systems für Trainer als Ideen zum Vorschein.

Das eine war: Lasst uns doch irgendwas zur Verfügung stellen, was der Trainerin erlaubt, ihre Gedanken zu sortieren, also diese Hängematten-Geschichte, gefolgt von Mindmap oder Zettelkasten, irgendwas in dieser Art, dafür gibt es bloß meistens schon Systeme! Da brauchen wird nichts großartig Neues zu machen, Mindmap-Tools gibt es, Whiteboard-Tools gibt es... Da gibt es also schon für's Gedanken sortieren eine ganze Menge.

Was es dann noch nicht so wirklich zu geben scheint, ist eine Art Methoden-Toolbox. Also zum Beispiel wenn ich als Trainer sagen würde: ah, ich habe jetzt fünf Themen identifiziert, die ich unterrichten möchte, und jedes von diesen Themen möchte ich nach 4C durchgehen, also immer wieder mit concept, connection (also die Verbindung zu diesem neuen Thema), dann concrete practice (also ein paar Übungen) und dann wieder Conclusion (also eine Zusammenfassung und Debriefing). Wenn mir irgendeine Methoden-Toolbox zum Beispiel helfen würde, diese vier schritte pro Unterthema zu bewältigen und nichts dabei zu vergessen, wär das schon ein interessantes Feature für so ein Trainer System.

Auch Gliederungshilfen, wie zum Beispiel hier oben dieses Warum, Was, Wie und Wohin noch, solche einfachen kleinen Tricks, die dazu dienen nachher das gesamte Material durchzustrukturieren und in eine schöne Reihenfolge zu bringen und Gliederung zu bringen, wäre doch auch nett.

[16:48] Oder eine ganz verrückte Idee: Einer der Trainer sagte, er hat meistens mehr Material, als er nachher im Training wirklich braucht. Um ihm die Möglichkeit zu geben, mit so einer Art MoSCow-Untersuchung da dran zu gehen und zu sagen: "must be", "should be" und "could be" ... ein paar Bausteine müssen im Training drin sein, ein paar können drin sein und paar sind vielleicht ganz nett, wenn sie drin sind und können bei Bedarf herangezogen werden.

So eine Art Zeitmanagement-Werkzeug, was einer Trainerin oder einem Trainer während des Trainings vielleicht auf einem Handy oder so anzeigen würde: Ah, ich habe noch fünf muss-Themen vor mir und habe noch 12 könnte-sein-Themen, die ich bei Bedarf heranziehen kann. Dann hätte man während des Trainings einen Eindruck, wo man bis jetzt steht und was alles noch gebracht werden muss und was nicht. Also auch so eine Art kleine Zeitmanagement-App für professionelle Trainer wäre eine super Idee, eigentlich.

Abschied

[18:00] Damit kamen wir raus und haben dann überlegt, ob wir uns noch mal treffen zu dem Zeitpunkt. Ich denke aber, erst mal haben wir eine ganze Menge herausgearbeitet, was ja auch erst mal weiter behandelt werden will. Und von daher kann einige Zeit vergehen, bis wir uns zu dem Thema noch einmal treffen.

Prima, Das hat sehr viel Spaß gemacht und hat uns allen glaube ich auch einiges gebracht und ich bin schon sehr gespannt, wie das jetzt weiter in Richtung Umsetzung gehen kann...

[Abschiedsworte, Ende des Videos...]

, Devlog , Domain-Driven Design