Workshops
Ich habe in letzter Zeit öfter mal einige Stunden in einem Workshop verbracht, in dem wir einen bestimmten Prozess austüfteln und auf die Beine stellen wollen. Ich habe nicht nur geredet, sondern auch viel zugehört, und dabei sind mir ein paar Dinge aufgefallen, die man anders machen könnte, wenn man möchte, dass bei all dem Gerede auch bald etwas Brauchbares rauskommt.
Das Wort Workshop kommt ursprünglich aus dem Englischen und bedeutet wörtlich schlicht „Werkstatt“. Der Begriff wurde im Business-Kontext metaphorisch übernommen und meint ein Arbeitsformat, in dem Teilnehmer gemeinsam aktiv an etwas arbeiten, statt nur zuzuhören. Der Umkehrschluss funktioniert hier natürlich nicht, denn wir alle arbeiten auch dann fleißig und aktiv, wenn wir gerade nicht in einem Workshop sitzen. Auf jeden Fall.
Auch andere Sprachen bedienen sich der Manufaktur-Metapher, ziehen dem englischen Begriff aber den in der eigenen Sprache vor. So setzen sich die Franzosen zu einem atelier stratégique zusammen, Spanier brüten in einem taller de innovación, und Finnen berufen eine työpaja („Arbeitswerkstatt“) ein.
Unabhängig davon, wie man das Format nennt – eines haben alle gemeinsam: Es wird ganz viel geredet (oft auch gleichzeitig). Wir beginnen damit, uns anzuschauen, wie das Geredete denn strukturiert ist – und wie schändlich wir mit diesen Strukturen umgehen.
Implizite Fragen und sprunghafte Antworten
Wenn ich mit einem Freund an der Donau spaziere, dann erzählt er etwas – das erinnert mich an etwas anderes und ich spreche ein wenig darüber. Plötzlich fällt ihm etwas ganz anderes ein, und es geht damit weiter. Wir lassen uns treiben. Wenn man unter Freunden plaudert, dann ist das völlig okay. Wenn man mit anderen in einem Workshop sitzt, dann ist das nicht okay. Dann kommen bezüglich dem, was man sagt und was man nicht sagt, Strukturen zum Tragen, die eingehalten werden sollten. Und welche Strukturen sind das? Jene von Fragen und Antworten.
Ich behaupte: Auch wenn die jeweilige Frage nicht immer ausgesprochen, oder gar an die Wand geschrieben wird, dann ist alles, was in einem Workshop gesagt wird, eine Antwort auf eine Frage. Allerdings – wir alle haben es erlebt – nicht unbedingt auf eine wichtige, relevante, interessante Frage.
In Hinblick auf die Frage-Antwort-Struktur schlage ich die gleich folgenden Regeln vor. Wie die Verteilung der folgenden Punkte zwischen Fragesteller und Antwortgeber zeigt, ist beim Beantworten noch viel mehr Vorsicht geboten als beim Fragenstellen. Das kommt auch daher, dass die Antworten zumeist viel, viel länger sind als die Fragen – wenn erstere überhaupt ausgesprochen werden!
Fragesteller, Moderator
Stelle Fragen nur dann, bzw. lasse sie von anderen nur dann zu, wenn sie wichtig und für die gemeinsame Sache relevant sind.
Antwortgeber
- Zolle den Fragen, und den Personen, die sie stellen, Respekt, indem du danach strebst, die Fragen zuerst richtig zu verstehen und dann tatsächlich zu beantworten. Es ist nicht okay, auf eine halb verstandene Frage hin auf Verdacht loszureden. Es ist nicht okay, aus einer Frage ein Schlüsselwort zu picken – und dann frei loszureden über alles, was einem dazu einfällt.
Besonders wenn die Frage wichtig und relevant ist, bleibt bei dieser, bis sie ausreichend beantwortet ist. - Beantworte keine anderen Fragen als die aktuell gestellte
- Beantworte keine Fragen, die niemand (nicht wenigstens der Sprecher selber) explizit gestellt hat
Wenn jemand spricht, frag dich, welche Frage er gerade beantwortet (du wirst überrascht sein).
Meiner Erfahrung nach sind Menschen extrem tolerant, was unklare Frage, unpassende Antworten, Themenwechsel und das Ausbreiten von Nebensächlichkeiten angeht. Dadurch sind unsere Meetings zwar kuschelig-liberal, aber für den Fortschritt bei der Sache ist das ein echtes Problem.
Mit Fragen und Antworten kann man also viel falsch, aber auch viel richtig machen. Jetzt gehen wir etwas näher ran: Was ist es denn, nach dem die Fragen fragen – und welchen Zweck erfüllen die Antworten?
Gesprächs-Modi
Neulich knie ich mit dem Chef der Handwerkerfirma meines Vertrauens am Boden unseres Dachbodens und schaue schräg unter einen halb verlegten Holzboden. Er erzählt mir etwas über Zwischenwände, Dämmung und eine unzureichend verlegte Insolier-Schicht. Er spricht von Möglichkeiten, wie wir bei der Reparatur vorgehen könnten. Ich höre verschiedene Optionen und denke mir: Jetzt kommt’s gleich, ich muss etwas entscheiden. Durch mehrmaliges Nachfragen finde ich allerdings heraus, dass alle Optionen bis auf 1 doch gar nicht infrage kommen. Schließlich verstehe ich, dass mein Gegenüber mich über eine klar auf der Hand liegende Vorgehensweise informieren wollte. Ich gab mein Okay und es ging weiter.
Das Gespräch war kurz und harmlos – interessant war für mich, wie es sich gedreht hat. Ich wähnte mich zuerst in einer Entscheidung. Dann wurde mir klar, dass ich nur eine Info erhalte (und von mir ein Okay eingeholt wird). Das erste ist etwas ganz anderes als das zweite.
Eine Entscheidung, die A von B verlangt, und eine Info von A an B (mit Bitte um grünes Licht) sind zwei Beispiele für verschiedene Modi (oder Vorgänge, Betriebsarten) in einem Gespräch. Es ist eine Antwort auf die Frage, was in dem Gespräch vorgeht, was es soll, auf welches Ziel es sich hinbewegt. Auch in Meetings und Workshops, so wurde mir klar, gibt es ganz konkrete, voneinander unterscheidbare Modi. Und soweit ich das sehen kann, gliedern sie sich in drei Gruppen.
- Einer redet (sendet) zu den anderen
- Alle denken gemeinsam nach (und reden darüber)
- Alle reden mit- oder gegeneinander
Reden um...
| icon | …den Unwissenden zu erklären wie es ist. Eine Person belehrt, vermittelt Wissen. Das kann zBsp. ein Status-Update, Hintergrundwissen oder eine Problembeschreibung sein. | „Let me teach you!“ SPEECH |
|---|---|---|
| icon | …einen Vorschlag zu verkaufen. Eine Option, ein Vorschlag wird – wie in einem Sales Pitch – präsentiert, begründet, verkauft. | “This is what’s best for you.” SALES PITCH |
…den Unwissenden zu erklären wie es ist. Eine Person belehrt, vermittelt Wissen. Das kann zBsp. ein Status-Update, Hintergrundwissen oder eine Problembeschreibung sein.
„Let me teach you!“
SPEECH
…einen Vorschlag zu verkaufen. Eine Option, ein Vorschlag wird – wie in einem Sales Pitch – präsentiert, begründet, verkauft.
“This is what’s best for you.”
SALES PITCH
Nachdenken um…
…Aspekte zu sammeln, wie etwas ist, ein vollständiges Bild gewinnen – zBsp. Schritte in einem Prozess oder denkbare Anwendungsfälle
„Was fällt uns alles ein?“
AS-IS BRAINSTORMING
…Optionen oder Ideen zu sammeln, wie etwas sein könnte. Das ist der klassische Fall des Brainstormings.
„Was könnten wir uns vorstellen?“
TO-BE BRAINSTORMING
…das Vorgeschlagene zu bewerten, oder gegen Anderes zu priorisieren
„Ist das gut?“
EVALUATION
Dialog führen / diskutieren um…
…zu erörtern, wie etwas zu sehen ist (Für und Wider abwägen, Verständnis sichern) und eine gemeinsame Sichtweise zu erzielen (was für alle Sinn macht). Das schließt ein: Nachfragen, gemeinsame Begriffe finden, gemeinsames Bild (AS-IS) entwickeln, Klarheit schaffen darüber, was wir brauchen oder was das Problem ist.
„Wie sehen wir das?“
COMMON VIEW
…eine gemeinsamen Vorstellung von etwas Neuem (Entwurf, Plan) zu entwickeln. Das ist „Co-Design“ und kann das gemeinsame Entwerfen eines Plans, einer Roadmap, einer Vision sein.
„Wie soll das werden?“
COMMON PLAN
…eine Entscheidung herbeizuführen und zu dokumentieren. Das schließt ein: Eine Einigung suchen und aushandeln, sich festlegen und entscheiden (zBsp. durch Abstimmung, oder Konsens), und etwas fixieren und dokumentieren (zBsp. Beschlussformulierung und Protokoll, Definitionen oder Problem Statements)
CONTRACT
Haben wir einmal erkannt, dass Workshops und Meetings in diesen Modi ablaufen, und begonnen, die Vorgänge in diesem Licht zu betrachten, dann wird uns manches auffallen. Eine Speech ist super, solange die anderen um die Belehrung gebeten haben. Ein To-Be-Brainstorming (genau wie ein Common Plan) ist dann die Zeit wert, wenn das jetzt wirklich die aktuelle Frage ist. Eine Evaluation sollte dann gemacht werden, wenn genug Infos vorliegen, und zwar von allen, nicht nur einseitig. Für einen Contract sollte die passende Runde von Leuten anwesend sein, und diesem Modus sollte ein Common-View-Dialog vorausgehen. Letzterer sollte ausgewogen sein. Du wirst künftig erkennen, wenn dieser in eine Speech oder eine Sales Pitch kippt.
Regeln für Workshoppers
Du siehst, und weißt natürlich längst, dass hier viel schiefgehen kann. Und regelmäßig schiefgeht! Damit das alles ganz schnell viel besser wird, habe ich im Folgenden meine liebsten Regeln zusammengestellt, genährt durch viele Dienstjahre in diversen Büros, und (Hör-) Bücher, die mir unterwegs begegnet sind. Aber ich will ehrlich sein: Wie immer im Leben ist das Kunststück nicht, die Regeln zu kennen – sondern die anderen dazu zu bringen, nicht mehr so viel Blödsinn zu machen.
Regeln zum Arbeiten in der Gruppe
Term discipline
Etabliert klare, sinnvolle Bezeichnungen, mit denen fortan unverändert gearbeitet wird. Seht davon ab, dieselbe Sache mal so und mal so zu nennen. Seht auch davon ab, zwei unterschiedliche Sachen auf die gleiche Weise zu bezeichnen.
Gefahr: Jedes Mal wird von neuem umständlich umschrieben. Auf der anderen Seite wissen die Kollegen nie genau, was gemeint ist.
Beispiele: Ein Anwendungsbeispiel, das den bisherigen Entwurf infrage stellt, wird einmal erklärt und dann mit einem Wort benannt (“der Chile-Fall”). Fortan reicht es, dieses Wort zu nennen. Es gibt eine Gruppe von Personen, die ein berechtigtes Interesse am Projekt haben. Eine vielleicht überlappende, aber etwas andere Gruppe ist jene der Personen, die zum Projektabschluss einen internen Report bekommen sollen. Beide “Stakeholder” zu nennen wird zu nichts Gutem führen.
Assumption awareness
Benennt Annahmen explizit, markiert sie als solche – und strebt danach, diese bald zu verifizieren – Erkennt, wenn Ihr etwas nicht wisst (eine Frage unbeantwortet bleibt) und versucht, das baldmöglichst zu klären.
Gefahr: Annahmen werden mit Wissen verwechselt – und es wird die Chance versäumt, die Annahme bald gegen Wissen einzutauschen
Out of focus
Erkennt Nebensächlichkeiten, weist darauf hin und haltet euch nicht damit auf.
Gefahr: Zu viel Zeit und Fokus wird für Themen aufgewendet, die euch nicht weiterbringen
Pseudo problem
Erkennt Scheinprobleme. Diese liegen vor, wenn man Lösungen diskutiert, obwohl das eigentliche Ziel oder Problem noch gar nicht klar ist.
Gefahr: Problemlösungs-Arbeit und -Aufwand, der auf keinem Fundament steht und ins Leere geht
Quantify
Klärt, wo sinnvoll, die Frage, welche (ungefähren!) Zahlen hinter etwas liegen – erkennt dadurch notwendige Kapazitäten, die (rel.) Bedeutung (Verteilung der Wichtigkeit) und damit zBsp. ob sich der Aufwand lohnt. „Über welche Größenordnung reden wir hier ungefähr?“
Gefahr: Entscheidungen werden auf Basis des Bauchgefühls (der lautesten Person im Raum) getroffen
Regeln zum Prozess
Before/after
Schaut euch einen Ablauf konsequent von Anfang bis Ende an. Fragt also: Was passiert vorher noch? Und wie geht es danach weiter?
„Ist das hier wirklich der ganze Prozess oder nur ein Ausschnitt?“
Gefahr: Von dem, was tatsächlich der gesamte Prozess ist, wird nur ein Teil ausgearbeitet.
Happy path
Denkt erstmal nicht an die Fehler, die Sonderfälle und die Abbrüche. Fragt euch besser, wie der ganz normale, erhoffte „Happy path“ aussieht. Fokus auf relevante, einfache, erhoffte Anwendungsfälle – nicht auf Corner cases
„Bevor wir über alle Ausnahmen reden – was ist der ganz banale Standardfall?“
Gefahr: Ihr verliert euch in Sonderfällen, ohne den Kernprozess zu verstehen.
Walk backwards
Wann immer es Sinn macht, versucht, (auch) von hinten nach vorne zu arbeiten. Wenn wir später X brauchen, dann müssen wir das rechtzeitig vorher erstellen/erhalten.
„Was brauchen wir weiter hinten – und was muss dafür weiter vorne passieren?“
Gefahr: Wichtige Schritte werden im Prozess nicht mitgedacht und festgeschrieben. Zu einer Betrachtung der Abhängigkeiten kommt es erst gar nicht.
Regeln zum zu konzipierenden Objekt
Main stream
Eure erarbeitete Lösung muss nicht jeden einzelnen Anwendungsfall abdecken. Es ist OK, Corner cases nicht abzudecken.
„Wie oft kommt dieser Fall, den wir hier ausführlich diskutieren, wirklich vor?“
Gefahr: Viel Herzblut fließt in die Vorbereitung von Fällen, zu denen es praktisch nie kommt. Dem gegenüber werden die Standardfälle, zu denen es ständig kommt, mit zu wenig Aufmerksamkeit und Muße bedacht.
Set in stone
Macht euch klar, welche Ergebnisse bald in einer finalen Form geliefert werden müssen – und welche in einer Entwurfsform sein dürfen, weil Ihr sie später noch ändern könnt (“das können wir uns später noch genauer ausdenken”)
„Was können wir später noch ganz easy ändern – und was kaum mehr?“
Gefahr: Ihr verbrennt Zeit und Fokus für die falschen Themen
Beispiele: Bei einer Prozessentwicklung sind die großen Phasen und Stufen bald zu entscheiden, und final zu gestalten. Dem gegenüber können die Felder eines Formulars, oder gar dessen grafische Gestaltung, später noch dreimal geändert werden.
Dilemma awareness
Erkennt ein Dilemma, wenn eines vorliegt, benennt es und strebt danach, eine Lösung zu finden, die es auflöst. Es wird die Chance verpasst, das Dilemma aufzulösen – und der eine oder andere Nachteil kommt zum Tragen
KISS (Keep it simple and stupid)
Strebt immer nach einer Lösung mit klaren Strukturen, einfachen Prozessen und geringem Aufwand. Jede zusätzliche Struktur (Komplexität, Detaillierung) nur dann in Betracht ziehen, wenn sie durch den zusätzlichen Nutzen gerechtfertigt ist. Ist von Lösungen mit hohem Aufwand, komplexen Strukturen und langwierigen Prozessen die Rede, sollten die Alarmglocken schrillen.
„Was ist der große zusätzliche Nutzen, der diese Komplexität rechtfertigt?“ und „Wollen wir uns trauen, das erst mal wegzulassen?“
Gefahr: Unnötig komplexe Strukturen, die mühsam aufzusetzen, zu nutzen und zu warten sind
Beispiele: Eigene Prozess-Varianten für Fälle, die einmal alle 3 Jahre vorkommen. Dokumentation, die niemand liest. Reviews und Freigaben von Dokumenten, die wenig Bedeutung haben
Build to learn
Erkennt an, dass ihr kein zu 100% funktionierendes Ding im Kopf/auf Papier planen könnt. Zielt also auf eine Art „MVP“ ab, um dieses in der Realität zu erproben und daran zu lernen.
„Könnten wir das einfach ausprobieren, anstatt es noch einmal zu diskutieren?“
Gefahr: Es wird etwas vermeintlich perfektes fertig gebaut – um dann festzustellen, dass sein Einsatz/die Verwendung ganz anders aussieht als geplant.