Bruce有话说
最近在学习Scrum@Scale的时候，了解到在组织级别，让PO Team和利益相关者充分沟通的一个Event是Executive MeatScrum。而这个是脱胎于一个叫做MetaScrum的Scrum Pattern。今天我们不谈Executive MetaScrum，先来学习一下MetaScrum在实际工作中对Scrum团队的作用和影响。MetaScrum没有翻译成中文，是因为如果翻译成“元Scrum”还是让人不知所云。所以索性还是保持原味吧。
作为敏捷团队，无论是在敏捷转型过程中还是在一个相对成熟的敏捷组织里。无论是在扁平的层级组织中还是有较多层级的组织中。我们总要面对以下的一些实际问题和场景：
- 管理层如何和Scrum团队一起工作
- 作为自管理团队，Scrum团队如何和应对管理层的干涉
- 在复杂产品线下，多团队、所干系人、多个Product Owner如何合作
- 组织级高层是否可以通过Scrum来进行组织级管理
希望今天的这篇文章能够给你一些启发，想不想尝试一下，应用这个Pattern到实际工作中？
正文
企业将Scrum引入到其开发组织中，这些组织以前使用的是传统的管理实践。他们根植在企业中已久，并将其价值流设置为开发出品。与此同时企业中存在其他的功能和机构，比如管理和运营，它们与开发组织——Scrum团队缺乏良好的联系。此外，不同产品的组织之间没有公认的相互交流的方式。
✥ ✥ ✥
Scrum团队已经存在，但是来自遗留管理结构的方向(或干扰的威胁)导致了对产品内容和方向控制的混乱。 在Sprint期间，管理人员可能会搞乱backlog或干扰开发团队，导致团队在Sprint中失败或触发紧急程序。反复干扰Product Owner的工作可能会使团队难以完成他们的工作以优化价值。一些Scrum团队可能无法向愿景交付有价值的常规产品增量，因为Scrum团队和管理层之间的不顺畅的关系导致需求中出现噪音。或者，管理层在支持团队时可能过于被动——例如，对公司层面的业务和合同协议不闻不问。
尽管如此，市场经常呈现冲突和变化的需求，利益攸关者(例如那些拥有公司股份的人，以及在公司方向上有利害关系的管理者)偶尔会提出关于组织如何工作的关注或愿望。将这些担忧透明化是很重要的。但是仅仅因为管理层表达了这样的担忧并不一定意味着他们干预开发工作是有帮助的。一个健康的Scrum团队会尊重产品负责人的权威，对待管理层命令和市场需求会有很大的不同;在同一个事件中混合这两种讨论可能会导致混乱。由于竞争问题、市场变化、销售合同或开发中的技术挑战和机会等，企业可能需要改变个别或整体的产品方向。产品负责人团队需要定期与利益相关者会面，以统一产品和价值流的观点和期望。
因此:
创建一个MetaScrum事件构建一个讨论的环境，在这个环境中，整个企业可以在组织的每个Scrum级别中与PO的backlog对齐。 MetaScrum定期举行会议，由Product Owner和公司管理层组成。首席执行官出席。MetaScrum有一个MetaScrum的Product Owner，他负责协调管理层、Scrum团队和其他利益相关者之间的关系。MetaScrum产品负责人通常主持会议，并领导产品负责人、高级管理层和开发管理层之间的对齐工作。
MetaScrum有自己的节奏，类似于一种公司级的Sprint脉冲(Sprint Pulse)。MetaScrum每一段时间间隔就召开一次，它类似于Sprint计划会，包含了Scrum团队将在两次MetaScrum会议间隔的Sprint中交付的内容。
在这个会议上，Scrum团队可以向Scrum团队之外的利益攸关者请求支持、资金、信息甚至产品———任何他们为完成交付而缺少的东西。MetaScrum可以作为一个场所，来提出此类请求并做出支持这些请求。管理层和其他产品负责人可以在这个定期会议上为产品backlog的变更进行讨论。在会议结束时，为了管理管理层的想法，产品待办事项列表将被锁定，直到下一次MetaScrum会议。
✥ ✥ ✥
MetaScrum提供了一个讨论的场所，在这里Product owner们可以彼此交流他们各自的产品计划，从而解决产品组合级别的问题。Product Owner们可能会从管理层那里获得信息，在产品、营销计划和其他产品计划之间转移重点和优先级。MetaScrum可以使PO们对执行管理方向敏感，并且可以告知管理层产品计划如何支持企业目标。在MetaScrum会议之间，Scrum团队在没有管理层干预的情况下工作。一个健康的组织不会干涉Product Owner的工作，好的Product Owner会仔细考虑所有利益攸关方的意见，包括管理层的意见。参见“让经理参与进来”。
MetaScrum不是一个管理层控制产品方向的机构，而是一个产品之间以及产品与管理层之间协调的场所。管理层可以通过MetaScrum提出产品变更需求，但是Product Owner们仍然掌握着他们各自产品的方向。一个非常流行的MetaScrum例子实际上被用于将管理层意志强加到产品开发上。而Scrum团队在产品开发这个方面保持自治是很重要的一个原则。
在PatientKeeper(一家为医生提供医疗保健应用程序的公司)，产品完全是按照Scrum方式组织开发的，经常发生这样的事情:由于市场因素、销售合同和开发问题，他们需要推迟某些医院软件的上线日期，同时加快其他工作。如果有重大的承诺变更，MetaScrum必须决定谁将在MetaScrum会议结束时与每个客户(医院)的CIO交谈。同样在 PatientKeeper，MetaScrum 的Product Owner运行 MetaScrum 并确保与高级管理人员和部门负责人对产品的理解一致。 CEO 在 MetaScrum 中并且通常不会干预 MetaScrum 本身，除非在需要时提供帮助。 然而，他会积极地消除由 MetaScrum 确定的组织级的障碍——包括变更管理。 人们说他就像 MetaScrum 的 ScrumMaster，一种超级 ScrumMaster，但他把执行操作留给了 Scrum of Scrums Master。
在3M公司，一个部门的首席执行官通过担任MetaScrum产品负责人的角色来运营MetaScrum。MetaScrum关注于围绕待办事项列表的对齐，每周开会两次。在这里，她想要明确轻重缓急。一个独立的领导团队专注于消除组织障碍。
丹麦的Systematic(一家开发软件和系统解决方案的公司)和瑞典的Saab Defense以Scrum的形式运行整个组织。他们在管理层次的高层有一个论坛，其功能类似于高级Scrum of Scrums。
MetaScrum是企业级变更的焦点。组织作为一个整体有一个战略远景、一个待办事项列表、一个路线图、增量(重组、新的市场计划等等)，以及其他使企业平稳运行和加速的Scrum组件。利益攸关者可能会改变组织的方向，改变人员配备，或改变预算分配以消除障碍，因此有权这样做的人必须是主体的一部分。
每个价值流和产品都使其障碍在MetaScrum级别上可见。有时候从单个产品的资源出发可能无法解决这些障碍，而公司作为一个整体却可以提供解决这些问题的动力。也可能是，这个问题在各个产品之间存在隐性联系，只有在多产品综合讨论会上才能让这个问题显现出来。优秀的MetaScrum的Product Owner会在MetaScrum会议上发现问题，并尽可能在当天解决问题，否则也需要尽快解决。
一个好的MetaScrum是所有产品内部决策的核心。应该邀请所有对产品决策有发言权的人参加会议。MetaScrum定期召开会议，以便每个人都知道他们将在何时何地做出产品决策。要使MetaScrum起作用，CEO的大力支持和在场是非常重要的。史蒂夫·乔布斯每两周在苹果公司召开一次会议，会上提出所有战略性产品决策，这就是MetaScrum实施的一个例子。对于较小的公司，MetaScrum经常每周开会，以跟上组织中的变化周期。
虽然每个Product Owner对他们的产品待办事项列表有最终的权力，但是他们需要在一个经过批准的预算下工作。MetaScrum是公司级别预算变化的讨论场所。管理层和Product Owner在一起讨论，对预算做小改动;如果决策涉及重大问题，比如需要寻求额外的投资，管理层和Product Owner在会议结束后立即采取行动来遵循决策的方向。
在最佳实践中，MetaScrum是组织中的一股强大力量。如果产品负责人在MetaScrum活动中同意了一个管理层的建议，那么这个决定在下一次MetaScrum之前是最终决定。在下一次MetaScrum活动之前，管理层可能不会向Scrum团队提出额外的要求，这样Scrum团队就可以不受管理层的干扰地工作。甚至客户和销售人员都知道MetaScrum事件结束后，在下一次事件之前试图改变协议是徒劳的。
MetaScrum对组织的所有利益攸关者负责，以引导可行的业务，它为每个利益攸关者集团创造价值。这包括组织的员工、客户和投资者。使用或多或少包容的常识，但保持MetaScrum工作和决策的透明性。
在适当的时候，优秀的企业可能会发现管理层在产品管理中起的作用越来越小，企业的权力慢慢地从执行管理层转移到Product Owner。组织将变得扁平。执行经理和部门主管可能会放弃已经过时的角色，反而成为Product owner，以此来参加执行操作。
请参看 让经理参与进来.
The first published reference to the MetaScrum ([1]) describes the PatientKeeper MetaScrum that started in 2003.
[1] Jeff Sutherland. “The Future of Scrum: Parallel PIpelining of Sprints in Complex Projects.” In Proceedings of Agile Development Conference (ADC’05), IEEE Press, 2005.
Picture credits: NASA, GPN-2000-001705, https://archive.org/details/GPN-2000-001705 (public domain).
