Offenheit oder psycholigische Sicherheit?

Um die Offenheit innerhalb einer Retrospektive zu fördern, wird gerne das sogenannte „Las Vegas-Prinzip“ angewendet. Es bedeutet das Versprechen, dass Aussagen aus der Retrospektive nicht nach außen weitergetragen werden. Dies kann aber dann problematisch sein, wenn die Verbesserungen die Mitarbeit von Managern oder anderen Teams benötigt. Und, was sagt eigentlich der Scrum-Gude dazu?

🔹1. Offizielle Grundlage: Was sagt der Scrum Guide?

Der Scrum Guide (2020) beschreibt die Sprint Retrospective folgendermaßen:

„The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.“
„The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done.“
„The Scrum Team identifies the most helpful changes to improve its effectiveness.“
„The most impactful improvements are addressed as soon as possible.“

👉 Wichtig:
Der Scrum Guide sagt nicht explizit, dass die Inhalte oder Ergebnisse „im Team bleiben“ müssen.
Das sogenannte „Las Vegas-Prinzip“ („What happens in Vegas stays in Vegas“) taucht nicht im Scrum Guide oder anderen offiziellen Scrum-Quellen (Scrum.org, Scrum Alliance) auf.

Es handelt sich also um eine verbreitete Praxis oder Interpretation aus der Scrum-Community, nicht um eine offizielle Regel.

---

🔹2. Ursprung des „Las Vegas-Prinzips“

Das Prinzip stammt aus der Idee, dass die Retrospektive ein sicherer Raum für Offenheit und Ehrlichkeit sein soll.
Es wird in der agilen Szene häufig als Ergänzung oder kulturelle Richtlinie verwendet, um Vertrauen zu fördern:

„Was in der Retro besprochen wird, bleibt in der Retro“
— außer vereinbarte Verbesserungen, die umgesetzt werden.

📘 Diese Haltung wird oft von Scrum-Trainern und Coaches (z. B. aus der Agile Alliance oder bei Liberating Structures) empfohlen, um psychologische Sicherheit zu schaffen — ist aber keine offizielle Scrum-Regel.

---

🔹3. Warum das problematisch sein kann

Das vollständige „Abschotten“ der Retrospektive kann zu mehreren Problemen führen:

a) Fehlende Transparenz über teamübergreifende Abhängigkeiten

Wenn ein Team z. B. Probleme mit einem anderen Team oder mit Managemententscheidungen erkennt, diese aber nicht teilt,
bleiben strukturelle Ursachen unsichtbar.

➡️ Folge: Nur Symptombekämpfung im eigenen Team, keine systemische Verbesserung.

b) Fehlende Organisations-Lernfähigkeit

Scrum basiert auf Empirie und Transparenz.
Wenn Retrospektiven-Erkenntnisse nicht (zumindest teilweise) geteilt werden,
verliert die Organisation die Möglichkeit, gemeinsam zu lernen.

➡️ Das widerspricht dem Scrum-Wert „Openness“.

c) Widerspruch zu Verantwortlichkeiten

Das Scrum Team (insbesondere Scrum Master) soll das gesamte System verbessern, nicht nur intern „optimieren“.
Wenn man die Ergebnisse verschweigt, kann das die Wirkung des Scrum Masters stark begrenzen.

---

🔹4. Wege, um die negativen Effekte zu minimieren

Es geht darum, Vertrauen und Transparenz auszubalancieren:

✅ a) Klare Vereinbarung im Team

Das Team sollte gemeinsam definieren, was vertraulich bleibt und was geteilt wird.
Beispiel:

• Persönliche Aussagen → bleiben intern.

• Strukturelle oder organisatorische Probleme → werden in anonymisierter oder sachlicher Form nach außen getragen.

✅ b) Scrum Master als Brücke

Der Scrum Master kann als Sprachrohr agieren, um systemische Impediments in geeigneter Form nach außen zu tragen – ohne persönliche Schuldzuweisungen.

✅ c) Gemeinsame Retros oder „Cross-Team Retros“

Wenn mehrere Teams betroffen sind, können übergreifende Retrospektiven (z. B. „Overall Retros“ oder „System Retros“) helfen,
Themen transparent und lösungsorientiert anzugehen.

✅ d) Förderung psychologischer Sicherheit

Die Organisation sollte eine Kultur fördern, in der Teams offen über Probleme sprechen dürfen,
ohne negative Konsequenzen zu fürchten. Dann ist Geheimhaltung weniger nötig.

---

🔹5. Fazit