译者导读：随着越来越多的公司与组织（尤其是规模较大的企业）启动敏捷转型，规模化敏捷的话题在业界和敏捷社区中越来越火热。然而传统公司在敏捷转型的规模化中时常步履蹒跚，其中主要的原因之一就在于：原本严丝合缝的组织架构，无法良好地适应并赋能一线的敏捷团队进行充分的自管理和自组织。因而社区通过总结 PatientKeeper 的优秀实践，提炼了 MetaScrum 的方法，即本篇译文的主题：在大型企业或组织的规模化敏捷实施中，设置高层级的 MetaScrum 团队，负责组织级的愿景与优先级确认，部门协调，跨团队互动，快速移除障碍等等工作。
原文：
美国国家航空咨询委员会在华盛顿召开会议，讨论美国取得航空发展领先位置的计划。
那些曾经使用传统管理实践的企业，已经在其开发组织中引入了 Scrum。虽然开发组织已经准备好，也采用了价值流（Value Stream) 开发产品 。但企业中其他的职能和组织，如管理层和运营部门，仍与开发组织的Scrum团队缺乏良好的联系。除此之外，不同产品的组织之间也没有公认的互动方式。
虽然 Scrum 团队已就位，然而来自传统管理结构的指示（或干扰的威胁），仍会导致产品内容和方向的控制中心产生混淆。
· 在 Sprint 过程中，管理层可能会干扰开发团队和待办列表，导致团队的 Sprint 失败或触发紧急程序 (Emergency Procedure)。
· 管理层对于 PO 权威的反复侵犯会使得团队难以完成优化价值的工作。
· 由于 Scrum 团队与管理层之间糟糕的关系造成了需求的噪音，导致团队可能无法成功交付基于愿景的，有价值的定期产品增量。
· 或管理层对于团队的支持不足，例如，不能严格要求客户遵守公司级别的业务和合同协议。
尽管如此，市场的需求常常相互冲突且变化莫测，而且组织的干系人（例如股东，以及和公司发展方向有利害关系的管理层）也会对组织的运作方式表达关切或诉求。这些关切的公开透明很重要，但仅仅因为管理层表达了担忧，并不意味着他们干预具体的开发工作就能够有所帮助。一个健康的 Scrum 团队会尊重 PO 的权威，并以不同的方式对待管理指令和市场需求，因为将这两者混为一谈就会造成混淆。由于竞争问题、市场变化、销售合同或是开发中的技术挑战与机遇，企业可能需要改变单个或整体产品的方向。因此每个 PO 团队需要定期与利益相关人会面，讨论产品和价值流相关的期望和观点并达到一致。
所以：
需要创建一个 MetaScrum 团队，将其作为一个论坛，让整个企业在组织中每一级的 Scrum 中都能与 产品负责人的待办列表保持一致。
MetaScrum 团队定期开会，由 PO 和公司高管组成，CEO 也会出席。MetaScrum 团队其中有一位 MetraScrum PO，负责在管理层、Scrum 团队，以及其他利益相关人之间引导共识。MetaScrum PO 通常会主持会议，并引领 PO、高级管理层和开发管理者之间的协调工作。
MetaScrum 有自己的节奏，对应于一种公司级别的组织 Sprint 脉搏。MetaScrum每隔一段时间就召开一次会议（类似于 Sprint 计划会议），包含了在这段时间间隔内，所有的 Scrum 团队的 Sprint 将要交付的内容。
Scrum团队可以在这个会议上向团队外部的利益相关人请求得到支持、资金、信息，甚至产品——任何他们完成交付所需要的东西。MetaScrum会议接受这类请求，并做出相关的决策来支持他们。这个定期会议上，管理层和PO们可以探讨针对产品待办列表的变更。会议结束时，产品待办列表将锁定，管理层则需要等到下一次会议才可以提出意见。
MetaScrum 提供了一个论坛，让 PO 们在这里交流各自的计划，并解决产品组合层面的问题。PO 们（可能带着来自管理层的想法和输入），在产品、营销方案和其他产品项目集之间调整重点和优先级。MetaScrum 可以让 PO 们了解高级管理层的方向，并告知管理层产品计划如何支持企业的目标。在 MetaScrum 的会议之间，Scrum 团队的工作不受到管理层的干涉。
健康的组织不会侵犯 PO 的权威，优秀的 PO 也会仔细考量所有利益相关人的意见（包括管理层）。此处请查看 #6 引入管理者。
MetaScrum 不是管理层控制产品方向的主体，而是协调各个产品以及产品团队与管理层之间的论坛。管理者可以通过 MetaScrum 提出产品变更的建议，但 PO 仍然负责自己的产品方向。目前广泛流行的MetaScrum 的一种实践，实际上是将管理层意志强加于产品开发之上的。然而在产品开发方面，Scrum 团队保持自治非常重要。
在 PatientKeeper (一家为医生提供医疗保健应用程序的公司)，产品组织完全采用 Scrum 模式，常常发生这件事：由于市场因素、销售合同和开发问题，需要推迟某些医院交付上线的日期，并加快其他医院的日期。如果有重大的承诺变更，MetaScrum 团队必须在 MetaScrum 会议当天决定由谁负责与每个客户（医院）的 CIO 进行沟通。同样在 PatientKeeper, MetaScrum PO 运行 MetaScrum，并与高管和部门主管达成一致。CEO 也在 MetaScrum 团队中，除了在有需要时进行引导，通常不会对 MetaScrum 进行干预。
然而，他非常积极地消除了由 MetaScrum 团队识别到的组织障碍 —— 包括改变管理层。有人说他就像是 MetaScrum 团队的 Scrum Master —— 类似于 超级Scrum Master，不过他把具体操作交给了 Scrum of Scrums Master。
在 3M 公司，一个部门的首席执行官通过在其组织中担任 MetaScrum PO 的角色来管理 MetaScrum。MetaScrum 团队每周开两次会，重点是对齐待办列表。在这里，她希望明确和解决优先事项。另外有单独的领导团队专注于消除组织级的障碍。
丹麦的 Systematic (一家开发软件和系统解决方案的公司) 和瑞典的 Saab Defense 以 Scrum的方式管理整个组织。他们在管理层顶级有一个论坛，其功能类似于高层级的 Scrum of Scrums。
MetaScrum 是企业级变革的焦点。组织作为一个整体，有统一的战略愿景、待办列表、路线图、定期的产品增量（结构重组、新的市场计划等等），以及其他 Scrum 组件，这些组件都是使企业顺利运行和加速的必要条件。利益相关者可以改变组织的方向，人员，或是预算分配以消除各种障碍，因此有权这样做的人必须是这个整体的一部分。
每个价值流和产品都应使其障碍在 MetaScrum 的层次上可见。有可能个别产品的资源不足以解决这些障碍，而公司作为一个整体能够提供力量解决问题。也可能是，这个问题在产品中存在隐性的联系，只有通过在一个联合论坛中使问题变得透明，才能将其暴露。优秀的 MetaScrum PO 会在 MetaScrum 会议中发现问题，并尽可能在当天解决，如果不能，则越快解决越好。
一个良好的 MetaScrum 是所有跨产品决策发生的地方。所有对产品决策有发言权的人都应受邀参加会议。MetaScrum 定期开会，这样每个人都知道他们将在何时何地做出产品决策。首席执行官的大力支持和出席在场对于 MetaScrum 有效工作非常重要。史蒂夫•乔布斯在苹果公司每两周就会召开一次会议，讨论所有的战略产品决策 —— 这正是一个 MetaScrum 的实例。对较小的公司，MetaScrum 通常每周开会，以跟上组织的变化周期。
虽然每个 PO 对他们的产品待办列表拥有最终权力，但是他们需要在批准的预算内工作。MetaScrum 是在公司层面进行预算变更的论坛。管理层和 PO 在现场进行较小的变更；如果决策涉及重大问题，例如需要寻求额外的投资，管理层和 PO 就在会议结束后立即采取行动，追求达成决策的路径。
在最佳实践中，MetaScrum 是组织中的一种强大力量。如果 PO 们在这次的 MetaScrum 会议上同意了一项管理层建议，那么在下一个 MetaScrum 之前，该决定就是最终的。直到下一次 MetaScrum 会议，经理们才可以向 Scrum 团队提出更多的话题，这样 Scrum 团队就可以不受管理层的干扰进行工作。即使是客户和销售人员也应了解，在 MetaScrum 会议结束后，直到下一次 MetaScrum 会议之前，试图更改协议是徒劳无益的。
MetaScrum 对组织的所有利益相关者负责，以引导为每个相关者团体创造有价值的、可行的业务。其中包括组织的员工、客户和投资者。通过运用常识来决定包含多少参与方，但一定要保持 MetaScrum 工作和决策的透明。
好的公司可能很快就会发现，管理层在产品管理中所起的作用越来越小，公司的权力慢慢地从执行管理层转移到了 PO。组织变得愈发扁平。执行经理和部门主管可能会放弃已经过时的角色，转而成为产品负责人 PO ，更接近实际行动。
MetaScrum 最早的公开参考资料：PatientKeeper 在2003年时启动MetaScrum，并在 (Proceedings of Agile Development Conference (ADC’05) [Sut05]) 进行了描述。
——译者：Vincent Zhang
校对：Suzzi Su
参考资料：
（1）A Scrum Book：37 MetaScrum
