在敏捷组织中，是否存在“组织内部透明度过高”这样的情况？由Scrum Master 创建的透明度是否有不应达到的界限？
案例一
真正的透明应该是，例如，确保谈话的私密性，并向经理保证，我们会采取一些行动。作为 Scrum Master，我们可能还想为开发人员和经理创造一个安全的空间，来讨论他们如何共同处理这种情况。有多种方法可以解决这个问题，任何一种都不需要以牺牲建立的信任为代价。
让我们来看另一个不同的案例。
案例二
组织正处于迈向敏捷之旅的初期。他们感觉一切都是新的，令人兴奋的，同时，这些新的变化让他们觉得不安。Scrum Master非常热衷于解释进行Sprint Review的原因，并广泛展示不同团队的工作，从而实现整个组织的透明。
在一个相对较新的团队中，在第一次Sprint Review时，Scrum Master鼓励团队谈论他们在上一个Sprint中遇到的阻碍和挑战。团队不愿意分享这些，所以 Scrum Master 自己解释了所有阻碍团队创造更多价值的阻碍和挑战，显然这样的做法和团队成员的决定相反，虽然他的意图是想要创造透明的环境，他认为通过分享这些阻碍和挑战，利益相关者会对此采取行动。
案例三
两位PO都很紧张，不确定这个变化对他们意味着什么，他们中的一个会不会丢掉工作？告诉 Scrum Master 这个消息的人也感到很有压力 —— 本来是一次随意的聊天，现在却影响了更多的人。在这个会议上，不能采取任何行动，也没有负责人参与，更像是一场惊心动魄的猜谜游戏，紧张程度不断上升。
也许你会说，Scrum Master 做了他应该做的事 —— 确保所有直接受此变化影响的人都应该知情。
但是为了确保实现透明，Scrum Master 应该在安排会议之前收集所有需要的数据。找出谁负责该领域的决策，他们为什么要这样做，谁将参与其中。由于匆忙行事，他可能影响了一个计划，也许原计划是在大概两周后这件事将对每个人都透明，届时向各位PO收集反馈的流程也将到位。由于没有获得足够的信息就采取行动，他制造了不必要的恐慌和谣言。
结论
关于建立透明，你们有什么故事或经验吗，欢迎在评论区分享。
作者
Magdalena是一名敏捷教练和Scrum Master，在工程、航空、银行等不同的商业领域有超过10年的经验。
