{"id":1847,"date":"2025-10-24T11:40:24","date_gmt":"2025-10-24T09:40:24","guid":{"rendered":"https:\/\/blog.hardscrum.com\/?p=1847"},"modified":"2025-10-24T12:07:31","modified_gmt":"2025-10-24T10:07:31","slug":"openness_vs_safety","status":"publish","type":"post","link":"https:\/\/blog.hardscrum.com\/en\/openness_vs_safety\/","title":{"rendered":"Openess vs Psychological Safety"},"content":{"rendered":"

To encourage openness during a retrospective, the so-called \u201cLas Vegas principle\u201d is often applied. This means promising that statements made during the retrospective will not be shared outside the group. However, this can be problematic if the improvements require the cooperation of managers or other teams. And what does the Scrum Guide actually say about this?<\/p>\n

<\/p>\n

\ud83d\udd39 1. Official Basis: What the Scrum Guide<\/em> Actually Says<\/h2>\n

The Scrum Guide (2020)<\/strong> defines the Sprint Retrospective<\/em> as follows:<\/p>\n

\n

\u201cThe purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.\u201d<\/em>
\u201cThe Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done.\u201d<\/em>
\u201cThe Scrum Team identifies the most helpful changes to improve its effectiveness.\u201d<\/em>
\u201cThe most impactful improvements are addressed as soon as possible.\u201d<\/em><\/p>\n<\/blockquote>\n

\ud83d\udc49 Important:<\/strong>
The Scrum Guide does not<\/strong> say that the contents or results of the retrospective must \u201cstay within the team.\u201d
The so-called \u201cLas Vegas Principle\u201d<\/em> (\u201cWhat happens in Vegas stays in Vegas\u201d) does not appear<\/strong> in the Scrum Guide or any other official Scrum sources (Scrum.org, Scrum Alliance, etc.).<\/p>\n

So this principle is a community interpretation or cultural practice<\/strong>, not an official rule<\/strong>.<\/p>\n

\n

\ud83d\udd39 2. Origin of the \u201cLas Vegas Principle\u201d<\/h2>\n

The idea comes from the belief that the retrospective should be a safe space<\/strong> for honesty and openness.
It\u2019s often used in the agile community as a cultural guideline<\/strong> to build trust:<\/p>\n

\n

\u201cWhat\u2019s said in the retro stays in the retro.\u201d
\u2014 except for the agreed-upon improvement actions.<\/p>\n<\/blockquote>\n

\ud83d\udcd8 This approach is frequently recommended by agile coaches and trainers (e.g., in the Agile Alliance or Liberating Structures community) to create psychological safety<\/strong> \u2014 but again, it\u2019s not part of official Scrum<\/strong>.<\/p>\n

\n

\ud83d\udd39 3. Why This Can Be Problematic<\/h2>\n

Keeping everything within the team can cause several serious issues<\/strong>:<\/p>\n

a) Lack of Transparency Across Teams<\/h3>\n

If a team identifies problems that involve another team or management decisions but doesn\u2019t share them,
systemic issues remain hidden<\/strong>.<\/p>\n

\u27a1\ufe0f Result: The team treats symptoms instead of causes.<\/p>\n

b) Lack of Organizational Learning<\/h3>\n

Scrum is based on empiricism and transparency<\/strong>.
If retrospective insights never leave the team, the organization cannot learn collectively<\/strong>.<\/p>\n

\u27a1\ufe0f This conflicts with the Scrum value of Openness<\/strong>.<\/p>\n

c) Misalignment with Scrum Roles<\/h3>\n

The Scrum Team<\/strong>, especially the Scrum Master<\/strong>, is responsible for improving the entire system, not just the internal team.
If results are kept secret, the Scrum Master\u2019s impact is greatly limited.<\/p>\n

\n

\ud83d\udd39 4. How to Minimize Negative Effects<\/h2>\n

It\u2019s about balancing trust and transparency<\/strong> effectively:<\/p>\n

\u2705 a) Make Explicit Team Agreements<\/h3>\n

Teams should jointly define<\/strong> what stays confidential and what can be shared.
Example:<\/p>\n

    \n
  • \n

    Personal statements \u2192 remain private.<\/p>\n<\/li>\n

  • \n

    Structural or organizational issues \u2192 can be shared, framed objectively and respectfully.<\/p>\n<\/li>\n<\/ul>\n

    \u2705 b) Use the Scrum Master as a Bridge<\/h3>\n

    The Scrum Master<\/strong> can act as a mediator, communicating systemic impediments appropriately<\/strong> and without personal blame.<\/p>\n

    \u2705 c) Hold Cross-Team or System Retrospectives<\/h3>\n

    If multiple teams are affected, shared retrospectives<\/strong> (\u201cOverall Retros\u201d or \u201cSystem Retros\u201d) can help make problems transparent and address them collaboratively.<\/p>\n

    \u2705 d) Foster Psychological Safety<\/h3>\n

    Organizations should create a culture where teams can speak openly about problems<\/strong>
    without fear of blame or punishment. That reduces the need for secrecy.<\/p>\n

    \n

    \ud83d\udd39 5. Summary<\/h2>\n
    \n
    \n\n\n\n\n\n\n\n\n
    Aspect<\/th>\nAssessment<\/th>\n<\/tr>\n<\/thead>\n
    Official Scrum Rule<\/strong><\/td>\n\u201cLas Vegas Principle\u201d is not official<\/strong><\/td>\n<\/tr>\n
    Intent<\/strong><\/td>\nProvide a safe space for honesty<\/td>\n<\/tr>\n
    Risk<\/strong><\/td>\nLoss of transparency and organizational learning<\/td>\n<\/tr>\n
    Solution<\/strong><\/td>\nClear agreements, Scrum Master as mediator, systemic communication<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n
    \n

    \ud83e\udded Conclusion<\/h2>\n

    The \u201cLas Vegas Principle\u201d may be well-intentioned<\/strong>, but if applied rigidly,
    it can undermine the very transparency and continuous improvement<\/strong> that Scrum depends on.<\/p>\n

    A healthy Scrum Team should protect personal trust \u2014
    but not hide systemic insights<\/strong> that could help the entire organization grow.<\/p>\n","protected":false},"excerpt":{"rendered":"Um die Offenheit innerhalb einer Retrospektive zu f\u00f6rdern, wird gerne das sogenannte “Las Vegas-Prinzip” angewendet. Es bedeutet das Versprechen, dass Aussagen aus der Retrospektive nicht nach au\u00dfen weitergetragen werden. Dies kann aber dann problematisch sein, wenn die Verbesserungen die Mitarbeit von Managern oder anderen Teams ben\u00f6tigt. Und, was sagt eigentlich der Scrum-Gude dazu?","protected":false},"author":3,"featured_media":1852,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[53,4,5],"tags":[],"translation":{"provider":"WPGlobus","version":"2.10.10","language":"en","enabled_languages":["de","en"],"languages":{"de":{"title":true,"content":true,"excerpt":false},"en":{"title":true,"content":true,"excerpt":false}}},"_links":{"self":[{"href":"https:\/\/blog.hardscrum.com\/en\/wp-json\/wp\/v2\/posts\/1847"}],"collection":[{"href":"https:\/\/blog.hardscrum.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.hardscrum.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.hardscrum.com\/en\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.hardscrum.com\/en\/wp-json\/wp\/v2\/comments?post=1847"}],"version-history":[{"count":6,"href":"https:\/\/blog.hardscrum.com\/en\/wp-json\/wp\/v2\/posts\/1847\/revisions"}],"predecessor-version":[{"id":1851,"href":"https:\/\/blog.hardscrum.com\/en\/wp-json\/wp\/v2\/posts\/1847\/revisions\/1851"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.hardscrum.com\/en\/wp-json\/wp\/v2\/media\/1852"}],"wp:attachment":[{"href":"https:\/\/blog.hardscrum.com\/en\/wp-json\/wp\/v2\/media?parent=1847"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.hardscrum.com\/en\/wp-json\/wp\/v2\/categories?post=1847"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.hardscrum.com\/en\/wp-json\/wp\/v2\/tags?post=1847"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}