Es ist einfach gesagt: "What happens in Vegas, stays in Vegas", frei übersetzt bedeutet das, was in Las Vegas passiert, bleibt in Las Vegas. Und wenn wir das auf Scrum und die Retrospektive beziehen, dann wissen wir, dass wir Inhalte aus der Retro nicht außerhalb breit treten wollen. Damit sind die Teammitglieder eher gewillt, sich an Verbesserungen, Gesprächen und Offenheit zu beteiligen. So kurz, so gut. Doch die Vegas-Regel können wir noch zu viel mehr nutzen, denn um zu bestimmen, wie weit und wo wir wissen über unsere Lernerfolge teilen wollen und können.
Die Vegas-Regel in der Retrospektive im Scrum Team
Wenn du mit der Regel in Berührung kommst, dann ist das meisten im Scrum Team. Der Scrum Master, der Product Owner und die Entwickler (Teilnehmerkreis) treffen sich zur Sprint Retrospektive, um die Zusammenarbeit zu verbessern. Oft wird das auch durch einen Agile Coach eingeführt, begleitet oder verbessert. Es geht immer um Zusammenarbeit im Team. Nach Möglichkeit mit dem Ergebnis, für den nächsten Sprint gleich etwas einzubringen, sei es nun ein Experiment oder eine konkrete Verbesserung.
Durch eine gute Moderation, der goldenen
Vegas-Regel Retro: Die Lernergebnisse weiter tragen
Soweit, so gut. Doch was passiert denn mit den Ergebnissen einer Sprint Retrospektive, wenn wir das Lernen größer fassen wollen? Können andere Menschen, Teams und Teile einer Organisation nicht auch lernen? Vielleicht habt ihr gerade was sehr cooles im Team gemacht, und das Ergebnis wäre wertvoll zu diskutieren? Wie du dabei nun die Vegas-Regel interpretieren kannst, das zeige ich dir nun in den folgenden drei Abschnitten einmal genauer.
Grundsätzlich: Wir wollen Transparenz und wir müssen in Organisationen lernen. Das steht außer Frage. Damit wir lernen können, müssen Menschen sich wohl fühlen, emotional sich sicher und relevant fühlen. Wir brauchen also die wertvollen Gedanken, Impulse und Meinungen der Menschen. Wenn diese falsch interpretiert werden und Menschen ein falsches Gefühl bekommen, hinterlassen wir schnell verbrannte Erde.
Was hier hilft, ist geführte Diskussion anhand von Werten und Prinzipien, die auch die Fehlerkultur und den konstruktiven Austausch fördern.
Bei den Lernergebnisse ist es wichtig, das Wissen kompakt darzustellen. Dieses Wissen, was aus dem Lernen entstanden ist, was vertrauensvoll innerhalb von Retrospektiven erarbeitet wurde, soll gemeinschaftlich archiviert werden, damit zum späteren Zeitpunkt auf das Hintergrundwissen zugegriffen werden kann.
Im Team
Wenn wir Teammitglieder in einer reifen Teamumgebung betrachten, dann kommen diese fast spielerisch zu guten Ergebnissen, der geschützte Raum und die 5 Phasen einer Retrospektive helfen, die kontinuierliche Verbesserung voranzubringen. Die Vegas-Regel besagt, dass die Inhalte einer Retrospektive im Team bleiben und zum Beispiel (auch mal notwendige) Schuldzuweisungen nicht nach außen gehen.
Hier kannst du diesen Aspekt immer gerne erwähnen und darauf achten, dass Menschen sich wirklich dem Thema widmen können und frei sprechen dürfen. Die psychologische Sicherheit im Team (siehe Google Studie)
Empfehlung: Nutze einen teaminternen Platz (Wiki, Information Radiator) und bereite die Informationen und Ergebnisse auf. Hier greift nur das Team zu bzw. hat nur die Berechtigung. Besitzt du eh nur ein Team, dann ist dieser Punkt oft wenig in der Diskussion. Stelle sicher, dass allen Teammitgliedern das Ergebnis und das Vorgehen transparent ist.
In Produktteams
Schauen wir uns die nächste weitere Stufe an. Nehmen wir nun an, ihr entwickelt nicht mehr alleine im Team, sondern arbeitet an einem Produkt, mit mehreren Teams. Auch hier wollt ihr natürlich konstruktiv in Retros Verbesserungen erzielen. Oft finden hier zwei Arten von Retrospektiven statt:
Dabei werden in der Produkt Retrospektive Themen besprochen um das Produkt oder den Wertstrom kontinuierlich zu verbessern. Die vereinbarten Maßnahmen sind dann oft für alle oder mehrere Teams relevant.
Empfehlung: Wenig überraschend sollten die Produktergebnisse natürlich im Produkt auch sichtbar sein, sprich alle Teams haben mitgewirkt und sollten deshalb natürlich auch an den Ergebnissen partizipieren.
Die Organisation
Bei der Organisation betrachten wir in der Regel immer die Varianten, dass mehrere Teams mehrere Produkte entwickeln. Dabei müssen sich die Teams, die unterschiedliche Produkte entwicklen, sich nicht unbedingt kennen. Doch auch hier wollen wir den Aspekt des Lernens berücksichtigen. Nur weil Teams sich nicht kennen, bedeutet das nicht, dass sie nicht auf von Ergebnissen aus der Retro am Ende jedes Sprints lernen können.
Empfehlung: Nutze in der Organisation Formate und Praktiken zu etablieren, die Teams in die Lage versetzen, selbst aktiv werden zu wollen. Es empfiehlt sich daher, dass Teammitglieder selbst einen Lösungsvorschlag, den erstellten Verbesserungsprozess oder das durchgeführte Experiment vorstellen wollen. Es ist darauf zu achten, dass eine Kultur des Vertrauens entsteht und die ganze Organisation mit dem Vorgehen gute Erfahrungen machen kann. Dabei hilft, Ideen zu visualisieren und originell vorzustellen.
Beachten wir noch einmal die sogenannte Dunbar Zahl, dann gibt uns diese eine Möglichkeit zu verstehen, wann und wie soziale Interaktionen stattfinden. Ab ca. 150 Menschen ist eine Grenze erreicht.
Du kannst nun einmal für dich selbst prüfen, ob du jegliches Learning innerhalb deiner Familien, deines Freundeskreis oder beliebigen Personen aus deiner Stadt teilen würdest (größer 150 Menschen).
Fazit
Bei jedem Übergang in der Organisation zu einem größeren Kontext ist die Frage, „was bleibt in Vegas“ zu bewerten. Eine goldene Regel, damit klar ist: „was aus der Retrospektive darf weitergegeben werden“, kann durch die Teams aufgestellt werden. Unterschiedliche Auffassungen dazu klärst du vorab in einem Meeting. So könnte der Scrum Master des Teams mit weiteren Scrum Mastern schnell und einfach erarbeiten, wie dieses Vorgehen aussehen kann.