Scrum Patterns : MetaScrum(译)

关注

发布于: 2021 年 06 月 13 日

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).