背景
德国的敏捷专家 Den Sunny 在2020年发起了一个全球性的签名运动，网站 http://remove-scrum-from-safe.tilda.ws/。
我们喜欢 Scrum。我们反对 SAFe（规模化敏捷框架）创建和推广的对 Scrum 的误解。
理由主要在在于规模化敏捷SAFe官网对Scrum、Scrum Master等概念的描述与Jeff Sutherland 和 Ken Schwaber 制定的《Scrum指南》有多处出入，造成误解和误用。
…像 SAFe 这样的框架 … 与 Scrum 指南不一致，并且编纂了可能削弱团队多年的功能障碍。
– 杰夫·萨瑟兰(Jeff Sutherland), Co-creator of Scrum
呼吁和诉求
我们呼吁 SAFe 的所有者尊重个人和组织，停止承诺可以在 SAFe 中使用 Scrum 和 Scrum Master 角色！
许多组织相应地实施规模化敏捷 SAFe，并具有各自的角色和流程。由于当前 SAFe 描述中的陈述，他们可以合理地期望能够在此结构中使用 Scrum。相反，SAFe 角色和流程迫使他们使用****大量 Scrum 反模式并造成严重的功能障碍。
然而，这些组织认为这正是 Scrum 框架，他们在此基础上了解 Scrum。它引入了对 Scrum的完全错误的理解，并剥夺了组织实现目标的机会。
此外，对于决定在 SAFe 中培养 Scrum Master 技能的人来说，这会导致重大的职业损失. 他们学习了错误的理论并采取了功能失调的行为。之后，他们很难理解真正的区别，以便能够有效地帮助组织正确采用 Scrum。
因此，以下是规模化敏捷 SAFe 描述中需要进行的最少更正：
- 从 SAFe 描述中删除任何承诺使用 Scrum 的可能性的声明。
- 在 SAFe 描述中重命名 Scrum Master 角色，以排除其与属于 Scrum 的真实 Scrum Master 角色的关联。
(*) 正如我们上面所展示的，SAFe 中的产品负责人人和开发团队角色与各自的 Scrum 角色存在严重偏差。但是，只有Scrum Master角色与Scrum是不可分割的。
具体理由解析
当前的 SAFe 描述包含有关 Scrum 的误导性信息：
Scrum
Scrum 指南
Scrum 是一个用于开发、交付和维护复杂产品的框架。
Scrum (名词)：一个框架，人们可以在其中解决复杂的适应性问题，同时富有成效和创造性地交付具有最高价值的产品。
Scrum 是为产品开发而设计的。产品是为客户生产的。整个 Scrum 团队旨在产生最大的商业价值，始终专注于客户的需求和整个产品。
框架内的每个组件都有特定的用途，并且对 Scrum 的成功和使用至关重要。
Scrum 是一个框架 - 如果缺少其中的任何元素，对于具有特定上下文的特定公司来说可能还可以，但是，在这种情况下，这不是 Scrum。
SAFe
敏捷团队——一组负责定义、构建、测试并在适用的情况下部署解决方案价值元素的人
取而代之的是，SAFe描述表明，敏捷团队只处理部分功能是可以接受的。在现实生活中，它通常会导致团队专注于系统组件。
无论如何，只交付一个功能的一部分，每个敏捷团队单独交付并不能为真正的客户带来任何价值。拥有自己的待办事项和产品负责人，他们既不关注客户需求也不关注整个产品，而是被迫在系统组件级别进行本地优化。
如果 SAFe 描述为参与通用产品开发的所有开发团队规定一个单一的产品负责人和一个单一的产品待办事项列表，也许甚至可以。它有机会成为 Scrum 中的适当扩展。然而，SAFe 描述给出了完全不同的处方——每个敏捷团队都有自己的团队待办事项和自己的产品负责人。
在SAFe根据当前的描述来实现，在****敏捷团队本身不开发一个产品，没有理由去关注客户的需求。取而代之的是，它被迫在系统组件级别上进行局部优化。
在下面来自 SAFe 描述的图片中，我们可以看到一个项目集看板示例，显示了不同团队之间的众多功能依赖关系。这不是 Scrum 和 Scrum 扩展的设计方式，但这正是 Scrum 及其在 SAFe 中扩展的完全错误方法的后果。
Product Owner 产品负责人
Scrum 指南
…整个组织必须尊重他或她的决定。产品负责人的决定在产品待办列表的内容和顺序中可见。
SAFe
团队待办列表类似于 Scrum 中的产品待办列表。团队待办事项列表部分由敏捷团队之外的一个单独角色管理的项目待办事项列表填充 - 产品经理。事实上，在这种设置中，产品负责人并不是团队待办列表的唯一决策者。
Scrum 指南
即使在规模化的情况下，Scrum 也规定：多个团队经常在同一个产品上合作。一个产品待办列表用于描述即将进行的产品工作。
SAFe
多个敏捷团队及其各自的产品负责人和团队待办事项工作在共同的解决方案上——产品或产品的一部分。在以下视频中，这种情况被清楚地解释为 Scrum 扩展的主要功能障碍之一。
此外，在SAFe 中：PO 在质量控制方面发挥着重要作用，并且是唯一有权接受已完成故事的团队成员。
这是一种Scrum 反模式。由于以下原因，PO 不能承担这些责任：
- 开发团队有责任确保交付高质量的增量。
- 在这种情况下，PO 控制着 Dev Team 的工作结果，从而被定位在更高的位置，就像经理一样。它通常会刺激合同游戏并导致团队功能障碍破坏团队合作。
Scrum Master 敏捷教练
Scrum 指南
Scrum Master 以多种方式为组织服务，包括：
- 领导和指导组织采用 Scrum。
- 在组织内规划 Scrum 实施。
- 帮助员工和利益相关者理解并实施 Scrum 和实证产品开发。
- 引起改变以提高 Scrum 团队的生产力。
- 与其他 Scrum Master 合作，提高组织中 Scrum 应用的有效性。
SAFe
- Scrum Master 的职责中没有任何关于指导组织的职责；
- Scrum Master 的职责中没有关于引起组织变革的任何内容。
据我们所知， 文化遵循结构。根据 SAFe 描述创建的结构将迫使 Scrum Master 只关注团队，这是作为一个系统的组织的一部分。这通常会导致局部优化并对整个系统产生负面影响。这是最关键的 Scrum 反模式之一。
Scrum 指南
Scrum Master 负责促进和支持 Scrum 指南中定义的 Scrum。
SAFe
然而，一些团队——尤其是系统团队、运营和维护团队——选择应用看板作为他们的主要方法。
尽管 Scrum Master 角色主要基于标准 Scrum，但敏捷团队——即使是那些应用看板的团队——设立这个职位是为了帮助团队实现其目标并与其他团队协调活动。
Scrum 指南
- 跨团队协调是开发团队职责的一部分。
- 移除障碍——Scrum Master 有责任指导团队自己有效地做到这一点；只有在特定情况下，例如关键和紧急的问题或组织级别的系统障碍，Scrum Master 才会做必要的工作。
- Scrum Master 不是产品负责人而是做某事的助手，这可能是对 SAFe 模糊描述的理解。
- 状态通信由产品负责人负责。
SAFe
Scrum Master：
- 与其他团队协调
- 积极解决问题，以便团队可以继续专注于实现迭代的目标。
- 帮助产品负责人努力管理产品待办列表。
- 与管理层沟通状态
换句话说，SAFe 的描述将“Scrum Master”称为一个从其他 Scrum 角色身上承担很多责任的角色，从而完全消除了他们需要改进这些角色的真正含义。这些是 Scrum Master 行为的 Scrum 反模式，剥夺了这个角色实现 Scrum Master 目标和完美愿景的可能性。
Dev Team 开发人员
Scrum 指南
他们是自组织的。****没有人告诉开发团队如何将产品待办列表转化为潜在可发布功能的增量
SAFe
系统和解决方案架构师/工程有专门的角色。他们的职责包括：
- 定义子系统及其接口
- 确定主要成分
- 识别接口之间的协作
- 为子系统分配职责
- 开发、分析、拆分和实现使能史诗的实施
- 定义、探索和支持启动器的实施以发展解决方案意图，直接与敏捷团队合作来实施它们
- 规划和开发架构跑道以支持新的业务特性和功能
- 定义和传达共享的技术和架构愿景
- 沟通与解决方案上下文交互的要求
- 使敏捷发布培训 (ART) 和解决方案培训上的团队与共享的技术和架构愿景保持一致
如果产品开发需要所有这些，那么这些就是开发团队在 Scrum 中的职责范围的一部分。然而，在 SAFe 的描述中，团队之外的一些其他角色承担了开发团队的部分职责。此外，这与开发团队的外部依赖无关。这也与决策有关。
这是一种 Scrum 反模式，因此开发团队缺乏决策自主权。这通常会导致对整体结果缺乏责任感。最后，它刺激了对编码和测试的狭隘关注，并导致缺乏团队合作和实现业务目标的动力。
你也可以参与签名
为了在此反对意见下“签名”并在下方显示您的姓名，
请将您的姓名、姓氏、城镇和您常住国家的电子邮件发送至：
remove.scrum.from.safe@gmail.com