Erfolgreich einen fachlichen Workshop gestalten! Nur wie?

Vielleicht kennt ihr diese Situation: Ihr werdet in eurer Rolle als Scrum Master von einem Kollegen aus einem anderen Team angesprochen, ob ihr nicht einen Workshop zum Thema X entwerfen und durchführen könnt.

Mir ging es kürzlich so — “Schön!” dachte ich und habe mich erst einmal über die Anfrage gefreut. Doch dann wurde mir klar: Die einzige Information, die mir mit auf den Weg gegeben wurde, war das Thema für den Workshop: Es müssen Altverträge auf eine neue Vertragsgeneration umgestellt werden.
Ein wenig dürftig, aber hey, ich wäre ja nicht Scrummaster geworden, wenn ich nicht gerne Probleme lösen würde.

Nur, wie soll man in so einem Fall vorgehen?

Inhaltliche Vorplanung für den Workshop

Teilnehmer:innen ermitteln: Wer wird benötigt und wie viele sind zu viel?

Am Anfang sollte natürlich die Auftragsklärung stehen. Aber wie das so ist: Mein Auftraggeber hatte erst einmal keine Zeit, um seine Anfrage zu spezifizieren. Also versuchte ich, an anderer Stelle zu starten: bei den Teilnehmern. 

Ich habe begonnen, die Teilnehmer für den Workshop ausfindig zu machen: Ganz klassisch mit einer Liste und per Rundfrage in den Teams, wer denn ihrer Meinung nach an dem Workshop teilnehmen sollte.

Am Ende meiner Sammlung kam ich auf über 30 Teilnehmer:innen, was mir deutlich zu viel erschien, um eine effiziente Entscheidungsfindung im Workshop zu gewährleisten. Da kam mir die rettende Idee: In unzähligen Schulungen und Weiterbildungen habe ich doch die ein oder andere Methode kennengelernt, mit der ich mir hier die Arbeit erleichtern könnte.

Ich habe mich hier für “Mit-Geld-Spielen” entschieden, um in den Teams ein Bewusstsein zu schaffen, was die Teilnahme so vieler Teammitglieder kostet. Und zwar nicht nur die Anwesenheit, sondern auch die verloren gegangene Entwicklungszeit und Ähnliches. Wir haben dann gemeinsam die Monopoly-Money-Methode genutzt. Mit dieser haben wir festgestellt, dass es den Teams doch nicht so wichtig ist, “jeden” dabei zu haben.

Und siehe da, der Workshop kann anscheinend auch mit der Hälfte der Teilnehmer:innen stattfinden. 

Meine erste Erkenntnis:
Man muss die Beteiligten dazu motivieren, sich wirklich Gedanken zu machen, wer für die erfolgreiche Durchführung des Workshops tatsächlich benötigt wird — und wer nicht.

Meine zweite Erkenntnis:
Das Aufzeigen von Kosten kann eine gute Motivation sein. 🙂 

Das Ziel des Workshops bestimmen: einfach mit “SCORE”

Mit dieser Liste war mir eines leider immer noch nicht klarer geworden. Nämlich das genaue Ziel des Workshops. Ich kannte nur den Anlass: “Wir müssen alte Verträge auf neue umstellen”, aber nicht das gewünschte Ergebnis.

Meine dritte Erkenntnis:
Der Anlass für einen Workshop ist nicht gleich dem erwünschten Ziel eines Workshops.


Okay, also die Auftragsklärung muss gemacht werden. Zum Glück habe ich mich mittlerweile an meinen “Methodenkoffer” erinnert und konnte dieses Mal gleich mit System vorgehen.

Das erste, was mir hierzu einfiel, war das SCORE-Modell. Eine einfache Methode, um Ziele zu bestimmen. SCORE ist ein Akronym, das sich aus den Anfangsbuchstaben von Symptom, Cause, Outcome, Resource und Effect zusammensetzt. Für jedes dieser Schlagworte soll eine Aussage formuliert werden, um so zu einer konkreten Zielbeschreibung zu gelangen.

Damit bin ich also nochmal zu meinem Auftraggeber gegangen, um mit ihm eine erneute Fragerunde durchzuführen. Hier das Ergebnis:

Symptom: Aktuell haben wir noch keine Ahnung, wie wir Funktion X für die Vertragsumstellung entwickeln sollen.

Cause: Weil wir das so noch nie getan haben.

Outcome: Wir wollen den Weg verstehen, den wir gehen müssen, um Funktion X umzusetzen.

Ressource: Mit einer groben Wegbeschreibung wäre uns schon sehr geholfen.

Effect: Damit können wir Funktion X verstehen und implementieren.

Was müssen wir im Workshop erarbeiten, um das Ziel zu erreichen?

So, nun hatte ich einen Anhaltspunkt, was wir erarbeiten sollen und müssen. Es braucht also eine Art Roadmap, welches Team was zu tun hat, um Funktion X zu liefern. Endlich, dachte ich. Ab jetzt wird es einfach:

1. Wir definieren das MVP,
2. erarbeiten einen User-Flow dafür und
3. bauen darauf aufbauend eine User-Story-Map auf.

Kein Problem, oder?

Ja an sich schon: Hier gibt es mehr Infos zur MVP-Definition, zur User-Flow-Definition und zum Aufbau einer User-Story-Map.

Mit diesem Plan also nochmal zum Auftraggeber und ihm vorstellen, was ich vor habe. — Zum Glück habe ich den Plan nochmal mit ihm durchgesprochen. Denn natürlich hatte ich noch immer nicht alles berücksichtigt, was es benötigt, um Funktion X zu liefern.

Meine vierte Erkenntnis:
Es lohnt sich, sich im Laufe der Workshopvorbereitung immer mal wieder Feedback vom Auftraggeber einzuholen.

Wie sollen die Teams zusammenarbeiten? Hilfe zur Selbstorganisation

Nur mit einer MVP-Definition, dem User-Flow und der Story-Map ist ja noch nichts gebaut. Der Weg der Entwicklung ist noch völlig offen. Sprich, wie wollen oder sollten denn die Teams zusammenarbeiten? Ja klar: selbstorganisiert, aber wie kann ich sie bei dieser Selbstorganisation unterstützen? Sie haben in dieser Konstellation ja noch nie zusammengearbeitet. 

Wir benötigen also eine Art Working-Agreement. Eines, dass sowohl Austauschformate, Kommunikationskanäle (synchrone wie asynchrone), Informationssammlung bzw. Dokumentation und auch ganz wichtig das “wie” sie zusammenarbeiten beinhaltet.

Welch ein Glück für den Moderator, dass er diese Aufgabe einfach an die Teilnehmer:innen zurückspielen kann. Habe ich schon erwähnt, dass ich Selbstorganisation liebe <3 ? Die Erstellung des Working-Agreements wurde also kurzerhand zu einem Agendapunkt für den Workshop.

Meine fünfte und sechste Erkenntnis:
Vergiss nicht, die Art der Zusammenarbeit im Workshop zu thematisieren und gib die Definition des Working-Agreements in einem eigenen Agendapunkt an das Team ab.

Den Workshop vorbereiten

Setting und Tools festlegen

Endlich hatte ich das Gefühl, dass ich alle inhaltlich relevanten Punkte für den Workshop auf meiner Agenda habe. Außer natürlich die Agenda selbst und die Vorbereitung und damit auch die Frage, ob wir den Workshop remote, hybrid oder vor Ort abhalten und welche Tools wir einsetzen können und möchten. 

Puh, das hieß also nochmal eine Runde mit den Beteiligten drehen, um all das zu klären. In dem hier beispielhaft aufgezeigten Workshop haben wir uns für einen Remote-Workshop mit einem Online-Whiteboard entschieden.

Dank der erneuten Befragungsrunde der Teams wusste ich jetzt auch, dass viele der Teilnehmer:innen sich nicht besonders gut mit Online-Whiteboards auskennen und deren Nutzung am liebsten vermeiden. Somit kam nun die Aufgabe dazu, den Teilnehmer:innen die “Angst” vor Online-Whiteboards zu nehmen.

Meine siebte Erkenntnis:
Beziehe die Teilnehmer:innen bei der Auswahl der Online-Tools für den Workshop mit ein und gehe auf ihre Unsicherheiten ein, z.B. über eine Gelegenheit zum spielerischen Tool-Test.

Workshop-Agenda erstellen und Einladungen verschicken

Somit waren nun meine ToDos für die nächsten Stunden klar. Zuerst musste ich die Workshop-Agenda, alle zuvor gesammelten relevanten Inhalte und eine Umgebung für Vorabfragen und Tool-Test auf dem Whiteboard aufsetzen, sodass sich folgende Bereiche ergaben:

  • Tool-Spielplatz, um im Voraus den Umgang mit dem Whiteboard üben zu können
  • Bereich für wichtige Fragen, die im Voraus aufkommen
  • Parkplatz für Themen, die nicht sofort während des Workshops geklärt werden können
  • Die Workshop-Agenda
  • Check-In
  • Working-Agreement für den Workshop
  • Ziel des Workshops
  • MVP-Definition
  • User-Flow
  • Story-Map
  • Working-Agreement für die Zusammenarbeit nach dem Workshop
  • “Abräumen” des Parkplatzes
  • Check-Out
Ansicht des Whiteboards zum Remote-Workshop.

Außerdem schreibe ich eine Einladung, in der folgende Informationen enthalten sind:

  • Laptop ist Pflicht
  • Erklärvideos zu Online-Whiteboards
  • Testen, ob das Whiteboard erreicht werden kann
  • Agenda mit Pausenzeiten formulieren

Kurz auf den Punkt: Das waren meine Aufgaben bei der Workshop-Konzeption

Aber was hab ich denn jetzt eigentlich zu welchem Zeitpunkt genau gemacht und wann war ich auf die Mitarbeit anderer angewiesen? Nun, als erstes wurde ja die Auftragsklärung abgeschlossen und die Teilnehmer:innen ausfindig gemacht: Der Teil wurde eher von mir begleitet und der Auftraggeber bzw. die Teams haben die benötigten Antworten geliefert. Ich habe hier den organisatorischen Rahmen vorgegeben und mit der SCORE- und der Monopoly-Money-Methode Hilfestellung geleistet bzw. bei der Teilnehmerzahl noch einmal nachjustiert. 

Im Anschluss habe ich die Agenda konzipiert und zur Ermittlung des Kenntnisstandes der Teilnehmer:innen noch einmal Rücksprache gehalten. Die Rückmeldung musste ich dann wieder bei meiner Planung und dem Ausarbeiten der Agenda berücksichtigen. 

Das Whiteboard zu erstellen und die Einladung dazu zu versenden, war wiederum ein Doing, das ganz in meiner Verantwortung liegt. 

Am Ende der gesamten Kette steht dann natürlich noch das Durchführen und Moderieren des Workshops, was ich sehr gerne gemacht habe.

Workflow: Vom Auftrag zum Workshop.

Fehler, die ich den Leser:innen ersparen möchte

Für alle, die bis hierher durchgehalten haben: Erstmal danke, ich hoffe ich konnte euch ein bisschen kurzweilige Lesezeit verschaffen und euch weiterhelfen. Zusätzlich wird dem ein oder anderen erfahrenen Facilitator aufgefallen sein, dass mir ein, wie ich vermute, häufig vorkommender Fehler bei meiner Workshop-Vorbereitung unterlaufen ist. Hätte ich nämlich zuerst das Ziel des Workshops bestimmt und mich im Anschluss auf die Suche nach den benötigten Teilnehmer:innen gemacht, hätte ich mir mindestens eine Klärungsrunde mit den Teams sparen bzw. die Suche nach den relevanten Teilnehmer:innen stark vereinfachen und verkürzen können.

Leider muss man manchmal einfach weitermachen, auch wenn man nicht von Anfang an den optimalen Weg gegangen ist. Lieber einen kleinen Schritt vorwärts als stehenbleiben.

Ähnliche Beiträge

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert