Liberating Structures Workshop-Vorlagen für Scrum Teams

1. 1-2-4-All (1-2-4-Alle)

Kurzbeschreibung: 1-2-4-All ermöglicht es, alle Teilnehmer gleichzeitig einzubeziehen und in kurzer Zeit zahlreiche Ideen, Fragen und Vorschläge zu generieren[1]. In nur etwa 12 Minuten durchlaufen alle nacheinander Einzelarbeit, Paar- und Vierergruppenarbeit bis hin zur Diskussion im Plenum. Dadurch werden stille oder zurückhaltende Personen geschützt einbezogen, Machtgefälle verringert und ein offener, produktiver Austausch entsteht, der zu einem gemeinsamen Verständnis und besseren Ergebnissen führt[1].

Ablauf (Zeitplan):

Moderationsanweisungen: Formuliere zu Beginn eine klare Einladungsfrage, die den Fokus der Gruppe definiert (z. B. „Welche Möglichkeit siehst du, im nächsten Sprint Verbesserung X zu erreichen?“). Achte darauf, dass wirklich jeder zunächst in Stille nachdenkt, bevor der Austausch beginnt[2]. Signalisiere den Phasenwechsel (z. B. mit einer Glocke) und halte die Zeit strikt ein[2][3]. Bitte die Teilnehmer, sich in der Einzelphase Notizen zu machen, um ihre Gedanken zu fokussieren. Im Plenum solltest du Doppelungen vermeiden – bitte jede Gruppe, nur neue Punkte einzubringen, und beschränke bei sehr großen Runden die Zahl der Meldungen (z. B. max. 3–4 Beiträge)[4]. Falls nötig, ermutige zu einem zweiten Durchlauf anstatt die Zeitlimits zu überschreiten, um noch tiefergehende Erkenntnisse zu gewinnen[5].

Konkrete Fragestellungen im Scrum-Kontext:
– Sprint-Retrospektive: „Welche eine Verbesserung hat den größten Einfluss auf unseren nächsten Sprint?“ – Alle Teammitglieder generieren zunächst eigenständig Vorschläge und verdichten diese mit 1-2-4-All zu den vielversprechendsten Verbesserungsansätzen.
– Sprint Planning: „Welche potenziellen Risiken oder Hindernisse sehen wir für den kommenden Sprint, und wie könnten wir ihnen begegnen?“ – Das Team sammelt mittels 1-2-4-All alle Befürchtungen oder Unsicherheiten und identifiziert die wichtigsten Punkte, um entsprechende Gegenmaßnahmen einzuplanen.
(Ähnliche Fragestellungen lassen sich für weitere Events formulieren, z. B. im Sprint Review: „Welches Feedback der Stakeholder ist für uns am bedeutendsten und wie wollen wir darauf reagieren?“, oder imBacklog Refinement: „Welche Kriterien müssen unsere User Stories erfüllen, um ‚ready‘ zu sein?“)

Mögliche Themen oder Anwendungsfälle für Scrum-Teams: 1-2-4-All eignet sich für Ideensammlungen und Problemlösungen in nahezu allen Scrum-Settings. Beispiele: Brainstorming von Verbesserungsmaßnahmen in Retrospektiven, Erarbeiten eines Sprint-Ziels im Planning, Einholen von Kunden-Feedback in Workshops (z. B. gemeinsam mit Stakeholdern im Review) oder um festgefahrene Teamdiskussionen wieder in Gang zu bringen[6]. Kurz: Immer wenn alle Stimmen gehört werden sollen und ein breites Gruppenwissen genutzt werden kann, bietet 1-2-4-All einen geeigneten Rahmen.

Tipps für die Durchführung:
– Timeboxing streng einhalten: Die kurzen Zeitfenster (gesamt ca. 12 Minuten) sorgen für Fokus und Energie[1]. Verwende ggf. Timer oder Glocken, um den Ablauf zu steuern.
– Inklusives Umfeld schaffen: Ermutige alle – besonders ruhigere Personen – ihre Ideen zu teilen. Die klare Struktur hilft auch Zurückhaltenden, sich einzubringen.
– Visualisierung nutzen: Lasse die Teilnehmer wichtige Ideen aufschreiben oder mit Post-its festhalten, um sie sichtbar zu machen[7].
– Nicht überstrapazieren: 1-2-4-All ist sehr vielseitig, aber nicht jede Diskussion muss damit geführt werden. Setze es gezielt dort ein, wo schnelle, breite Beteiligung gefragt ist, und kombiniere es bei Bedarf mit anderen Methoden (z. B. zur Vertiefung von Ideen durch Improv Prototyping oder Ecocycle Planning)[7].

2. Impromptu Networking (Spontanes Vernetzen)

Kurzbeschreibung: Impromptu Networking hilft, schnell Verbindungen zu knüpfen und wichtige Erwartungen oder Herausforderungen zu teilen. Innerhalb von etwa 15 Minuten entsteht durch mehrere kurze Zweiergespräche sofort eine produktive Arbeitsatmosphäre[8]. Die Teilnehmer „tauten auf“ und bringen verborgene Anliegen oder Talente ans Licht, indem sie in wechselnden Paaren Fragen zu ihren aktuellen Herausforderungen und Erwartungen beantworten. So wird Neugier geweckt, engagiertes Mitmachengefördert und jeder Einzelne leistet von Beginn an einen Beitrag zur gemeinsamen Arbeit[8].

Ablauf (Zeitplan):

Moderationsanweisungen: Formuliere eine offene Einstiegsfrage, die sowohl auf fachliche Herausforderungen als auch auf gegenseitige Erwartungen abzielt (z. B. „Welche Herausforderung bringst du mit, und was möchtest du von der Gruppe bekommen bzw. ihr geben?“[9]). Bitte die Teilnehmer, sich in jeder Runde mit jemandem auszutauschen, den sie noch nicht gut kennen (bei bekannten Teams: mit Kollegen aus anderen Bereichen/Teams mischen)[10]. Kündige den Rundenwechsel akustisch an (Glocke, Klatschen o. Ä.), damit alle gleichzeitig die Partner wechseln[11]. Achte darauf, dass jeder in den Paaren ungefähr gleich viel Redezeit erhält. Als Facilitator kannst du die Leitfrage zu Beginn kurz erläutern und die Energie hochhalten, greifst aber während der Gespräche nicht inhaltlich ein.

Konkrete Fragestellungen im Scrum-Kontext:
– Sprint Planning (Kick-off): „Worauf freust du dich im kommenden Sprint und was bereitet dir Sorgen?“– Alle Teammitglieder tauschen vor Sprintbeginn ihre Erwartungen und Befürchtungen aus. So entsteht ein gemeinsames Verständnis der Stimmung und Fokusbereiche des Teams zu Sprintstart.
– Sprint Review (Stakeholder-Check-in): „Welche Erwartung hast du an dieses Review und was kannst du der Gruppe heute anbieten?“ – Bevor die eigentliche Review-Präsentation beginnt, vernetzen sich Team und Stakeholder in kurzen Zweiergesprächen. Erwartungshaltungen werden geteilt und die Zusammenarbeit mit externen Beteiligten wird gleich zu Beginn persönlicher.
(Weitere Anwendungen: als Icebreaker vor einem Workshop, zum Start einer Retro die aktuellen Anliegen sammeln, oder bei Team-Kickoffs, um neue Mitglieder schnell zu integrieren.)

Mögliche Themen oder Anwendungsfälle für Scrum-Teams: Impromptu Networking wird oft gleich zu Beginn eines Meetings oder Events eingesetzt, um sofort alle einzubinden und eine energiegeladene Stimmung zu schaffen[8]. In Scrum-Teams eignet es sich z. B. zum Start von Retrospektiven (Erwartungen ans Retro-Thema teilen), bei Sprint Reviews (Kunden und Team kommen vorab ins Gespräch), oder in Workshops mit mehreren Teams (z. B. Communities of Practice), um den Austausch zwischen verschiedenen Disziplinen anzuregen. Auch bei Trainings oder bereichsübergreifenden Meetings hilft diese Struktur, Barrieren abzubauen und ein Netzwerk von Kontakten im Raum zu knüpfen.

Tipps für die Durchführung:
– Geeignete Fragen wählen: Kombiniere in der Leitfrage persönliches Aufwärmen mit inhaltlichem Fokus (z. B. Herausforderung + Erwartung). So entsteht sofort Relevanz für alle[9][12].
– Ernsthafte Verspieltheit: Ermuntere die Teilnehmer mit Spaß an die Runden zu gehen, aber dennoch beim Thema zu bleiben. Eine positive Grundhaltung erleichtert das „Auftauen“ Zurückhaltender[13].
– Drei Runden durchführen: Die vollen drei Gesprächsrunden sollten genutzt werden – erst die Wiederholung und Variation in Runde 2 und 3 führt zu vertiefter Reflexion und besseren Verbindungen[14].
– Diskretion wahren: Da es um persönliche Herausforderungen gehen kann, muss nichts im großen Plenum berichtet werden. Wenn überhaupt, dann vorsichtig nachfragen, ob jemand freiwillig eine Erkenntnis teilen will[15].

3. Nine Whys (Neunmal Warum)

Kurzbeschreibung: Nine Whys dient dazu, den tieferen Sinn oder Zweck einer gemeinsamen Arbeit aufzudecken und zu teilen[16]. Durch wiederholtes Nachfragen („Warum ist das wichtig?“ – bis zu neunmal) hilft diese Struktur einem Team, die eigentliche Motivation hinter ihrer Tätigkeit oder einem Vorhaben herauszuschälen. Das Ergebnis ist eine klare, gemeinsame Purpose-Statement, die Fokus, Motivation und Verantwortung innerhalb der Gruppe steigert[16]. Wenn eine Gruppe ihr „Warum“ gefunden hat, entstehen oft automatisch mehr Engagement und Innovationsfreude, da alle verstehen, wofür sie gemeinsam einstehen[16].

Ablauf (Zeitplan):

Moderationsanweisungen: Sorge für eine vertrauensvolle Atmosphäre, da das Hinterfragen persönlicher Motivation etwas Intimes sein kann. Stelle klar, dass es kein Richtig/Falsch gibt und dass wertfrei nachgehakt wird („Warum ist das für dich wichtig?“ – nicht allgemein)[17]. Die Interviewer sollen mit echtem Interessezuhören, nicht bewerten, und variieren, wie sie fragen (z. B. „Erzähl mehr… warum bedeutet dir das etwas?“), um dem Gespräch Tiefe zu geben[18]. Stoppe das „Warum“-Fragen, wenn der Befragte offensichtlich den Kern erreicht hat oder unsicher wird – spätestens nach neunmaligem Nachfragen. Teilt anschließend die Vielfalt der gefundenen Gründe in der Gruppe, um ein Gefühl für den gemeinsamen Nenner zu bekommen[19]. Weise darauf hin, dass es hier darum geht, Verständnis aufzubauen, nicht sofort Lösungen oder Maßnahmen abzuleiten.

Konkrete Aufgabenstellungen im Scrum-Kontext:
– Team-Kickoff: „Warum ist es dir persönlich wichtig, an diesem Produkt/Projekt zu arbeiten?“ – In einem neu formierten Scrum-Team kann Nine Whys helfen, die individuellen Antriebe offenzulegen und zu einem gemeinsamen Team-Zweck zu finden. Jeder erläutert, warum ihm die Mission wichtig ist, was ein gemeinsames „Warum“ des Teams formt.
– Sprint Goal klären: „Warum ist dieses Sprint-Ziel für uns als Team bedeutsam?“ – Vor oder während des Sprint Plannings können die Mitglieder durch wiederholtes Warum-Fragen ergründen, welcher Wert hinter dem vorgeschlagenen Sprint Goal steckt. Das erhöht die Identifikation mit dem Ziel und deckt auf, ob alle das gleiche Verständnis haben.
(Auch anwendbar für Produktvisionen: z. B. „Warum sollte es dieses Produkt geben?“ oder zurMotivationsklärung in schwierigen Phasen: „Warum ist unsere Arbeit (noch) sinnvoll?“, um dem Team Sinnstiftung zu geben.)

Mögliche Themen oder Anwendungsfälle für Scrum-Teams: Nine Whys ist ideal, um übergeordnete Zielezu klären – sei es die Produktvision, der Product Goal, ein Sprint Goal oder die Daseinsberechtigung eines Projekts. Es hilft bei der Teamentwicklung (gemeinsame Werte/Purpose finden) und kann in Retrospektiveneingesetzt werden, wenn ein Team den tieferen Grund für wiederkehrende Probleme verstehen will („Warum stört uns X wirklich?“ – mehrmals gefragt, um zum Kern zu kommen). Generell fördert Nine Whys die Selbstreflexion und Ausrichtung: Teams verstehen, was ihnen wirklich wichtig ist, was Entscheidungen und Priorisierungen in Scrum erleichtert[20]. Es schafft zudem einen Motivationsschub, da ein klarer Purpose intrinsisch antreibt.

Tipps für die Durchführung:
– Sicherer Raum: Beginne eventuell mit einer persönlichen Beispiel-Antwort, um zu zeigen, dass es in Ordnung ist, ins Detail zu gehen. Absolute Ehrlichkeit wird ermutigt, aber jeder teilt nur, was er möchte.
– Spielerisch bleiben: Lade die Teilnehmer ein, ihr „inneres neugieriges Kind“ hervorzuholen, das unbefangen immer wieder „Warum?“ fragt[18]. Humor und Leichtigkeit nehmen dem Prozess die Schwere.
– Variationen im Fragen: Anstatt monoton „Warum? Warum?“ zu wiederholen, formuliere um: „Was macht das ausgerechnet für dich wichtig?“, „Was wäre anders, wenn das (über Nacht) erfüllt wäre?“[21]. So bleibt die Unterhaltung flüssiger.
– Empathisch bohren: Zeige Mitgefühl, während du tiefer gräbst. Falls jemand stockt, kann die Frage „Fällt dir dazu eine Geschichte oder Erfahrung ein?“ helfen[22].
– Wiederholung als Ritual: Überlege, Nine Whys in regelmäßigen Abständen (z. B. quartalsweise) zu machen, um zu sehen, ob sich der Team-Purpose wandelt[23]. Dies hält die Ausrichtung aktuell.

4. Wicked Questions (Verzwickte Fragen)

Kurzbeschreibung: Wicked Questions ermöglichen es einem Team, scheinbar widersprüchliche Realitäten nebeneinander offenzulegen, um daraus geschärftes strategisches Denken zu entwickeln[24]. Indem paradox klingende Herausforderungen gleichzeitig betrachtet werden („Wie kann es sein, dass wir X und Y zur selben Zeit tun?“), reduzieren Wicked Questions das übliche „Entweder-oder“-Denken[25]. Sie bringen gegensätzliche, aber einander ergänzende Kräfte ans Licht – die Spannungsfelder, die das Verhalten eines Teams beeinflussen[26]. Dadurch entstehen innovative Strategien, die beide Pole berücksichtigen, anstatt in extremen Kurswechseln zu schwingen. Kurz: Die Methode macht es gefahrlos möglich, unausgesprochene Zielkonflikte oder Dilemmas offen zu benennen und verborgene Chancen im Paradoxon zu entdecken[27].

Ablauf (Zeitplan):

Moderationsanweisungen: Stelle sicher, dass die Teilnehmer die zwei Seiten einer Wicked Question wertfreiund anerkennend betrachten – nicht als gut vs. schlecht[30]. Die Formulierung sollte neutral bleiben: „Wie können wir A und B gleichzeitig erreichen?“ statt „Warum verhindert A immer B?“. Vermeide „garstige“ Fragen, die Schuld zuweisen oder negativ gefärbt sind[31]. Beispiele sind entscheidend: Bringe genügend Beispiel-Wicked-Questions (ggf. aus anderen Kontexten), damit das Team versteht, was mit paradoxen Gegensätzen gemeint ist (z. B. „Wie können wir extrem kundenorientiert und gleichzeitig Kostenführer sein?“). Ermutige die Gruppe zu schnellen Iterationen – lieber viele rohe Fragen generieren und dann verfeinern („Vorwärtsscheitern“)[32]. Achte darauf, dass keine faktischen „Entweder-Oder“-Fragen gestellt werden, die sich durch Analyse lösen ließen – es müssen echte gleichzeitig zutreffende Gegensätze sein[33]. Als Facilitator hilf ggf. beim Umschreiben, damit aus einem klagenden „Entweder-oder“ eine echte verzwickte „Wie kann es sein, dass wir… und gleichzeitig…?“-Frage wird.

Konkrete Fragestellungen im Scrum-Kontext:
– Teamprozess & Qualität: „Wie können wir konsequent unsere Definition of Done einhalten und gleichzeitig jedes Sprintziel termingerecht liefern?“ – Diese Wicked Question kann in einer Retrospektive diskutiert werden, um den Spannungsbogen zwischen Qualität und Geschwindigkeit sichtbar zu machen und beide Aspekte künftig auszubalancieren.
– Produktstrategie: „Wie können wir die Wünsche unseres wichtigsten Kunden erfüllen und gleichzeitig unserer Produktvision treu bleiben?“ – Im Backlog Refinement oder Sprint Review mit Stakeholdern hilft diese Frage, den Spagat zwischen individuellem Kundenwunsch und langfristiger Vision offen zu thematisieren, sodass das Team eine Strategie für beide Prioritäten entwickelt.
– Teamkultur: „Wie können wir als Team autonom entscheiden und gleichzeitig die Vorgaben der Organisation einhalten?“ – Diese Frage könnte in einem Team-Workshop oder einer Retro gestellt werden, um die Balance zwischen Selbstorganisation und Unternehmensrichtlinien auszuloten.

Mögliche Themen oder Anwendungsfälle für Scrum-Teams: Wicked Questions eignen sich immer dann, wenn ein Scrum-Team vor Zielkonflikten steht oder mit Dilemmata ringt. Typische Anwendungsfälle: Priorisierungskonflikte (Qualität vs. Geschwindigkeit, Innovation vs. Standardisierung), Rollen- oder Erwartungskonflikte (z. B. Kundenanforderungen vs. technischer Schuldenabbau), Veränderungsprozesse(Teams sollen kreativ sein und gleichzeitig compliant arbeiten) oder generell in Change-Initiativen, wo widersprüchliche Forderungen an das Team gestellt werden. Durch das Aussprechen der Widersprüche fördert man ein gemeinsames Verständnis dafür, dass beide Seiten wichtig sind – was zu integralen Lösungenführen kann, anstatt dass das Pendel zwischen Extremen hin- und herschwingt[27][34]. Dies stabilisiert langfristig Prozesse und Entscheidungen, da das Team bewusster abwägt.

Tipps für die Durchführung:
– Positive Grundhaltung: Formuliere die Widersprüche möglichst wertschätzend für beide Seiten („Wie kann es sein, dass wir X und Y gleichzeitig tun?“). So bleibt die Diskussion konstruktiv und keine Seite fühlt sich abgewertet[35].
– Keine Schuldzuweisung: Achte darauf, dass Wicked Questions nicht zu „Warum können die da obenerwarten, dass…?“ degenerieren. Solche Fragen umformulieren, damit sie die Gruppe selbst betreffen und lösungsneutral bleiben.
– Kreative Spannung nutzen: Weise das Team darauf hin, dass die entdeckten Spannungen etwas Positives haben – sie können kreative Energie freisetzen. Dadurch entsteht oft mehr Freiheit und Verantwortung bei der Lösungsfindung[36][37].
– Nachhaltig weiterverfolgen: Eine Wicked Question allein löst das Problem noch nicht. Plant z. B. im Anschluss einen Follow-up (wie Min Specs oder Ecocycle Planning), um Strategien zu entwickeln, die beiden Polen gerecht werden. So vermeidet ihr, nach dem Workshop einfach zum Alltag zurückzukehren, ohne die spannenden Widersprüche anzugehen.

5. Appreciative Interviews (Wertschätzende Interviews)

Kurzbeschreibung: Appreciative Interviews (AI) richten den Blick auf positive Erfahrungen und Erfolge, um daraus die Ursachen des Gelingens abzuleiten[38]. In Paarinterviews erzählen die Beteiligten einander von Höhepunkten – Zeiten, in denen etwas besonders gut lief – und erforschen gemeinsam, was diese Erfolge ermöglicht hat. So identifiziert das Team seine Stärken und Erfolgsfaktoren. Anstatt Probleme zu analysieren, wird auf dem aufgebaut, „was gut funktioniert“. Das schafft eine optimistische Atmosphäre und motiviert, mehr von diesen Erfolgsbedingungen herzustellen. In weniger als einer Stunde kann so jede Gruppengröße wertvolle Erkenntnisse gewinnen, warum Dinge gelingen[38].

Ablauf (Zeitplan):

Moderationsanweisungen: Bitte die Teilnehmer, konkrete Geschichten statt allgemeiner Aussagen zu teilen. Die Interviewer sollen mit offenen Fragen das Erlebte erforschen: Was fühlten/bemerkten die Beteiligten? Wer war beteiligt? Was hat den Unterschied gemacht? Halte die Stimmung wertschätzend – negative Aspekte haben in den Geschichten keinen Platz, es geht um die Wurzeln des Erfolgs. Falls jemand ins Jammern gerät, lenke zurück: „Was lief gut in deinem Beispiel?“ Achte außerdem auf die Zeit – gib ein Signal zum Rollenwechsel nach der Hälfte. In der Gruppenphase moderierst du so, dass alle positiven Muster herausgearbeitet werden. Schreibe häufig genannte Erfolgsfaktoren sichtbar mit, um sie im Abschluss sichtbar zu haben. Frage in der Abschlussdiskussion gezielt: „Wie können wir diese Faktoren institutionalieren oder häufiger ermöglichen?“, damit die Gruppe konkrete nächste Schritte ableitet (z. B. „Mehr Pair-Programming, weil Zusammenarbeit in den Erfolgsgeschichten entscheidend war“).

Konkrete Fragenstellungen im Scrum-Kontext:
– Sprint Retrospektive (Celebrate Success): „Worauf bist du im letzten Sprint besonders stolz, und was hat dazu geführt?“ – Statt nur Probleme zu wälzen, fokussiert sich das Team auf einen Erfolg im Sprint und lernt daraus, was es beibehalten oder ausbauen sollte.
– Produktentwicklung / Innovation: „Erzähl von einem Feature, das unsere Nutzer begeistert hat – was haben wir dafür richtig gemacht?“ – In einer Review-ähnlichen Runde oder einem Produkt-Workshop tauschen PO, Entwickler und ggf. Kunden Erfolgsgeschichten aus, um Erfolgsrezepte für künftige Features abzuleiten.
– Team-Building: „Wann hast du dich im Team zuletzt richtig unterstützt und wertgeschätzt gefühlt? Was war da anders?“ – Als Teamentwicklungseinheit können solche Interviews helfen, positive Teamdynamiken bewusst zu machen und gezielt zu stärken.

Mögliche Themen oder Anwendungsfälle für Scrum-Teams: Appreciative Interviews sind immer dann hilfreich, wenn ein Team droht, sich zu sehr auf Probleme zu fokussieren oder neue Energie braucht. Typische Einsatzfelder: Retrospektiven, um nach mehreren schwierigen Sprints wieder positive Geschichten in Erinnerung zu rufen; Kickoff-Workshops, um zu Beginn die Stärken des Teams zu identifizieren; Projektabschlüsse (Post Mortems), um aus Erfolgen zu lernen, nicht nur aus Fehlern. Auch bei Organisationsentwicklungen oder Visionserarbeitung kann man mit positiven Kernmomenten starten („Wann haben wir unseren Wert wirklich geliefert?“). Das Team erkennt durch AI die gemeinsamen Erfolgsfaktoren und kann darauf aufbauen, anstatt nur Lücken zu analysieren.

Tipps für die Durchführung:
– Tiefe statt Breite: Lieber lässt du wenige, aber echte Geschichten erzählen, als in der Kürze der Zeit viele oberflächliche. Die Emotionalität einer persönlichen Erfolgserzählung wirkt oft stärker nach als abstrakte Punkte.
– Aktives Zuhören betonen: Trainiere ggf. kurz, was aktives Zuhören heißt (nicht unterbrechen, nachfragen, paraphrasieren). Das Interview ist kein Verhör, sondern ein gemeinsames Entdecken der positiven Kerne.
– Positive Sprache fördern: Falls Teilnehmer in der Erzählung abgleiten in „…und dann ging aber xy schief“, frage nach: „Was hat trotz der Umstände geholfen, dass es dennoch erfolgreich war?“ Halte den Fokus konsequent auf dem Positiven, ohne negatives Erlebtes zu bewerten.
– Ergebnisse sichern: Die identifizierten Erfolgsfaktoren sollten dokumentiert und zugänglich gemacht werden (z. B. als Plakat im Teamraum mit „Das macht uns erfolgreich“). So erinnert sich das Team im Alltag an seine Stärken und kann bewusst mehr davon tun.

6. TRIZ

Kurzbeschreibung: Die Liberating Structure TRIZ lädt Teams zur „kreativen Zerstörung“ ein, um Platz für Innovation zu schaffen[39]. In einem dreistufigen Prozess überlegt die Gruppe zunächst radikal, was man tun müsste, um sein Ziel garantiert zu verfehlen – also das schlimmste denkbare Ergebnis zu erzielen. Anschließend reflektieren die Teilnehmer ehrlich, was davon man tatsächlich schon tut[40]. Zum Schluss werden konkrete Schritte vereinbart, um diese kontraproduktiven Aktivitäten zu stoppen[40]. TRIZ macht es möglich, unausgesprochene Tabus oder „heilige Kühe“ humorvoll zu schlachten und so all die Dinge zu identifizieren, die Innovation und Erfolg im Weg stehen[39]. Durch dieses „auf den Kopf stellen“ entsteht oft Erleichterung und Raum, um eingefahrene Muster gemeinsam zu beseitigen – ein kathartischer Prozess, der sogar Spaß machen kann[41].

Ablauf (Zeitplan):

Moderationsanweisungen: Erkläre TRIZ vorab, damit die Teilnehmer den Sinn verstehen – betone, dass es um umgekehrtes Denken geht und zunächst durchaus gelacht werden darf. Gib kein zu frühes “Spoiler”: Teile den Prozess in klare Runden und verrate in Runde 1 noch nicht, dass später die Brücke zur Realität geschlagen wird (das fördert radikalere Ideen)[42]. In Runde 1 animiere zu übertriebenem Denken: je extremer die Vorschläge, desto besser. Erlaube keine „Lösungen“ oder neuen Ideen in Runde 1 – es geht nurdarum, Blödsinn und kontraproduktive Dinge zu sammeln[39][41]. In Runde 2 ist brutale Ehrlichkeit gefragt: Schaffe ein Klima, in dem sich niemand rechtfertigen muss, sondern alle offen zugeben dürfen, wo es hakt. Wenn Verlegenheit entsteht („tun wir das wirklich?“), erinnere daran, dass viele Teams solche Aha-Momente haben. In Runde 3 fokussiere streng auf Stopp-Aktionen – keine neuen To-Dos hinzufügen, sondern tatsächlich weglassen/auflösen. Halte ggf. nach, wer was abstellen wird. Es kann hilfreich sein, am Ende nochmal auf die ursprüngliche Zielsetzung hinzuweisen – so sieht das Team, wieviel Ballast es gerade identifiziert hat, den es loswerden kann.

Konkrete Fragestellungen im Scrum-Kontext:
– Sprint-Retrospektive: „Was müssten wir tun, um unseren nächsten Sprint garantiert völlig scheitern zu lassen?“ – Diese TRIZ-Frage eignet sich hervorragend in Retros, um alle kontraproduktiven Verhaltensweisen offenzulegen, über die man sonst ungern spricht. Die Ergebnisse liefern meist sofort Ansatzpunkte, was das Team aufhören sollte zu tun[43].
– Start einer Scrum-Einführung: „Was sollten wir tun, um die Einführung von Scrum in unserer Organisation komplett gegen die Wand zu fahren?“ – Zu Beginn einer Transition genutzt, hilft TRIZ, typische Fehlverhalten (z. B. Mikromanagement, fehlende Unterstützung, alte Gewohnheiten) sichtbar zu machen. Das Team erkennt früh, welche Anti-Patterns es vermeiden muss[44].
– Qualität & Done: „Was könnten wir tun, um das un-doneste, miserabelste Increment überhaupt abzuliefern?“ – Diese provokante Frage (fokussiert auf die Definition of Done) kann z. B. in einem Quality-Workshop gestellt werden. Sie führt dem Team vor Augen, welche Schlampigkeiten und Kurzschlüsse zu schlechter Qualität führen – und welche davon evtl. tatsächlich passieren[45]. Anschließend lassen sich Maßnahmen definieren, um Qualitätshürden einzuhalten (z. B. „Stoppen wir das Mergen ohne Code-Review“).

Mögliche Themen oder Anwendungsfälle für Scrum-Teams: TRIZ ist ein Universalwerkzeug, um kontinuierliche Verbesserung durch Weglassen statt Hinzufügen zu erreichen[41]. Typische Anwendungsfälle: In Retrospektiven (Teamverhalten, Zusammenarbeit mit dem Product Owner, technische Praktiken – was müssen wir einstellen, um besser zu werden?), bei Prozess-Reviews (Meetings, Artefakte – welche Gewohnheiten sabotieren uns?), zur Risikoanalyse (präventiv Worst-Case-Szenarien durchspielen, z. B. vor Release: „Was würde unser Release ruinieren?“). Auch in Management-Workshops oder produktstrategischen Runden kann TRIZ genutzt werden, um Platz für Neues zu schaffen – z. B. indem man sich fragt, welche Projekte/Initiativen gestoppt werden müssen, um Ressourcen für Innovation freizulegen[39]. Immer wenn Teams das Gefühl haben „wir haben schon so viel versucht, aber nichts ändert sich“, kann TRIZ die perspektivwechselnde Initialzündung sein.

Tipps für die Durchführung:
– Ernsthaft Spaß haben: Vermittle eine Haltung von „wilder Ernsthaftigkeit“. Der Prozess darf humorvoll sein (Lachen löst Spannungen[46]), aber die Gruppe soll die Erkenntnisse am Ende ernst nehmen.
– Keine Scheu vor Tabus: Ermuntere ausdrücklich, auch heikle Punkte aufs Tableau zu bringen („Wir müssten unseren Kunden konsequent anlügen!“). Oft kommen so Dinge hoch, die bisher niemand aussprach – genau das ist gewollt (Unaussprechliches aussprechen)[47].
– Konkrete Stopps definieren: Achte darauf, dass in Runde 3 nicht nur vage Wünsche („wir sollten vorsichtiger sein“) stehen, sondern klare Aktionen: WAS wird WER ab sofort unterlassen? Möglichst in „Wir werden aufhören zu ___“ formulieren.
– Nachhalten: TRIZ wirkt am besten, wenn das Team die Stopp-Liste nachverfolgt. Hängt sie sichtbar aus. Der Scrum Master kann in kommenden Daily Scrums oder Retros nachfragen: „Haben wir X wirklich sein lassen?“. Dieser soziale Druck unterstützt die Verhaltensänderung.

7. 15% Solutions (15%-Lösungen)

Kurzbeschreibung: 15% Solutions ermutigt jedes Teammitglied, sofort umsetzbare Schritte zu identifizieren, die im Rahmen seiner eigenen Einflussmöglichkeiten liegen. Die Grundidee: Niemand ist zu 0 % handlungsfähig – es gibt immer zumindest 15 %, die man ohne zusätzliche Ressourcen oder Erlaubnis sofort tun kann, um voranzukommen. In dieser Struktur denkt jeder kurz über kleine Lösungen nach, die er beitragen kann, und teilt diese dann mit anderen. Das führt zu einem Schwarm an praktischen Mini-Maßnahmen, die gemeinsam einen großen Effekt haben können. Die Atmosphäre ist dabei lösungsorientiert und ermächtigend: Statt auf Hindernisse zu schauen, fokussiert man auf das Machbare im Hier und Jetzt.

Ablauf (Zeitplan):

Moderationsanweisungen: Definiere klar den Fokus oder das Problem, zu dem 15%-Lösungen gesucht werden (z. B. „Wie können wir die Codequalität verbessern?“ oder „Was kannst du tun, um die Meetings effizienter zu machen?“). Erkläre das Konzept der „15 %“: Es geht um Ideen, die jetzt und im eigenen Handlungsspielraum liegen – nicht um perfekte Großlösungen. Während der individuellen Phase: absolute Stille, damit jeder nachdenken kann. In den Gruppenphasen achte darauf, dass keiner die Idee eines anderen bewertet oder ausredet (auch keine „Ja, aber…“). Jede Lösung, so klein sie scheint, wird positiv aufgenommen. Als Moderator kannst du in der Abschlussrunde betonen, wie viele kleine Schritte zusammen kommen – das zeigt dem Team: jeder kann beitragen. Bei Bedarf frage: „Wobei braucht jemand Hilfe?“ – vielleicht können sich so Tandems finden, die gemeinsam eine 15%-Idee angehen.

Konkrete Aufgabenstellungen im Scrum-Kontext:
– Sprint-Retrospektive (Abschluss): „Welche 15%-Lösung wirst du ab morgen umsetzen, um unsere Arbeitsweise zu verbessern?“ – Am Ende einer Retro notiert jedes Teammitglied eine kleine persönliche Aktion (z. B. „Ich werde täglich die Definition of Done bei meinen Tasks checken.“). Diese werden im Team geteilt, sodass jeder einen konkreten Mini-Action-Item hat.
– Backlog Refinement: „Was kannst du tun, um das nächste Refinement effektiver zu gestalten?“ – Das Entwicklerteam überlegt individuelle Beiträge (z. B. „Ich lese die User Story vorab und notiere Fragen“). Geteilte Verantwortung entsteht, ohne dass es offiziell im Plan stehen muss.
– Team-Kultur: „Welche kleine Sache kannst du beitragen, damit unsere Zusammenarbeit noch besser läuft?“ – In einem Team-Health-Check-Workshop kann jeder eine Selbstverpflichtung formulieren (z. B. „Ich gebe künftig schneller Feedback, statt zu warten“). Solche persönlichen Commitments stärken die Eigenverantwortung.

Mögliche Themen oder Anwendungsfälle für Scrum-Teams: 15% Solutions passt in jedes Setting, wo es um ins Tun kommen geht. Häufig als Abschluss einer Retrospektive genutzt, damit nicht nur große, sondern auch sofortige Verbesserungen entstehen. Auch in Workshops (z. B. Definition-of-Done-Verbesserung: „Was kannst du ab sofort ändern, um Qualität zu heben?“) oder Planungen („Was kann jeder beitragen, damit der Sprint ein Erfolg wird?“). Es fördert eine Kultur der Eigeninitiative und verhindert die Haltung „ich kann ja nichts ändern“. Im Kontext mehrerer Teams (etwa bei Scrum-of-Scrums oder Communities) kann jeder Vertreter 15% Solutions präsentieren, um voneinander zu lernen, was im eigenen Einfluss steht. Kurz: Immer wenn Prokrastination oder Abhängigkeiten drohen, erinnert 15% Solutions daran, dass man jetzt gleich handeln kann.

Tipps für die Durchführung:
– Hilfefrage parat haben: Manche tun sich schwer, etwas zu finden. Hilf mit Fragen wie: „Was könntest du sofort ausprobieren, ohne jemanden um Erlaubnis zu fragen?“ oder „Stell dir vor, du fängst Montag damit an – was wäre das?“.
– Kultur der Machbarkeit: Betone, dass auch kleinste Schritte zählen – z. B. „einen Kollegen um Feedback bitten“ ist valide. Dadurch senkst du die Hürde, dass jeder etwas findet.
– Keine falsche Bescheidenheit: Wenn jemand sagt „Mein Einfluss ist gleich Null“, erinnere daran, dass jederin seinem Bereich Experimente starten kann. Oft ist das Mindset die Barriere. 15% Solutions sollen genau diese Barriere durchbrechen und Selbstwirksamkeit erlebbar machen.
– Nachfassen: Frage in der nächsten Retrospektive oder Daily: „Wer hat seine 15%-Idee umgesetzt und was ist passiert?“. Der Erfahrungsaustausch darüber kann weitere Motivation bringen und zeigt Accountability.

8. Troika Consulting (Troika-Beratung)

Kurzbeschreibung: Troika Consulting ermöglicht schnelles, kollegiales Coaching in Kleingruppen. Drei Personen tun sich zusammen; reihum schlüpft jeweils eine in die Rolle des „Klienten“ und schildert den anderen beiden ein persönliches Anliegen oder Problem. Die beiden Berater beraten anschließend offen miteinander, während der Klient zuhört. Dieses Format schafft in kurzer Zeit einen vertrauensvollen Raum, in dem jeder Teilnehmer zu seinem Thema kreative Ratschläge und neue Perspektiven erhält – und zugleich von der Beraterrolle bei den Anliegen der Kollegen lernt. Troika ist effektiv, um individuelle Probleme im Team zu lösen, ohne externe Coaches, da die Weisheit und Erfahrung innerhalb des Teams genutzt wird.

Ablauf (Zeitplan):

(Gesamtdauer pro Troika ca. 3×7 Minuten = ~21 Minuten. Evtl. 1–2 Minuten Puffer zwischen Runden einplanen.)

Moderationsanweisungen: Unterteile klar in Rollen und erkläre diese: Der Klient muss offen und konkret sein, darf aber nicht zu lange ausholen. Die Berater sollen aktiv zuhören und zuerst nur klärende Fragenstellen – keine Ratschläge in Phase 1. Betone die Bedeutung des „Silent Listening“: der Klient schweigt während der Beratungsphase komplett. Als Moderator achte auf die Zeit und signalisiere den Wechsel (z. B. Glocke: von Schildern zu Beratung, dann wieder zurück). Ermutige die Berater, in ihrer Beratung ruhig kreativ zu spinnen und verschiedene Ideen durchzudenken – der Klient hört ja zu und kann sich das Nützlichste herauspicken. Versichere dem Klienten, dass es normal ist, ungewohnte Ideen zu hören; er muss nichts sofort kommentieren. Nach jeder Runde lobe kurz, dass der Klient nun konkrete Impulse hat, und bitte zum Rollenwechsel. Bei sensiblen Themen: stelle sicher, dass Vertraulichkeit gilt – was in der Troika besprochen wird, bleibt in dieser Kleingruppe.

Konkrete Anwendungsfälle im Scrum-Kontext:
– Sprint-Retrospektive: Jedes Teammitglied bringt ein persönliches Hindernis oder Anliegen aus dem letzten Sprint ein (z. B. „Ich komme mit der Testautomatisierung nicht weiter“ oder „Ich hadere mit unserer Meetingkultur“). In Troikas beraten die Kollegen sich gegenseitig und finden Lösungen oder zumindest neue Sichtweisen. So erhält jeder in der Retro individuelles Feedback.
– Produkt-Backlog Refinement (PO Coaching): Der Product Owner könnte in einer Troika mit zwei Entwicklern als Beratern ein Thema durchdenken, z. B. „Wie priorisiere ich technische Schulden vs. Features besser?“. Gleichzeitig könnte eine andere Troika zwei POs aus anderen Teams als Berater einbeziehen (Cross-Team). Diese Beratung im kleinen Rahmen kann dem PO helfen, bessere Entscheidungen zu treffen.
– Scrum Master Circle: Treffen sich mehrere Scrum Master (z. B. aus verschiedenen Teams) können sie Troikas bilden, um sich gegenseitig zu coachen (Themen wie „Team zieht Retrospektiven ins Lächerliche, was tun?“). Auf diese Weise nutzt die Community interne Expertise statt externer Beratung.

Mögliche Themen oder Anwendungsfälle für Scrum-Teams: Troika Consulting ist ein Allround-Tool für Peer-Coaching. Besonders wertvoll in Retrospektiven: Nicht nur allgemeine Teamthemen besprechen, sondern jedem Raum geben für seine individuellen Herausforderungen (Konflikte, Unsicherheiten, technische Fragen). Im Daily Scrum (wenn genügend Zeit/respektive in einem verlängerten Daily) könnten adhoc-Troikas gebildet werden, wenn ein Entwickler feststeckt – so kriegt er schnelle Hilfe ohne das ganze Daily zu dominieren. In Sprint Reviews könnte Troika unkonventionell eingesetzt werden, indem z. B. zwei Stakeholder dem Team Feedback als „Berater“ geben, während das Team als „Klient“ zuhört (etwas abwandeln nötig). Auch für zwischenmenschliche Themen (z. B. Zusammenarbeit mit einer schwierigen externen Partei) ist Troika sinnvoll. Generell überall, wo ein Teammitglied oder eine Rolle im Scrum-Team einen konkreten Rat benötigt und die Weisheit der Kollegen nutzen möchte[48][49].

Tipps für die Durchführung:
– Zusammensetzung der Troikas: Wenn möglich, mische Personen mit unterschiedlichen Blickwinkeln. In cross-funktionalen Teams ist das gegeben. Zur Not können auch Vierergruppen gebildet werden (dann zwei Berater gleichzeitig reden oder abwechselnd).
– Vertrauen aufbauen: Zu Beginn betonen, dass das Gesagte vertraulich bleibt und dass es okay ist, auch Unwissen oder Schwächen zuzugeben – wir helfen uns gegenseitig. Wenn nötig, selbst ein Beispiel-Problem nennen, damit andere sich öffnen.
– Zeit strikt einhalten: Der Beratungsdialog (Phase 2) neigt zum Überziehen, weil die Berater viel zu sagen haben. Schneide sanft ab, sonst fehlt die Zeit, dass jeder drankommt. Lieber knackig beraten als ewig diskutieren.
– Klient-Schweigen üben: Viele finden es anfangs schwer, nicht einzuhaken. Erinnere die Klienten freundlich daran, einfach zuzuhören wie „eine Fliege an der Wand“. Vielleicht metaphorisch: „Jetzt lausche mal deinem eigenen Beratungsgespräch von außen.“

9. What, So What, Now What? (W³ / „Was? – Und? – Jetzt?“)

Kurzbeschreibung: What, So What, Now What ist eine dreistufige Reflexionsstruktur, die hilft, Erfahrungen systematisch auszuwerten[50]. Zuerst wird sachlich gesammelt: Was ist passiert oder was beobachten wir? Dann wird analysiert: So what – was bedeutet das, welche Schlüsse ziehen wir daraus? Schließlich folgen Aktionen: Now what – was machen wir jetzt daraus? Diese Methode (angelehnt an die „Ladder of Inference“) eignet sich ideal, um in Retrospektiven oder anderen Debriefings Klarheit zu schaffen[51]. Sie führt zu einem geteilten Verständnis der Fakten, einer gemeinsamen Sinngebung und konkreten nächsten Schritten. Durch die klar getrennten Phasen verhindert W³ vorschnelles Urteilen und sorgt dafür, dass Lernen aus Erlebtemstrukturiert abläuft.

Ablauf (Zeitplan):

Moderationsanweisungen: Trenne die drei Phasen strikt – kündige z. B. klar an „Jetzt sammeln wir erstmal nur Fakten (Phase 1)!“ und interveniere, wenn jemand in dieser Phase schon bewertet („Das war schlecht…“ – dann stoppend korrigieren: „Halte dich erstmal an die Fakten, was ist passiert?“). Notiere die Beiträge gut sichtbar, z. B. auf drei Flipcharts spaltenweise für What/So What/Now What. In Phase 2 stelle vertiefende Fragen: „Warum ist das ein Thema? Was folgt daraus?“. Achte darauf, dass alle zu Wort kommen – die Struktur selbst ermuntert zwar Beteiligung, aber frage gezielt nach unterschiedlichen Perspektiven, insbesondere bei „So What“ (Entwickler, PO, Stakeholder könnten unterschiedliche Bedeutungen sehen). In Phase 3 steuere auf konkrete Aktionen hin: Fordere bei vagen Vorschlägen Nachdetails („Wer macht das bis wann?“). Binde die Erkenntnisse aus Phase 2 ein: „Angesichts dessen, was wir gelernt haben – was genautun wir?“ Stelle sicher, dass am Ende Verantwortlichkeiten klar sind. Wenn die Zeit knapp wird, priorisiere ggf. die Maßnahmen nach Impact. Hervorheben: Es ist okay, wenn eine Erkenntnis zu keiner Aktion führt außer „im Auge behalten“ – nicht alles muss sofort geändert werden.

Konkrete Anwendungsfälle im Scrum-Kontext:
– Sprint Retrospektive: W³ kann als komplette Retro-Agenda dienen: Das Team rekapituliert erst Was im letzten Sprint geschah (Daten, Ereignisse), diskutiert dann So What – warum das relevant war (z. B. welche Auswirkungen positive oder negative Ereignisse hatten) – und entscheidet Now What, also die Verbesserungsaktionen für den nächsten Sprint. Diese Struktur ist tatsächlich eine perfekte Retro-Methodeund wird von vielen Scrum-Teams so eingesetzt[52].
– Review-Nachbereitung: Direkt nach einem Sprint Review könnte das Team intern W³ nutzen: Was wurde im Review gesagt oder gezeigt? So What – was bedeutet das Feedback für uns (Prioritäten, Zufriedenheit der Stakeholder)? Now What – was nehmen wir uns vor (z. B. bestimmte Anforderungen umstellen, Kommunikation verbessern etc.)?
– After-Action-Review: Nach einem ungewöhnlichen Ereignis (z. B. Prod-Ausfall, Kundenbeschwerde, gescheiterter Sprint) kann man in einem speziellen Meeting via W³ das Ereignis aufarbeiten – ähnlich einer Mini-Retrospektive, aber fokussiert auf den Vorfall.

Mögliche Themen oder Anwendungsfälle für Scrum-Teams: Überall dort, wo Erfahrungen reflektiertwerden sollen, hilft W³ als roter Faden. Neben Sprint- oder Release-Retrospektiven eignet es sich für Workshops nach Meilensteinen („Was ist im letzten Quartal passiert? Was bedeutet das für unser Product Roadmap? Was tun wir als Nächstes?“), für Team-Health-Checks („Was beobachten wir in unserer Teamkultur? Was heißt das? Was wollen wir ändern?“) oder Lessons Learned nach Projekten. Auch außerhalb reiner Scrum-Ereignisse: z. B. nach einem Kunden-Meeting gemeinsam analysieren, nach einem Experiment / Spike auswerten etc. Die Stärke von W³ liegt darin, dass es Chaos in Klarheit verwandelt und Leute ermutigt, laut über Bedeutung und Konsequenzen nachzudenken, statt nur Ereignisse abzuhaken[53][52]. Gerade in agilen Umfeldern, wo empirisches Vorgehen wichtig ist, wird mit W³ aus Erfahrung wirklich gelernt.

Tipps für die Durchführung:
– Visualisieren: Nutze Dreispalten-Templates (physisch oder virtuell), damit alle sehen, in welcher Phase man ist und was schon gesammelt wurde. Das verhindert Wiederholungen und Disziplinverstöße (wenn jemand in Spalte 1 was wertet, kannst du darauf hinweisen).
– Neutral moderieren: In „What“ selber keine Wertungen reinbringen. Falls ein Beitrag wertend kommt („Der Build war eine Katastrophe“), frage nach der Tatsache dahinter („Was heißt ‚Katastrophe‘? War er rot? Wie lange?“).
– Die Leitfragen gut übersetzen: Ggf. formuliere auf Deutsch sichtbar: „Was haben wir beobachtet? – Und was bedeutet das? – Und was machen wir nun?“ damit alle die englischen Begriffe korrekt verstehen.
– Flexibel im Ablauf: Bei sehr komplexen Themen kann man die Gruppen erst in kleinere Teams aufteilen, die je What/SoWhat/NowWhat durchlaufen, dann im Plenum konsolidieren. Oder Phase 1 im Plenum, Phase 2 in Gruppen, Phase 3 wieder gemeinsam. Passe es der Gruppengröße an, damit jeder beitragen kann. Wichtig ist nur, die Reihenfolge strikt zu halten.

10. Discovery & Action Dialogue (DAD)

Kurzbeschreibung: Das Discovery & Action Dialogue (DAD) ist eine strukturierte Gesprächsabfolge, mit der Gruppen lokale Lösungen für hartnäckige Probleme entdecken und entfesseln können[54]. Anstatt externen Expertenrat zu suchen, hilft DAD dabei, die bereits vorhandene Weisheit innerhalb der Gruppe sichtbar zu machen – insbesondere durch das Identifizieren von „Positive Deviants“ (Leute, die das Problem schon erfolgreich umgangen haben). In einer moderierten Runde beantworten die Teilnehmer nacheinander sieben Schlüsselfragen, die vom Verständnis des Problems über vorhandene erfolgreiche Ansätze bis hin zu konkreten Maßnahmen reichen[54]. Damit wird die Kluft zwischen Erkenntnis und Aktion geschlossen: Das Team versteht gemeinsam besser, was wirklich los ist, was andere bereits an Lösungen tun und wie man diese Lösungen verbreiten kann. DAD ist ideal, um chronische Probleme anzugehen, bei denen es nicht an Wissen mangelt, sondern an Umsetzung.

Ablauf (Zeitplan):

Die Kernelemente von DAD sind sieben Fragen, die nacheinander im Plenum oder in Gruppen behandelt werden. Ein Moderator stellt jeweils die Frage und lässt Raum zur Diskussion. (Bei großer Gruppe ggf. erst Kleingruppen diskutieren lassen, dann einsammeln.)

1. Woran erkennen wir das Problem? – „Wie merkt ihr, wann oder woran das Problem X auftritt?“ (Ziel: gemeinsames Verständnis der Symptome und Situation schaffen – alle schildern Beobachtungen.)
2. Wer macht es schon besser? – „Kennt jemand Situationen/Personen/Teams, die X trotzdem guthinbekommen? Was machen diese anders?“ (Hier werden vorhandene Ausnahmen/Erfolgsfällegesammelt, um von ihnen zu lernen.)
3. Wie trägst du selbst dazu bei? – „Was machst du persönlich vielleicht, das das Problem (unbeabsichtigt) mitverursacht oder aufrechterhält?“ (Ehrliche Selbstreflexion: Verantwortung erkennen.)
4. Was hindert uns? – „Was hält uns davon ab, es so zu machen wie die Erfolgsbeispiele? Warum tun wir das noch nicht längst?“ (Barrieren und Gründe identifizieren, die Adoption guter Praktiken verhindern.)
5. Ideen sammeln: – „Was würde helfen, diese Hürden zu überwinden? Wie könnten wir mehr so handeln wie die, bei denen es klappt?“ (Brainstorming von Lösungsideen, angelehnt an die positiven Abweichler.)
6. Wer muss dabei sein? – „Wer (welche Rolle/Person) muss unbedingt eingebunden werden, damit wir X lösen können?“ (Identifizieren von Stakeholdern oder Mitstreitern, die Einfluss haben.)
7. Nächste Schritte: – „Was werden wir konkret tun, um morgen anzufangen, das Problem anzugehen? Was ist der erste Schritt?“ (Konkretisierung der Action Steps und Verantwortlichkeiten.)

(Zeit pro Frage ca. 5–7 Minuten, insgesamt 40–60 Minuten je nach Tiefe.)

Moderationsanweisungen: Erkläre eingangs das Ziel: Lokale Lösungen finden und voneinander lernen. Als Moderator stelle jede Frage nacheinander und achte darauf, dass wirklich alle sieben durchlaufen werden (nicht vorschnell bei einer hängenbleiben). Bei sensiblen Punkten (Frage 3: eigene Beiträge zum Problem) hilf mit einer sicheren Atmosphäre: kein Blaming, sondern wir alle haben unseren Anteil. Bohre nach positiven Abweichungen (Frage 2): Falls niemandem was einfällt, frag nach kleinen Erfolgen („Gab es irgendwann mal weniger von X? Was war da anders?“). Halte bei Frage 4 die Gruppe davon ab, wieder in alte Denkmuster zu verfallen („geht nicht weil…“) – hier sollen die Hemmschuhe identifiziert werden, aber ohne sich darin auszuruhen. In Frage 5 und 7 sorge für Konkretheit: Aus Ideen müssen machbare Experimente oder Handlungen formuliert werden. Visualisiere alle Antworten mit, z. B. auf Flipchart-Spalten pro Frage. So sieht man am Ende einen „roten Faden“. Wichtig: Lass die Gruppe viel selbst sprechen, aber steuere, dass alle Fragen durchkommen. Fasse zwischendurch zusammen, z. B. nach Frage 2: „Also es ist möglich, das Problem zu umgehen – wir haben Beispiele gefunden. Jetzt Frage 3…“.

Konkrete Anwendungsfälle im Scrum-Kontext:
– Wiederkehrende Impediments in Retrospektiven: Wenn ein Team in mehreren Retrospektiven immer wieder dasselbe Problem beklagt (z. B. „fehlende Code Reviews“ oder „unrealistische Schätzungen“), kann ein DAD-Workshop eingelegt werden. Das Team durchleuchtet dann dieses hartnäckige Problem mit den 7 Fragen, um endlich Ansätze zu finden, es zu lösen.
– Team-übergreifende Probleme: Angenommen, in einem Skalierungs-Setup haben mehrere Teams das Problem „Knowledge Silos – Wissen wird nicht geteilt“. Ein Moderator kann mit Vertretern aller Teams ein Discovery & Action Dialogue durchführen, um herauszufinden, wer es irgendwo schon besser macht (vielleicht teilt Team A Wissen via Wiki), warum andere das nicht tun, etc., und dann für alle Teams Maßnahmen abzuleiten.
– Verbesserung der Definition of Done: Ist die DoD oft nicht erfüllt oder unklar, könnte man DAD fragen: „Woran merken wir, dass die DoD nicht lebt?“, „Wer hat es schon geschafft, immer Done zu liefern?“, „Was hindert uns daran, deren Vorgehen zu übernehmen?“ usw. Daraus entstehen sicher pragmatische Ideen, z. B. DoD beim Planning immer prüfen, die von innen kommen.

Mögliche Themen oder Anwendungsfälle für Scrum-Teams: DAD eignet sich speziell für chronische, komplexe Herausforderungen, bei denen es nicht „die eine“ Lösung gibt, sondern viele kleine Hemmnisse. Beispiele: Testautomation klemmt, Team hat Angst vor offenem Feedback, Stakeholder-Einbindung funktioniert nicht, Cross-Team-Kollaboration stockt, “Technical Debt” wächst, etc. Oft kennt irgendwer schon funktionierende Ansätze – DAD holt diese ans Licht (Lernen von den Besten im eigenen Umfeld). Auch in Agile Transition Teams kann DAD genutzt werden: z. B. „Wie schaffen wir es, dass Manager weniger micromanagen?“ – wer macht es schon anders, was hindert uns, was tun wir selbst falsch, etc. DAD passt überall, wo kollektives Lernen gefragt ist und die Gruppe selbst Teil der Lösung sein muss, anstatt Berater von außen zu holen[54]. Es fördert Eigenverantwortung und gemeinsames Problemlösen auf Basis vorhandener Stärken.

Tipps für die Durchführung:
– Evtl. anonym starten: Bei Frage 3 (eigener Anteil) kann es hilfreich sein, alle schreiben still für sich auf, wie sie beitragen, und werfen Zettel in die Mitte – Moderator liest anonymisiert vor. So traut sich jeder eher, ehrlich zu sein.
– Auf Erfolg aufbauen: Halte die Stimmung optimistisch – Frage 2 ist der Schlüssel, um zu sehen: Es gibtbereits Lösungen. Vermeide, dass das Gespräch in Negativschleifen (Jammern) gerät, indem du immer wieder auf entdeckte positive Abweichungen verweist: „Wenn Klaus das geschafft hat, können wir das doch auch lernen!“.
– In Kombination verwenden: Man kann DAD mit anderen LS kombinieren, z. B. vorgelagert ein Impromptu Networking, um alle warmzumachen zum Thema, oder nachgelagert 15% Solutions, damit jeder noch einen persönlichen Mini-Schritt festlegt.
– Als Moderator neutral bleiben: Gerade bei DAD, wo es um Probleme im Team geht, ist es wichtig, dass du nicht deine eigene Meinung zu früh einbringst. Leite durch Fragen. Falls du als Scrum Master selbst Teil des Systems bist, reflektiere vorher deinen Beitrag (Frage 3), damit du authentisch moderieren kannst, ohne defensiv zu werden, falls dein Anteil benannt wird.

11. Shift & Share

Kurzbeschreibung: Shift & Share ist eine Struktur, die Wissenstransfer und Ideenaustausch in großer Gruppe effizient gestaltet. Es funktioniert wie eine Messe oder Stationenlauf: Mehrere Gastgeber (z. B. Teammitglieder) präsentieren an „Stationen“ parallel eine Idee, Erkenntnis oder einen Prototyp, während die übrigen Teilnehmer in kleinen Grüppchen von Station zu Station wandern („shiften“)[55]. So kann in kurzer Zeit jeder Teilnehmer mit allen präsentierten Inhalten in Kontakt kommen und in kleinen Runden ins Gespräch mit den Gastgebern kommen. Shift & Share belebt Meetings, da sich alle bewegen und interagieren, und es fördert Breitenbeteiligung: Jeder Gastgeber bekommt intensives Feedback in kleinen Dosen und jeder Besucher kann Fragen stellen oder kommentieren. Typischerweise eignen sich 3–6 Stationen mit jeweils 5–10-minütigen Runden.

Ablauf (Zeitplan):

Moderationsanweisungen: Wähle die Gastgeber/Themen im Voraus aus – im Scrum-Kontext könnten z. B. Entwickler ihre jeweils gelösten kniffligen Probleme vorstellen, oder jedes Teammitglied präsentiert ein User Story Ergebnis im Review etc. Bereite den Raum so vor, dass Stationen klar erkennbar sind (nummeriert). Zeitslots klar definieren: z. B. 8 Minuten pro Station, dann Glocke/Lautruf für Wechsel. Brief die Gastgeber: Sie sollen ihre Präsentation kurz und interaktiv halten, nicht 8 Minuten Monolog. Lieber 3 Minuten Input, dann auf Fragen eingehen. Besuchergruppen sollten eine gleichmäßige Größe haben – ggf. als Moderator anfangs einteilen („Zählt 1-2-3-4 durch… alle 1er starten bei Station A“). Bei ungleich verteilten Besuchern helfe nach, damit keine Station leer bleibt. Ermutige die Besucher, aktiv Fragen zu stellen und nicht schüchtern zu sein – die kleine Gruppengröße hilft dabei. Achte beim Wechsel darauf, dass es flott geht; kündige evtl. 1 Minute vorher an „Bitte in 1 Min abschließen und bereit machen zum Wechsel“. Im Abschluss gib jedem Gastgeber das Wort, aber knapp („Nenne einen coolen Tipp, den du bekommen hast.“) – so bekommt die Gesamtgruppe nochmal eine Zusammenfassung und evtl. Motivation, bilateral Details nachzubesprechen.

Konkrete Anwendungsfälle im Scrum-Kontext:
– Sprint Review als „Science Fair“: Statt frontaler Präsentation kann ein Sprint Review als Shift & Share gestaltet werden. Jedes Team (bei mehreren Teams) oder jedes Feature wird an einem Tisch gezeigt, Stakeholder wandern herum nach Interesse. So entsteht mehr Dialog mit Stakeholdern, sie können Fragen direkt an Entwickler stellen. Das skaliert gut, wenn viele Beteiligte da sind.
– Retrospektive mit mehreren Fokusthemen: Falls ein Team in der Retro mehrere Arbeitsgruppen gebildet hat (z. B. zu „Testing“, „Collaboration“, „DevOps“), können am Ende die Gruppen ihre Ergebnisse via Stationen den anderen vorstellen. So vermeidet man lange Präsentationen im Plenum, jeder kann sich nacheinander die Erkenntnisse abholen.
– Wissensaustausch im Team: Regelmäßig kann ein Scrum-Team ein internes „Tech Share“ machen, wo z. B. drei Entwickler an drei Stationen je einen neuen Trick/Tool zeigen (z. B. CI-Setup, neues Library-Feature) und die Kollegen rotieren. Dies ist spannend und effizient, da jeder in kurzer Zeit viel lernt.
– Multi-Team Event (Community of Practice): Bei größeren Runden (z. B. Scrum-of-Scrums oder Dojo-Sessions) kann Shift & Share genutzt werden, damit Teams einander ihre Best Practices vorstellen – jeder Stand repräsentiert ein Team und teilt seine Erfahrungen zu einem Thema (z. B. „So machen wir Refinement“).

Mögliche Themen oder Anwendungsfälle für Scrum-Teams: Immer wenn mehrere Inhalte parallelvermittelt oder diskutiert werden sollen, glänzt Shift & Share. Es fördert Interaktivität in Meetings mit sonst passivem Publikum. Beispiele: Produktideen-Pitches (PO stellt mehrere neue Feature-Ideen an versch. Stationen vor, Team gibt Feedback), Architektur-Reviews (versch. Architekturalternativen an Stationen diskutieren), Risiko-Workshops (jedes Risiko-Szenario an Station brainstormen lassen), Abteilungs-Review(wenn mehrere Teams ihre Ergebnisse vorstellen, rotiert das Management durch Stationen). Auch in Trainings oder Open Spaces kann man damit Zeitslots parallelisieren. Für Scrum Master: in Retros mit übergreifenden Themen (z. B. Retro mit mehreren Teams gemeinsam) kann Shift & Share eingesetzt werden, damit Teams voneinander lernen. Kurzum, es eignet sich perfekt, um viele Gespräche gleichzeitigin Gang zu setzen, anstatt sequentiell zu präsentieren.

Tipps für die Durchführung:
– Gastgeber vorbereiten: Ermutige die Station-Gastgeber, vielleicht etwas Visuelles parat zu haben (Demo, Poster, Folien auf Laptop). Eine attraktive Station zieht die Besucher an.
– Geräuschpegel managen: Viele gleichzeitige Gespräche können laut werden. Wähle den Raum groß genug oder die Stationen weit genug auseinander. Bei >4 Stationen evtl. in getrennte Räume aufteilen, mit gutem Timing.
– Zeitpolster einplanen: Die erste Rotation braucht manchmal 1–2 Minuten länger, bis alle geschnallt haben, wie es geht. Plane lieber leicht kürzere Präsentationszeiten und lass minimal Puffer für Übergänge.
– Plenumsauswertung optional: Wenn es viele Stationen gab, erspare dem Plenum jede Zusammenfassung – oft reicht es, dass jeder seins gehört hat. Alternativ könnte man ein gemeinsames Dokumentieren organisieren (z. B. jeder Besucher schreibt eine Idee, die er an Station X mitnahm, auf ein Board), um gemeinsames Lernen zu sichern.

12. 25/10 Crowdsourcing

Kurzbeschreibung: 25/10 Crowdsourcing ist ein dynamisches Verfahren, um eine große Anzahl von Ideenin kurzer Zeit zu sammeln und gemeinsam zu priorisieren[56]. Jeder Teilnehmer schreibt zunächst anonym eine kühne oder neuartige Idee auf eine Karte. Dann folgt ein strukturiertes Bewertungs-Pingpong: Die Karten werden zufällig herumgereicht und in mehreren Runden von jeweils anderen Personen gelesen und mit Punkten (1–5) bewertet. Am Ende werden die Punktzahlen aufaddiert – die bestbewerteten („25 von 25 Punkte“) Ideen kristallisieren sich so heraus, ohne langwieriges Diskutieren. Es ist ein spielerischer Wettbewerb der Ideen, der oft überraschende, kollektiv favorisierte Vorschläge zutage fördert. (Der Name 25/10 kommt daher, dass idealerweise 5 Runden mit maximal 5 Punkten = 25 Punkte möglich sind, und Top-Ideen etwa 20+ Punkte erreichen.)

Ablauf (Zeitplan):

Moderationsanweisungen: Bereite die Fragestellung klar vor und präsentiere sie deutlich (Flipchart/Beamer), damit alle beim Ideenformulieren den gleichen Fokus haben. Ermutige zu kühnen Ideen („Denkt groß!“). Für das Austauschen der Karten: Lass die Leute ruhig aufstehen und umhergehen – Bewegung lockert die Stimmung. Achte aber darauf, dass auch wirklich mehrfach durchgemischt wird (nicht immer mit dem gleichen Nachbarn tauschen). Gib in jeder Runde ein Signal („Tauscht jetzt die Karten… okay, lesen & bewerten… nächste Runde!“). Anonymität ist wichtig: Niemand soll sich für seine Idee oder Bewertung rechtfertigen müssen, daher kein Name auf Karten. Beim Auswerten hilft es, die Karten laut vorzulesen und die Punktzahl zu verkünden. Lobe den kreativen Beitrag aller, besonders die Top-Scorer. Visualisiere die Rangfolge – ggf. mit einem schönen Fanfaren-Sound für Platz 1 😉. In der Nachbesprechung richte den Blick auf Umsetzung: „Welche der Top-Ideen wollen wir angehen? Wer macht den ersten Schritt?“. Und: Bewahre die Karten auf oder dokumentiere sie, da auch nicht-Top-Ideen wertvolle Anregungen enthalten können.

Konkrete Anwendungsfälle im Scrum-Kontext:
– Sprint Retrospektive (Verbesserungsfindung): Frage: „Welche mutige Veränderung würde unsere Arbeitsweise dramatisch verbessern?“ – Jeder schreibt eine Retro-Action-Idee. Dann 25/10 Bewertung. Das Team sieht, welche Verbesserungsmaßnahme kollektiv am meisten Unterstützung hat und kann diese umsetzen.
– Product Discovery / Strategie-Workshop: Frage: „Welche Produktidee würde unseren Kunden maximalbegeistern?“ – Alle Stakeholder generieren Features oder Veränderungen, bewerten sie. Die höchstbewertete Idee könnte ins Product Backlog ganz nach oben wandern, da sie breite Zustimmung hat.
– PI-Planning (Scaled Scrum): Bei großen Planungs-Events könnten Dutzende von Feature-Vorschlägen durch 25/10 priorisiert werden, um schnell ein Gefühl zu bekommen, was viele für wertvoll halten.
– Backlog Refinement (Story-Ideen): Das Team könnte 25/10 nutzen, um aus einer Flut von Story-Vorschlägen jene herauszufiltern, die am vielversprechendsten sind.
– Teamwerte erarbeiten: Auch abstrakter: „Welcher Wert ist uns im Team am wichtigsten?“ – jeder schreibt einen Wert, Bewertung – so sieht man Top-Prioritäten.

Mögliche Themen oder Anwendungsfälle für Scrum-Teams: 25/10 eignet sich besonders, wenn viele Ideen in kurzer Zeit generiert und ausgewählt werden sollen. Das ist oft in Workshops der Fall: z. B. Brainstorming von Produktvision-Elementen, Sammeln von Risiko-Minderungsmaßnahmen, Generieren von Teamnamen oder Motto, Ideen für Hackathon-Projekte, etc. Es verbindet die Kreativphase und Entscheidungsphase nahtlos, was Zeit spart. In Scrum-Events speziell: Retrospektiven (umzusetzenste Verbesserung identifizieren), Reviews (beste Kunden-Feedback-Ideen auswählen), Planning (Top-Prioritäten sichtbar machen). Es hat auch einen spielerischen Charakter (Leute sind oft neugierig: „Wer hat meine Idee wie bewertet?“ – bleibt aber anonym). So fördert es die Energie und Beteiligung auch in sonst drögen Priorisierungsrunden.

Tipps für die Durchführung:
– Gerade Teilnehmerzahl fördert den Kartentausch, aber notfalls kann eine Person in einer Runde aussetzen oder der Moderator springt ein. Wichtig ist, dass kein Teilnehmer seine eigene Karte in einer Runde bewertet.
– Bewertungsverständnis klären: Was bedeutet 1 vs. 5? Hier kann man sagen: 5 = „Wow, das sollten wir unbedingt machen!“, 1 = „Naja, eher nicht so wirkungsvoll.“ Damit alle ungefähr gleich bewerten.
– Bewegung einbauen: Lass Leute zwischen den Runden aufstehen und jemanden suchen, den sie noch nicht kennen oder am anderen Ende des Raums. Das erhöht die Zufälligkeit und bringt Leute ins Gespräch (man darf auch kurz lachen über Ideen, aber Bewertungen bleiben individuell).
– Feier die Ergebnisse: Die Top-Ideen sollen sichtbar gefeiert werden – z. B. applaudiert oder der Ideengeber (falls er sich outen will) gewürdigt. Das motiviert zur Umsetzung. Ggf. kann man der Spitzenidee einen lustigen Titel geben („Moonshot des Monats“ o. ä.), um positive Erinnerung zu schaffen.

13. Wise Crowds (Kluge Menge)

Kurzbeschreibung: Wise Crowds ist eine Beratungsstruktur, mit der eine Person vor einer größeren Gruppe qualifizierten Rat für ihr Anliegen erhält. Ähnlich wie bei Troika Consulting stellt hier ein „Klient“ sein Problem vor, aber die Beratung erfolgt durch eine ganze Gruppe (typisch 4–7 Personen bilden ein Beraterpanel), während alle anderen als Beobachter dienen. Das Format erinnert an eine Podiumsdiskussion: Der Klient schildert sein Problem, das Beraterpanel stellt klärende Fragen und diskutiert dann mögliche Lösungen, als säße der Klient nicht dabei – doch er hört zu. Abschließend teilt der Klient, was hilfreich war. Wise Crowds ermöglicht es, die kollektive Intelligenz einer größeren Gruppe zu nutzen, um komplexe Herausforderungen zu adressieren, und macht das Lernen öffentlich: Auch die Beobachter ziehen Lehren aus dem Austausch. Es ist geeignet, wenn man ein wichtiges Thema hat, das für viele relevant ist, und es sich lohnt, es im Plenum zu behandeln.

Ablauf (Zeitplan):

Moderationsanweisungen: Weise die Rollen klar zu und erkläre ihre Haltung: Berater geben ihr Bestes, Zuhörer (Publikum) sind still. Achte streng auf die Zeit pro Phase; besonders die Beratungsdiskussion neigt zum Ausschweifen – kündige ggf. „noch 1 Minute“ an. Stelle sicher, dass in Phase 3 wirklich Fragen gestellt werden und keine vorzeitigen Ratschläge („Hast du schon X probiert?“ – das ist okay, aber besser in Phase 4). Während der Beratung (Phase 4) greife nicht ein, außer das Panel verliert völlig den Fokus. Erinnere Berater daran, miteinander zu reden, nicht nur reihum Statements abzugeben – Dialog ist erwünscht. Der Klient muss diszipliniert schweigen in dieser Zeit; falls er impulsiv reagieren will, freundlich per Handzeichen ermahnen. Für die Beobachter: Sie dürfen weder in Phase 3 noch 4 eingreifen – allenfalls könnten sie später als nächste Berater dran sein. Nach Ende kannst du die Beobachter fragen, was sie gelernt haben, damit auch ihr Erkenntnisgewinn reflektiert wird. Doch primär steht der Klient im Fokus. Wähle idealerweise ein Thema von allgemeinem Interesse als Fall, dann profitieren alle. Falls niemand spontan Klient sein will, kann der Scrum Master auch selbst ein typisches Teamhindernis einbringen.

Konkrete Anwendungsfälle im Scrum-Kontext:
– Scrum of Scrums / Community: Ein Scrum Master hat ein kniffliges Problem mit seinem Team (z. B. „Team XYZ kommt nie ins Gespräch mit Stakeholdern“). In einer Scrum Master Community of Practice stellt er es als Klient vor, andere SMs bilden das Panel und beraten. Alle hören zu und lernen – typischer Cross-Team Wissensaustausch.
– Sprint Retrospektive (Teamweite Beratung): Hat ein einzelnes Teammitglied oder eine Rolle (PO, Dev, Tester) ein besonderes Anliegen, kann man innerhalb der Retro eine Wise Crowds Session machen. Beispiel: Der Product Owner schildert seine Herausforderung „Ich bekomme nicht genug Feedback von Kunden“ und bittet das Dev-Team um Rat. Das Team diskutiert (Panel) und PO hört zu – so entstehen gemeinsames Verständnis und Lösungen.
– Projekt-Review / Management-Runde: Ein Team oder Teamvertreter als Klient beschreibt z. B. ein Hindernis auf Organisationsebene („Wir haben technische Schulden, die wir so nicht abbauen können“). Ein Panel aus anderen Teamleads/Architekten berät aus ihrer Erfahrung, während Management zuhört. So fließen Ideen zusammen.

Mögliche Themen oder Anwendungsfälle für Scrum-Teams: Wise Crowds ist besonders wertvoll bei komplexen Problemen, wo verschiedene Perspektiven helfen. Es kann im eigenen Team genutzt werden (Team berät Teammitglied) oder teamübergreifend (Gruppe berät Einzelteam). Typische Scrum-Themen: Teamdynamik, technische Herausforderungen, Anforderungen priorisieren, Konflikte mit Stakeholdern, etc. Die Struktur ist gut geeignet, um externe Beratung ins Team zu holen, z. B.: Das Team lädt einen Fachexperten ins Panel ein, um ein Problem zu diskutieren, das der PO hat. Oder umgekehrt: Das Team berät im Sprint Review einen Stakeholder, der unsicher ist (z. B. Nutzer erzählt Problem, Team brainstormt Lösungen). Auch in Trainings kann Wise Crowds genutzt werden: Teilnehmer bringen eigene Fälle ein, der Rest berät – hohes Commitment, hoher Lerneffekt. Immer dort, wo man merkt, einer ringt mit etwas und „im Raum steckt die Lösung“, kann Wise Crowds eine tolle, transparente Beratungsform sein.

Tipps für die Durchführung:
– Geeignete Fälle wählen: Nicht jedes Thema passt – trivialen Problemen fehlt es an Diskussionsstoff, zu heikle Themen (zwischenmenschliche Konflikte) will man evtl. nicht vor großem Publikum ausbreiten. Wähle Fälle mit genügend Relevanz und offenem Ausgang.
– Panelgröße anpassen: Zu groß und es reden einige gar nicht; zu klein und es fehlt evtl. Input. Mit 4–5 Beratern klappt es meist gut. Wenn viele etwas beisteuern könnten, rotierendes Panel erwägen (aber Achtung auf Zeit).
– “Fishbowl”-Setting nutzen: Man kann Wise Crowds auch in einem offenen Fishbowl machen, wo zusätzliche Beobachter auf freien Stuhl kommen dürfen, um kurz mitzuberaten. Das wird aber komplexer. Klassisch ist besser: Panel fix, Rest lauscht.
– Nachbesprechung für Beobachter: Damit alle profitieren, frage am Ende: „Welchen Rat fandet ihr besonders interessant – auch für euch selbst?“. So denkt das ganze Team darüber nach, was man aus dem Fall gelernt hat.
– Danke sagen: Würdige den Mut des Klienten, sein Problem zu teilen, und danke dem Panel. Das fördert Vertrauen, damit beim nächsten Mal wieder jemand sich öffnet.

14. Min Specs (Minimale Spezifikationen)

Kurzbeschreibung: Min Specs hilft einer Gruppe, einfache Grundregeln für den Erfolg zu definieren, indem alles Überflüssige weggelassen wird. Es geht darum, aus einer anfänglich längeren Liste von möglichen Regeln, Anforderungen oder Prinzipien jene Minimalmenge an „Muss“ und „Muss-nicht“ herauszufiltern, die auf keinen Fall verletzt werden dürfen, um ein Ziel zu erreichen[57][58]. Das können bspw. Teamregeln, Kriterien oder Verfahrensweisen sein. Durch das radikale Reduzieren („Was können wir weglassen und würden trotzdem erfolgreich sein?“) eliminiert man unnötige Komplexität und schafft einen klaren, verbindlichen Rahmen – ähnlich den wenigen wichtigen Leitplanken, innerhalb derer ansonsten freie Innovation stattfinden kann[59]. Häufig genügen 2–5 solcher „Min Specs“, um eine Gruppe sowohl zu fokussieren als auch ihr Freiheit zu lassen[60].

Ablauf (Zeitplan):

Moderationsanweisungen: Erkläre das Konzept mit einem Beispiel: Max Specs = alle möglichen Regeln; Min Specs = kleinste nötige Untermenge[59]. Damit alle verstehen, dass es nicht um „mehr Regeln“ geht, sondern um Entschlacken. In Schritt 1 lieber freies Brainstorming zulassen – Leute neigen zunächst zu vielen Vorschriften. Das ist okay, diese werden ja danach hinterfragt. Halte Schritt 3 fokussiert: Geh Punkt für Punktdurch die Liste und stelle die Killerfrage: „Könnten wir erfolgreich sein, wenn wir gegen diese Regel verstoßen?“. Hier muss die Gruppe ehrlich sein. Falls jemand zögert, diskutiere kurz, aber entscheide eher großzügig im Sinne von Streichen – nur wirklich unverzichtbare sollen stehenbleiben[61]. Moderator sollte neutral bleiben; das Team entscheidet, was essentiell ist. Achte darauf, dass Min Specs knapp und konkretformuliert werden (keine langen Sätze). Wenn sich herausstellt, dass viele ähnliche Punkte im Kern auf eines hinauslaufen, formuliere diesen Kern als Min Spec. Beispiel: aus „Agenda haben“, „Ziel klären“, „Zeitbox“ könnte die Min Spec werden: „Ein Meeting muss ein klares Ziel haben“ (die anderen wären dann nice-to-have). Frage beim Überprüfen: „Würden wir sofort Probleme kriegen, wenn wir diese Regel nicht befolgen?“Wenn nein -> raus. Visualisierung: Streiche Punkte einfach durch oder markiere sie farblich, das verdeutlicht den Reduktionsprozess. Die entstehende kurze Liste kann man rahmen. Wichtig: Mach deutlich, dass diese Min Specs jetzt verbindlich sind – weil es ja so wenige sind, gibt’s keine Ausreden. Mache Min Specs eventuell spaßig, indem du sagst „Alles andere ist erlaubt, solange diese wenigen Regeln befolgt werden!“.

Konkrete Anwendungsfälle im Scrum-Kontext:
– Definition of Done / Ready: Perfektes Einsatzgebiet! Ein Team hat evtl. eine lange DoD-Liste – Min Specs hilft zu fragen: Welche Kriterien sind absolut unentbehrlich, damit etwas „Done“ ist? Vielleicht bleiben nur 3–5 wirklich kritische Punkte übrig (z. B. „alle Akzeptanztests grün“, „Code Review durchgeführt“, „in Prod-ähnlicher Umgebung getestet“). Das schafft Klarheit und streicht Nice-to-haves raus[62][63]. Ebenso DoR (Definition of Ready) – was muss ein Backlog Item mindestens erfüllen, bevor wir es in Sprint nehmen?[64]
– Team Working Agreement: Anfangs definieren Teams oft Dutzende Regeln („Wir kommen pünktlich“, „Wir schätzen Fibonacci“, etc.). Mit Min Specs kann man daraus ein paar Grundprinzipien extrahieren, die das Team wirklich ausmachen. Z. B. „Wir begegnen einander immer respektvoll“ könnte als einziger Muss-Wert bleiben, der vieles abdeckt.
– Sicherheitsregeln / Compliance: In Bereichen mit vielen Vorschriften (z. B. Medizintechnik, Finanzen) kann das Team mit Min Specs herausarbeiten: Welche wenigen Vorschriften dürfen wir nie verletzen? Das hilft, den Fokus zu halten, ohne im Regelwust unterzugehen.
– Prozessoptimierung: Wenn ein Scrum-Team eigene Prozesse entwirft (z. B. eine Definition of Ready für Backlog Items, oder einen Testprozess), können sie mit Min Specs die minimal nötigen Schritte definieren und unnötige Bürokratie weglassen[65][66].
– Meetings: Wie oben im Beispiel: Ein Team könnte Min Specs für alle internen Meetings festlegen, damit die effektiv sind (z. B. „Muss ein klares Ziel haben“ und „Muss enden mit nächsten Schritten“ – reicht vielleicht schon).
– Produkt-Launch-Kriterien: Was sind die minimalen Go/No-Go-Kriterien, um ein Release freizugeben? Team + PO könnten mit Min Specs die 2–3 unbedingten Qualitätskriterien bestimmen (z. B. „Keine Showstopper-Bugs im Bugtracker“, etc.).

Mögliche Themen oder Anwendungsfälle für Scrum-Teams: Überall dort, wo das Team oder die Organisation Regeln, Prinzipien oder Kriterien definieren muss, bringt Min Specs Klarheit. Es fördert Empowerment: Wenn nur wenige klare Grenzen existieren, kann innerhalb dieser frei agiert werden[58]. Beispiele: Qualitätsstandards, Architekturprinzipien (z. B. 3 Min Specs definieren wie „Keine Geheimnisse im Code – dokumentiere komplexe Stellen“), Strategieprinzipien („Unsere Produktstrategie muss…“), sogar Unternehmenswerte (Min Specs als gelebte Kernwerte). In Retros könnte man es einsetzen, um aus vielen Verbesserungsideen die eine unverzichtbare Maßnahme zu extrahieren (wobei dafür TRIZ/1-2-4-All oft genutzt werden). Generell ist Min Specs eine Art „Pareto-Optimierung“ von Regeln: 20% der Regeln, die 80% des Erfolgs sichern[67]. Scrum selbst hat ja implizit Min Specs: wenige Regeln, damit Teams flexibel bleiben – dieses Mindset kann mit Min Specs auch auf Team-Ebene angewandt werden.

Tipps für die Durchführung:
– Auf Passung achten: Nicht jedes Thema eignet sich – bei kreativen Prozessen will man nicht zu restriktiv sein. Aber wo Klarheit fehlt oder zu viel Ballast da ist, ist es top.
– Gemeinsame Definition von Erfolg klären: Alle müssen dasselbe Ziel vor Augen haben, sonst streichen sie nach falschen Kriterien. Zu Beginn fragen: „Was heißt überhaupt Erfolg in unserem Kontext?“ (z. B. DoD = Increment releasable ohne weitere Arbeit).
– Nicht zu knauserig: Min Specs heißt nicht „so wenig wie möglich machen“, sondern „so wenig Regeln wie nötig“. Also ruhig streng sein: jede gestrichene unnötige Regel gibt Freiheit und Verantwortung zurück[66].
– Visualisiere den Prozess: Die Leute lieben es, Punkte zu streichen – macht das gemeinsam auf Flipchart. Das hat was Befreiendes („Wir dürfen also X weglassen!“).
– Beispiel zum Verständnis: Gern ein metaphorisches Beispiel vorab: „Min Specs für gesund bleiben: 1) Schlaf genug, 2) trink genug Wasser, 3) beweg dich täglich. Alles andere (Vitamine, Gym, etc.) ist nice-to-have.“ – So verstehen alle die Logik.
– Follow-Up prüfen: Später mal reflektieren (z. B. in Retro): Haben uns diese Min Specs gereicht? Fehlt was oder ist was unnötig? Sie sind nicht in Stein gemeißelt, man kann sie bei Bedarf anpassen.

15. Improv Prototyping (Improvisations-Prototyping)

Kurzbeschreibung: Improv Prototyping ermöglicht es Teams, Ideen spielerisch auszuprobieren, indem sie sie vorspielen statt nur darüber zu reden[68]. Es ist quasi eine „Probe für’s echte Leben“[68]: Die Teilnehmer schlüpfen in Rollen und stellen in kurzen Improvisationsszenen dar, wie eine neue Lösung, ein Prozess oder Verhalten aussehen würde. Dadurch können sie in sicherer Umgebung experimentieren und erhalten sofort Feedback durch das Erleben. Diese Methode eignet sich, um abstrakte Konzepte greifbar zu machen oder komplexe Abläufe schnell zu testen, ohne gleich real implementieren zu müssen. Es baut Hemmungen ab, fördert Kreativität und gemeinsames Lernen – man „spielt sich in eine neue Denkweise hinein“. Eine Aufgabe, die zunächst groß und daunting erscheint, wird in kleine Spielszenen gebrochen und so zugänglich gemacht.

Ablauf (Zeitplan):

Moderationsanweisungen: Schaffe eine lockere, sichere Atmosphäre – viele sind ungewohnt beim Rollenspiel. Betone, es geht nicht um Schauspielkunst, sondern darum, eine Idee lebendig zu testen. Freiwilligkeit vor Zwang: Frag wer Lust hat mitzuspielen; falls zu wenige, kannst du notfalls selbst mitmachen oder einfach Rollen minimal halten. Gib den Spielern einen klaren Rahmen: Setting, Ziel („zeigt uns, wie das Meeting mit Regel X abliefe“), aber kein detailliertes Skript. Impro lebt von Spontaneität, also ermutige: „Es gibt kein falsch – alles, was passiert, ist Input zum Lernen!“. Zeit begrenzen: Sonst verzetteln sich Szenen. Sag z. B. „max 3 Minuten“. Im Zweifel Szene proaktiv beenden, wenn Hauptpunkte durch sind. In der Reflexion sorge dafür, dass Feedback respektvoll bleibt – zuerst Positives („Was war hilfreich?“), dann „Was könnten wir verbessern?“. Wenn nötig, auch konkrete Fachfragen klären (z. B. „Ist das realistisch? Wie würdest du als Kunde reagieren?“). Ermuntere zum Iterieren: „Wollen wir’s noch mal anders probieren?“. Achte aber auf Gruppenenergie – nicht überstrapazieren, wenn Unlust aufkommt. Lieber das Gelernte zusammenfassen und schließen. Finde die Balance zwischen Spaß und Fokus: Lachen ist okay (gewünscht sogar), aber leite es immer zurück zum Lerneffekt („Wir hatten Spaß – und was nehmen wir mit?“). Bei remote Teams kann man auch improvisieren, z. B. in Breakouts oder mit Webcam-Off-the-cuff-Sketches; ggf. schwieriger, aber möglich.

Konkrete Anwendungsfälle im Scrum-Kontext:
– Verhaltensänderungen in Retrospektive: Team möchte Daily Scrums verbessern – statt nur darüber zu reden, spielt man mal ein Daily mit den neuen Regeln (z. B. ohne dreifrageformat, oder in anderer Reihenfolge). Anschließend kann jeder sagen, wie es war. So spürt das Team die Änderung direkt und kann entscheiden, ob sie im echten Daily ausprobiert werden soll.
– Stakeholder-Gespräche üben: Wenn z. B. ein Entwickler bald einen schwierigen Call mit einem Kunden hat, kann das Team Improv Prototyping machen: einer spielt den Kunden, einer den Entwickler, und man improvisiert das Gespräch. So erkennt der echte Entwickler mögliche Stolpersteine und bekommt Tipps von Kollegen im Nachgang.
– Feature-Idee durchspielen: PO hat eine Idee für ein neues Feature – Teammitglieder spielen einen Nutzer, der das Feature nutzt, und ein anderer den Support, etc. Daraus merkt man evtl., was an der User Story noch unklar ist oder wo UX-Probleme liegen. (Quasi eine improvisierte Nutzertest-Simulation.)
– Teamkonflikte ansprechen: Bei Spannungen im Team könnte man z. B. in einem geschützten Rahmen eine typische Konfliktszene improvisieren (Namen ggf. ändern), um gemeinsam drüber zu lachen und dann Lösungen zu finden, wie man es anders machen könnte. (Vorsicht: nur wenn genug Vertrauen vorhanden ist, sonst kann das nach hinten losgehen.)
– Schulung/Workshops: Scrum Master können Improv nutzen, um z. B. den Unterschied zwischen Mikro-Management und Selbstorganisation zu demonstrieren – Teilnehmer spielen Manager vs. Team in zwei Varianten. Lernen durch Erleben! Oder in einer Retrospektive Variation: „Spielt mal wie unser Daily aussehen würde, wenn wir es völlig falsch machen“ (Humor) – dann „wie sollte es ideal aussehen?“, das liefert Erkenntnisse.

Mögliche Themen oder Anwendungsfälle für Scrum-Teams: Improv Prototyping passt immer dann, wenn das Team Neues ausprobieren will, aber unsicher ist, oder wenn dröge Regeländerungen mal kreativ angegangen werden sollen. Es kann Teil eines Design Thinking Prozesses sein (Szenarios nachspielen), für UX (Customer Journey nachstellen), Organisationsänderungen (z. B. neue Meeting-Struktur erst simulieren), Notfallübungen (z. B. Incident Response in IT – mal durchspielen). In Retrospektiven bringt es Abwechslung, wenn Routine einkehrt. Teams mit vielen Kinästheten oder praktisch Veranlagten profitieren, weil sie Dinge tun statt nur reden. Und es fördert Empathie: In Rollen schlüpfen (z. B. Entwickler spielt mal den frustrierten User) kann Aha-Erlebnisse auslösen. Agile Prinzipien von Experiment und Feedback werden hier direkt angewandt: Impro-Szene = Experiment, Feedback-Schleife = Retrospektive im Kleinen. So kann das Team im geschützten Raum scheitern und lernen, bevor es echt wird.

Tipps für die Durchführung:
– Einfache Requisiten nutzen: Ein Whiteboardmarker als Mikrofon, Post-its als Handy, Stühle als Auto… das macht es oft lustiger und greifbarer. Braucht keine Vorbereitung, alles vor Ort ist Requisite.
– Nicht alle müssen mitspielen: Zuschauende profitieren auch. Zwinge introvertierte nicht auf die „Bühne“, aber oft trauen sich mehr als gedacht, wenn’s locker ist.
– Aufzeichnen? Wenn passend, kann man eine Szene aufnehmen (Handyvideo) und später analysieren – aber Vorsicht, kann Leute hemmen. Nur wenn Team offen dafür ist.
– Humor nutzen: Ermuntere auch zu überzeichnetem Spiel – das darf ruhig klischeehaft sein. Im Humor liegt oft Wahrheit: „Extrem-“Darstellungen eines Problems entlarven es. Danach wieder Ernsthaftigkeit reinholen: „Spaß beiseite, was sagt uns das?“
– Achte auf Zeit: Lieber mehrere kurze Sketche als eine epische Impro, die die Gruppe ermüdet. Halte das Tempo hoch – Impro soll energetisieren, nicht ausufern.
– Debrief nicht vergessen: Der wahre Wert liegt im gemeinsamen Drüber-Reden nach dem Spiel. Stelle sicher, dass am Ende jedem klar ist, was wir gelernt haben und ob/wie wir das real anwenden wollen.

(Die restlichen Strukturen 16–33 folgen in gleicher detaillierter Form.)

[1] [2] [3] [4] [5] [6] [7] 1-2-4-All – Liberating Structures

https://liberatingstructures.de/liberating-structures-menue/1-2-4-all/

[8] [9] [10] [11] [12] [13] [14] [15] [55] Impromptu Networking – Liberating Structures

https://liberatingstructures.de/liberating-structures-menue/impromptu-networking/

[16] [17] [18] [19] [21] [22] [23] Nine Whys – Liberating Structures

https://liberatingstructures.de/liberating-structures-menue/nine-whys/

[20] Nine Whys noch mal beleuchtet – Liberating Structures

https://liberatingstructures.de/nine-whys-noch-mal-beleuchtet/

[24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] Wicked Questions – Liberating Structures

https://liberatingstructures.de/liberating-structures-menue/wicked-questions/

[38] Discovering and Building on the Root Causes of Success with …

https://medium.com/the-liberators/use-appreciative-interviews-to-reveal-conditions-for-successful-scrum-fd82e20fce03

[39] [40] [46] [47] TRIZ – Liberating Structures

https://liberatingstructures.de/liberating-structures-menue/triz/

[41] [42] [43] [44] [45] Stop Counterproductive Activities with TRIZ | Scrum.org

https://www.scrum.org/resources/blog/stop-counterproductive-activities-triz

[48] 8. Troika Consulting – Liberating Structures

https://www.liberatingstructures.com/8-troika-consulting/

[49] Helping Heuristics — Liberating Structures Fieldnotes

https://www.ripplet.org/liberating-structures/helping-heuristics

[50] [51] [52] [53] Use “What, So What, Now What” During The Sprint Retrospective | Scrum.org

https://www.scrum.org/resources/blog/use-what-so-what-now-what-during-sprint-retrospective

[54] Discover and Unleash Local Solutions to Chronic Problems with …

https://medium.com/the-liberators/discover-and-unleash-local-solutions-to-chronic-problems-with-discovery-action-dialogue-d33fa3fc760d

[56] Engage Everyone Simultaneously in Generating Questions, Ideas …

https://medium.com/the-liberators/use-1-2-4-all-to-tap-into-the-collective-brainpower-of-a-group-of-any-size-6cf60ac7a818

[57] [65] [66] Liberating Structures Sprint Planning in Scrum – Hands-on Agile

https://age-of-product.com/liberating-structures-sprint-planning/

[58] [59] [60] [61] [67] Min Specs – Liberating Structures

https://liberatingstructures.de/liberating-structures-menue/min-specs/

[62] [63] Take Your Scrum Team’s Definition Of Done To The Next Level! | by Zombie Scrum Resistance | The Liberators | Medium

https://medium.com/the-liberators/take-your-scrum-teams-definition-of-done-to-the-next-level-7108e129eb2d

[64] Liberating Structures – Min Specs for Definition of Ready

https://agilereflections.dk/2019/01/29/liberating-structures-min-specs-for-definition-of-ready/

[68] Improv Prototyping – Liberating Structures

https://liberatingstructures.de/liberating-structures-menue/improv-prototyping/