大规模敏捷系列：

• Spotify的大规模敏捷之路

• Scrum At Scale® 指南-切实可行的规模化扩展敏捷

• 金融企业J.P.摩根大通运用LeSS框架实施大规模敏捷转型

---

前言

最近将在项目中实践规模化敏捷SAFe，在上个月的MVP1的原型规划中，相关团队都聚在一起，通过大房间的规划会议，快速建立了共识，确定MVP1原型工作中各团队的分工和彼此间的依赖关系，以及MVP1原型的目标。但在会上也有同事提出可以进行单独的一系列协调会议确定各自的产出物，不过根据经验，这会增加等待时间和更多的沟通和对齐成本。事实证明，大房间的规划会议取得了很好的效果。上期翻译分享了Henrik Kniberg的作品《原创 理解MVP(最小可行产品)-以及为什么我更喜欢最早的可测试/可用/可爱的产品》广受好评，本次翻译分享此文，供学习交流使用。欢迎共同探讨规模化敏捷SAFe的落地实践。：） -- 唐芳彬（Alex）

原文翻译：

Henrik Kniberg & Eik Thyrsted Brandsgård

2016年12月

- 什么？一个150人的会议由2天缩短成1天？

- 是的！每两个月一次。效果很好。

- 但为什么呢？以及如何做到呢？

背景

乐高数字解决方案（DS）是一个由20多个团队组成的群体，负责通过孩子和父母使用的任何设备（电脑、平板电脑、应用程序、可穿戴设备、VR等）与他们进行沟通。我们还展望未来的产品开发，如何拥抱新技术，如何采用经典的玩玩具的方式，并结合一些很酷的东西，如增强现实，或“扫描”物理模型并将其带入游戏的方式。大多数团队都在丹麦的比隆，但我们也有一些团队在印度。

乐高的核心并不是一家数字公司。这是一个有80年历史的17000人的组织，专门优化实体玩具的设计、生产和销售。和大多数公司一样，乐高也在努力适应快节奏的数字世界，在这个世界里，变化是不断的，敏捷开发正在成为常态。

数字解决方案在乐高处于这一变化的最前沿，我们将与你分享一段我们正在经历的非常有趣的旅程！

问题所在

过去当我们只有5个左右的开发团队时，计划和同步是非常容易管理的。团队和产品负责人基本上只需要相互交谈，然后找出解决方案。然而，当我们成长到15-20个团队时，事情开始变得更加痛苦。

乐高整体上有一个很好的投资组合和预算流程。投资框架是在每年的基础上协商的（项目Y的X小时），而实际的内容决策与财务决策是分离的，因此部门在如何花费他们的精力上可以相当灵活。

所以在2014年，我们在高层有这个稳定的投资组合管理过程，在团队级别，我们有15-20个团队在做Scrum（译者注：Scrum是目前全球最受欢迎的敏捷开发流程框架）和Sprints（译者注：Scrum里的Sprint，翻译为冲刺，可以理解为一个迭代）。问题出现在中间层 - 即项目集层！

我们试图使用Scrum并以敏捷的方式工作，但除此之外，我们基本上是一个矩阵型组织在做项目。作为产品负责人，你几乎把所有的时间都花在了会议上，以此来协调团队完成所有的事情，但最终你还是得不到你需要的东西，因为其他团队有其他的优先级。

作为平台产品负责人，你可能会有10个人来找你要东西，但你不可能提供所有东西。那么你如何决定哪些事情更重要呢？有时团队最终会建立相同的东西 - 比如，嘿，除了我们已经拥有的五个旋转木马之外，还有一个过山车不是很酷吗？不能承接太多的好东西，还是怎么样呢？

综上所述，我们一直在努力:

• 跨团队的一致性 - 如何让团队朝着同一个方向前进，而不是互为绊脚石

• 客户协作 - 如何设定切合实际的期望，满足客户需求而不过度承诺

• 发布计划 - 如何跨多个sprint、多个团队和多个产品进行制定计划和排列工作优先级

• 平台开发 - 如何确保我们为未来投资，而不是仅仅实施一堆一次性的解决方案

随着2014年底的临近，我们决定尝试一些不同的东西。

改变

2015年1月，我们变得大胆，开始改变。我们将整个DS组织转变为一个“团队的团队”（译者注：team-of-teams, 也就是敏捷流程框架Scrum中的scrum-of-scrums），引入了共享的sprint节奏、去中心化的同步和依赖管理，以及每8周安排一次大房间规划活动。这产生了很多积极的影响，不仅对DS，对我们协作的其他部门也是如此。

让我们来看看经过一年半的实验我们最终的结果。

免责声明：这是一个正在进行的旅程，而不是一个已经完成的旅程。我们不断改进模型 - 例如在2016年第三季度，我们将大房间规划活动的时间从2天缩短到了1天。继续更新这篇文章很诱人，但它永远不会结束，所以让我们假设这篇文章是2016年第二季度情况的快照:o)

大房间规划之旅

今天是星期三早上，你被邀请参加这个神秘的活动，人们一直在谈论的“PI规划”。  如你所知这就是所谓的“产品增量规划”（译者注：“PI 规划”在文章中指的是Product Increment Planning，而在规模化敏捷SAFe框架，PI是指Program Increment，中文是项目集增量，此处可以理解为是同一个东西，一个大型产品研发往往对应着项目集管理工作），它是每8周发生一次的规划活动。当你走进一个大体育馆，看到如下场景：

开个玩笑....你看到的是这个：

环顾四周，你会看到所有的DS开发团队都在那里，包含所有的经理、许多客户和利益干系人，以及一些像你这样好奇的访问者。一项高阶的议程正在讨论之中。

演示时间！

几分钟后，音乐开始响起，一个快节奏的5分钟视频展示了过去两个月发布的内容的亮点，整个过程伴随着热烈的掌声。

这并不能取代团队通过Sprint评审会和用户测试等获得的日常反馈。但它提供了一个很好的概述，并提供了一些灵感。它提醒每个人我们所做事情的目的（译者注：对于Scrum框架，每个Sprint或迭代的末期，都会有一个Sprint评审会，由产品负责人PO邀请客户代表等干系人来参加敏捷团队的迭代工作评审，通过可工作的软件展示本迭代完成情况，下一步计划，还有获取客户代表等干系人反馈，拥抱变化。）。

闪电会谈！

接下来，一位经理会站起来几分钟，分享一些关于正在发生的事情和未来重要事情的想法。然后，其他人站起来，就数字儿童安全、即将到来的黑客马拉松、平台策略以及当天其他热门话题进行一系列简短的励志演讲。有人演示了使用新平台发布东西是多么容易，另一个人运行了一个有趣但愚蠢的Kahoot测试。

到了上午中期，全体会议的内容已经完成，当人们徘徊去喝咖啡时，他们会在反馈板上对每个会话（译者注：指前面提到的闪电会谈）进行评分。每次会谈多有价值和有趣？分数范围为 1-5分。

- 乔：“看，大部分是4分和5分！比上次好多了。”- 丽莎：“除了第四个话题。啊!”- 乔：“是的，这只可能是与此有关的10个人会喜欢。但我睡着了。”

你看到了一些有助于改善下次会谈的小评论。有几个人在争论我们是否应该进行闪电会谈，或者下次直接开始计划是否更好。

主持人转向你。他说：“全体会议就像一颗定时炸弹，必须让会议简短而切题，否则人们就会忽视它。如果做得好，它可以做到真正的带来帮助，即给人一种上下文感，有助于规划。”

团队突破

下一个：团队突破。每个团队都在同时进行工作，找出未来几个月要交付的关键内容，整个房间都充满了嘈杂声。一个高层次的计划，不要太详细，因为很多意想不到的事情会在8周内发生。

每个团队都有自己的可滚动白板和规划板。大多数团队成员都站在板前面互相讨论，而有些人则四处走动，与其他团队和利益相关者同步。有些人围着咖啡桌和小吃桌，随意谈论着其他话题。

你会注意到有些团队和角色有团队T恤或特殊的帽子，以便在人群中更容易认出彼此。印度团队有代表参加会议，在房间里的人与在印度的其他团队成员之间来回沟通。

乍一看很混乱，但能量水平相当高。虽然有些人看起来有点紧张或无聊，但大多数人看起来都很开心，工作效率也很高。大量自发的对话和笑声，新的联系正在形成，现有的联系得到加强。很明显，他们以前也这样做过，并且对此感到满意。

这部分活动占据了一天的大部分时间，感觉非常像一个“开放空间活动”（如果你去过其中的一个，你就会了解）。就像在一个开放空间活动中，最重要的一条规则是双脚法则。

双脚法则：如果你现在站的地方学习不到东西、没有贡献、没有乐趣，那就用你的双脚去一个你可以学习、贡献或玩得开心的地方。（好吧，我们添加了“玩得开心”的部分，它不是正式开放空间的一部分。）

你注意到主持人经常强调这一信息：在这些日子里，充分利用你的时间取决于你自己，无论是和你的团队一起计划，在咖啡机旁聊天，还是讨论架构。不要等别人告诉你该做什么或去哪里。

但是也有一些限制，所以在每个桌子上都有一个描述总体规划过程和NFRs的讲义（NFRs指“非功能性需求” - 如果你仔细想想，会觉得这个名称相当奇怪……)。诸如法律要求、服务包更新或新部署过程这些所有团队都需要考虑的事情。每一个PI都会更新NFRs。

基于拉动的计划

你注意到一个重要的细节 - 团队（大部分）在拉取工作，而不是工作推动他们。他们根据自己过去交付能力的相关数据，以及他们对现实的直觉感受来决定拉取多少工作。为了使这项工作在实践中，每个团队都有一个产品负责人，他与利益干系人进行协商，并在PI规划活动之前准备好经过优先级排列的产品代办列表。因此，产品负责人和客户负责优先级，而团队则选择要拉取多少工作。

有些团队相当独立，有自己的待办列表（即Backlog）。其他的，比如平台团队，一起工作并从一个共享的项目集待办列表中拉取特性。

你会发现项目集代办列表投射在墙上，并注意到来自不同团队的人员站在它前面，讨论应该由哪个团队来拉取哪个特性。

这些团队是半专业化的，每个团队都专注于不同的领域，如乐高ID身份验证、云技术或搜索。团队倾向于拉取最熟悉或最不讨厌的特性，因此产品负责人有时需要提醒他们，最好有人拉取优先级高但讨厌的特性，即使它与你的专长不匹配。到目前为止，团队已经很好地掌握了必要的负载平衡，以确保我们作为一个整体专注于正确的事情（而不是高效地构建错误的事情）。团队成员大多是“T型”的，这意味着他们的技能有专业的一面，但也足够广泛，能够互相帮助（译者注：“T型”人才是敏捷开发里强调的一种人才能力，每个人技能上有专业纵深或专长，但也有一定层度的横向的关于其他领域的技能，这样能避免团队资源瓶颈）。

我们曾经把项目集代办列表放在一个带有打印的卡片的物理板上，就像这样:

....但这有点麻烦，所以我们找到了一种方法，可以在我们的代办列表管理工具中直接在线完成它，投射到墙上。这样虽然减少了动手的机会，但由于我们有六个团队正在进行平台开发，因此可以更容易地跟踪所有内容的最终结果。

环顾四周，您会注意到有些团队的桌面上有大屏幕，以数字方式显示他们的代办列表，而其他团队则主要使用模拟工具。

团队板

每个团队在一个滚动的白板上都有一个物理团队板。

它开始是空白的，并在白天随着计划的形成而填充。

以下是不同部分的含义:

这基本上是团队未来4个Sprint的高阶计划（每个Sprint为2周，因此产品增量为8周），即规划活动的主要输出。

- “嗯…你们每8周才发布一次？”

- “不，8周是我们项目集层次的规划周期。发布周期是完全独立的，一些团队经常发布，一些团队发布得很少。”

当然，计划将会改变，这取决于每个团队环境的波动性。但是有一个计划仍然是有用的，因为它驱动着围绕优先级、相互依赖、容量等等的各种对话。需求总是会超过容量，因此团队和客户需要一起做出艰难的权衡决定。

为了协助计划，队员们利用了“昨日天气法则”。也就是说，他们查看过去PI的数据，显示他们完成了多少（以故事点表示）。这一小部分数据可以作为一种实际的检查参考，以避免过度承诺。我们曾经有很多关于过度承诺的问题，这反过来导致了糟糕的质量，错过了最后期限，以及客户和团队之间的不信任。面对不确定性，不如先承诺少一些，然后再拉取更多的工作，而不是先过度承诺，然后再不得不把工作推出去。

“PI目标”是团队的高层次承诺，理想情况下是基于影响的（“我们将实现业务结果X”），而不是基于输出的（“我们将交付特性Y”）。但是我们的里程不同。弹性目标是团队可能完成的事情，或者希望完成的事情，但是没有足够的信心去完成。

- “等等，‘承诺’到底是什么意思？”

很高兴你发问！一个已承诺的PI目标意味着：

• “基于我们现在所知道的，我们真诚地相信我们能够实现这一目标。”

• “我们有空余的容量来应对不确定性”。需要多少空余的容量？取决于:

  • 我们对所涉及的工作量有多大的不确定性?

  • 我们对环境的不确定性有多大（改变优先级等）

  • 这项承诺有多重要？它越重要，我们能承诺的其他目标就越少。

• “我们会尽最大努力实现承诺，但我们不能100%确定。”

• “在任何时候如果我们发现我们无法履行承诺,我们将尽快让利益干系人知道”。

承诺之前通常意味着“某人为你做出的不切实际的允诺。处理它”。这会损害质量和动力，并使规划和预测变得非常困难。

风险板

随着规划的进展，团队开始识别可能导致承诺失败的风险，比如“新许可证不会按时交付”之类的潜在问题。这些都张贴在分散在房间各处的风险板上，每个项目或主要计划都有一个风险板。有些风险仅通过与合适的人交谈就能在当地得到解决，而另一些风险则需要升级，并在第一天结束时留在板上接受管理评审。

在过去，风险要么被忽视，要么全部被很快地委托给管理层（将其变成瓶颈）。通过自底向上的方式将风险可视化，团队在承担自己的所有权方面做得更好，并且只会对他们真正需要帮助的风险进行升级。有时，降低风险的成本是巨大的，与风险会带来的影响不成比例，所以最好接受风险。承认并接受风险可以消除挫折感，让团队安心，这样他们就可以专注于交付而不是担心。

依赖板

很快你就注意到墙上挂着一块相当巨大的板。它似乎是某种重心，因为总是有嘈杂声和人员聚集在那块板前。这块板一开始是空的，但到第一天结束时，它就变成了一堆杂乱的便利贴，用……呃....红色的纱线互相连接！贴纸，剪刀，纱线，到底是怎么回事?

我们将其称之为“依赖板”（有时也称为“项目集板”）。它表明谁需要什么，以及从谁处获取，还有什么时候需要。仔细看看……

每一列是一个团队，每一行是一个Sprint（2周）。这些注释表示从蓝色到粉色的依赖关系。“为了交付这个（蓝色卡片），我们需要你交付那个（粉色卡片）。“您会注意到大量关于哪个Sprint将向谁交付什么内容的讨论和协商。

似乎没有人负责专门管理依赖板。主持人最初提出了它，但随后团队完全围绕它进行自组织工作，将彼此间的依赖关系可视化，并将该依赖板用作握手协议的一种形式，以确定谁需要与谁交谈。依赖板是一个集中式的工具，使去中心化的协作成为可能。

- “所以团队张贴他们计划交付的所有功能特性？”

- “不，只有带依赖性的功能特性。我们过去把所有功能特性都放到板上，但这太凌乱了，没人能理解它。我们得出结论，真正重要的是依赖关系，所以我们只关注这一点。独立的功能特性可以在各自的团队板上看到，但不是在这里。”

你发现了一个明显的瓶颈（CIT专栏，Corporate IT），并就如何最有效地利用瓶颈进行了热烈的讨论，以及一些关于如何在长期内减少瓶颈因素的对话。

- “这是怎么回事? ”你问主持人。

- “嗯，CIT实际上是一个独立于DS的组织，所以一开始他们根本没有参与规划过程。但在最初几次PI规划活动之后，很明显，CIT变成我们最重要的依赖对象。人们对此怨声载道。因此，我们在依赖板上为CIT增加了一列，并开始邀请该组织的代表参加PI规划活动。”

- “这有帮助吗？”

- “是的，有很大不同！变得少推卸责任和更多的合作，更少的‘我们和他们’，更多的谈到‘我们和我们’。”

CIT和DS的人面对面地在依赖板前讨论如何最大限度地利用我们宝贵的瓶颈（当然，还有随着时间的推移如何减少瓶颈因素）。看起来很糟糕，但是依赖板前的人告诉你“以前更糟！”你应该看看我们做的所有改进！比如将东西移动到云上以减少依赖性。不过需要时间。”

最后一行的依赖明显是空的。这就是所谓的IP（“创新与规划”）。这个Sprint被保留下来，为计划外的创新、前三个Sprint的工作量溢出以及其他“东西”（比如下一次PI规划会议、培训以及其他可能出现的东西）留出空间。

一位工程师指出：“我们现在在履行承诺方面做得更好了。我们有容量数据（故事点等），因此不太可能过度承诺。而且，IP Sprint还充当了一种缓冲区，所以如果发生爆炸，我们有空间进行恢复。但最重要的是，承诺是经过讨论和协商的，而不是空口说白话。”

- “那创新呢？这就是IP Sprint中的I，对吧？”

他笑着说。

- “那部分通常会被扔出窗外。但是现在比以前好多了。上一个PI（译者注：Program Increment， 即项目集增量）我们在IP sprint（译者注：Innovation and planning，即前面提到的“创新与规划”）中做了一个黑客马拉松，从中我们得到了很多很酷很有用的东西！有些团队总是能够在IP期间挤出时间进行创新，这让这次未能成功的团队感到羡慕。”

你可能会对另一件事情感到好奇：

- “会议结束后依赖板会怎么样了（译者注：该处会议指的是大房间的PI规划活动）?”

- “我们卷起来，放回到办公室，把它贴在墙上。”

- “然后呢? ”

- “每周我们做一次或两次的Scrum of Scrums。每个团队的Scrum Master聚集在依赖板前，他们讨论障碍和依赖，并标记出被解决的障碍和依赖。”

他给你看一张照片：

- “那么印度的团队呢？如果依赖板只挂在比隆的墙上，他们怎么查看依赖板?””- “我们仍试图找出解决方案……”- “下一个PI规划呢？这块依赖板会怎么样？”- “抛弃了。在每一个PI规划中，我们创建一个新的依赖板。这将给我们一个全新的视角，也让我们在用依赖板的形式和结构进行实验时，不被历史问题困扰。”

计划草案展览会

在看似混乱的突破规划进行了几个小时后，主持人站到台前宣布到了计划草案展览会的时间了。当他总结了这种形式（到目前为止大多数人都很熟悉）时，骚动平息了下来。

- “我们将分别进行四次7.5分钟的会话。每次会话，一名团队成员都会呆在他们的团队板上向其他人介绍计划，而其他人则可以查看其他团队的演示。”

他开始了一个7.5分钟的大计时器，演示开始了。小组围绕着每个规划板来听取和讨论该团队的计划 - 他们打算交付什么以及为什么要交付。

讨论了依赖关系和风险，并在某些情况下发现了新的问题。别慌，我们明天有时间解决问题。

- “为什么是7.5分钟？”为什么是四个会话?”

- “我们已经尝试过很多不同的计时，这是到目前为止最有效的方式。只需要足够的时间来学习一些东西，且避免感到厌烦或陷入过多的细节。”

7.5分钟后，铃声响起，第二次会话开始。人们转移到另一个团队去听他们的计划。以此类推，总共四次，也就是30分钟。

- “好吧，那么每个人都可以选择四个团队参观并了解他们的计划？”- “完全正确”。- “但是大的图景呢？听到所有团队的计划不是很有用吗？”- “对少数人来说是的。但对绝大多数人来说，答案是否定的。所以选你最关心的四个团队去参观。如果你想知道更多，你可以在明天的突破中拜访更多的团队。”- “你们一直以来都是这么做的吗?”- “没有。在过去，我们通常以循环赛的方式共享计划草案。每个人都会坐下来，然后每一次由一个团队站起来向整个房间的人员展示他们的计划，而主持人将摄像头指向团队板，并投放到大屏幕上。一旦我们找到合适的工具，操作就会变得非常灵巧。但即使有严格的时间限制，至少也要花一个小时才能把20支左右的队伍都召集起来。”- “哎哟”- “是的。尽管我们尽了最大的努力使它变得有趣，但它完全是一个令人打瞌睡的时候！只有几个人认真的听着，但大多数人茫然地瞪着手机或头依靠在桌子上等待它尽快结束！人们确实关心其他团队在做什么，尤其是他们所依赖的团队。但是就像其他3或4个团队一样，他们不需要知道所有团队在做什么。因此，我们决定停止强迫每个人遵循这个计划，而是采用一个基于拉动的系统。展览会模式工作得更好！”

你四处走动，听演讲。人们讨论他们的计划、依赖、技术、风险等。真的感觉像某种展览会！

主持人再次走过并指出:

- “注意到房间里的高能量了吗？”这是我们的主要反馈回路，告诉我们我们的方式是正确的。如果能量水平很低，人们开始走神，无论我们做什么都是错的，我们需要调整形式。所以我们保留了产生能量的部分，而放弃了让人睡着的部分。”

你会注意到实际上有两个主持人，两人一组结对，轮流上台。他解释说:

- “我们总是结对地引导这种活动。这样一来，当一方在引导的时候，另一方后退一步，观察能量水平并思考改进。结对还提供了一些冗余，以防我们中的一个人生病，并更容易培养一个新的主持人。”
管理评审和问题解决

在第一天结束时，大多数人会离开，而经理们则留在后面。管理评审时间到了!

风险板被收集起来在大的依赖板附近排成一排，经理们则围成半圆。

每个人都受到平台所做事情的影响，所以他们从那里开始。平台产品负责人总结了他们的计划，并提出了一个艰难的权衡决策。

- “坏消息。在这个PI我们没有容量同时交付A和B”。

这两项计划（译者注：指前面提到的A和B）都非常重要，不采取其中任何一项都将产生更广泛的影响，因此辩论相当激烈。主持人帮助保持大家沟通方式的文明和聚焦。经理们讨论他们有什么选择，每种选择的利弊，最后决定优先考虑A，推迟B。几个团队明天需要在此基础上调整和重新对齐他们的计划。

接下来，他们检查每个风险板。风险板上仍然存在的风险是团队无法自行解决的，因为它们涉及组织的不同部分，或者不在团队的控制范围内。这群经理人现在需要掌握主动权，决定该做什么，他们有动力这样做，因为这是唯一能阻止他们回家的东西……

你注意到风险板上的列。其中一位经理解释道:

- “ROAM框架（译者注：指的是风险的四个状态Resolved、Owned、Accepted和Mitigated的首字母缩写，也可以称为”漫步框架“）对这个对话非常有用。我们一次检查一个风险，讨论它并做出决定，然后将其移动到这四列的其中一列：解决，拥有，接受或者减轻（‘漫步风险板’）。所以回家的标准是非常明确的。风险板上的一切风险都必须经过讨论和‘漫步’（译者注：即更新状态）！”

在经历了每一个风险的检查之后，他们就明天早上谁来为大家总结这个问题达成一致。

回想一下你读过的一本关于服务型领导（译者注：也有翻译为仆人式领导）的书，你会意识到，这整个过程某种程度上促使管理者进入了服务型领导模式。团队看到管理者承担责任并帮助解决问题，从而建立信任。

主持人确认了这一点。

- “管理评审过去相当混乱，耗费精力。首先我们没有风险板，所以谈话非常没有结构化和花了很长时间，决策有时被丢失或遗忘。当我们引入风险板后，有太多的风险正在升级。渐渐地，团队变得自己更善于承担风险管理的所有权（当然是受到经理们的鼓励），因为风险升级得越少，经理们就越有能力、也更愿意承担这些风险。”

第2天 - 稳定计划

第二天早上，你在吃早餐时问某人:

- “为什么是第二天？你们还没说完吗？每个团队都有一个计划、确定的依赖关系、解决的风险等等。现在要做什么呢?”- “这个计划只是暂时的。当我们昨天回家时，有许多未解决的问题。现在我们已经考虑过了，我们可以对计划进行迭代，并整理出一些问题，否则这些问题就会出现在下游，打乱sprints（译者注：即敏捷流程框架里的“冲刺”，等同于“迭代”）。”- “所以你们总是做两天的PI规划会议吗?”- “到目前为止的确是这样。但是现在我们已经做得很好了，第二天的能量很低，所以我们未来可能会尝试一天的形式。”
快进：我们做到了，确实，1天工作得更好！去搞清楚。稍后会详细介绍。

早餐后，经理们上台分享他们对昨天出炉的计划草案的反馈意见，总结管理评审中的一些关键决策，并解释他们将如何处理升级到他们手上的关键风险。

出现的一个大问题是不稳定的测试环境，几个团队已经确定这是一个很大的风险。负责该领域的经理总结道：“我们知道这个问题，这个PI的大多数优先事项都集中在提高稳定性上。如果你想要更多的信息，可以和X团队谈谈。但要获得一个真正稳定的环境需要几个月的时间，所以在此之前，我们只能接受这种风险。”这不是什么好消息，但团队意识到问题已经得到承认，事情至少正在朝着正确的方向发展。一些人将调整他们的计划，考虑到持续的不稳定。

在那之后，团队回到突破规划，和昨天一样的形式 。有些人提前完成并开始做其他事情，而其他人则有很多依赖关系，并继续与其他团队合作，以确定需要做什么，以及需要由谁以及何时完成。

主持人鼓励人们留下来，即使他们的部分计划已经完成。他们可以做其他事情，写代码，写电子邮件，等等。

- “有时候，一个问题会出现在另一个依赖你的团队中，如果你还在，问题可以很快得到解决。”

在某些情况下，团队的一部分人会回家，而一些代表则会留下来为其他团队服务。

到下午早些时候，计划已经稳定下来了(或者已经尽其所能的稳定)，现在是进行最终计划评审的时候了。同样的形式，4个会话，团队可以四处走动，听取彼此的计划。每一块板上的彩色乐高积木都被用来表示该计划自昨天以来是否发生了很大的变化，有点像一个状态标志。帮助人们决定去哪里。

信心投票

在计划草案展览会之后，团队回到他们的桌子上，主持人宣布信心投票的时间到了。“你对自己能够达到PI的目标有多大的信心？”每个人举起1-5个手指，其中1表示“忘了它”，5表示“完全自信”。

环顾四周，你会发现大多数团队都非常有信心实现他们的承诺。但是有一些1和2，所以主持人让他们说几句话。总而言之，能量水平相当低，所以你不禁想知道 - 这么做的实际价值是什么?

迷你回顾会

议程上的最后一点是小型回顾。每个团队坐下来讨论PI规划活动本身，与上次相比有哪些改进，以及下一次应该改进哪些。此外，每个团队成员个体都以匿名的方式对整个PI规划活动的价值（“这对我来说花了多少时间”）进行5分制评分。

之后，除了Scrum Master和主持人留下以外，其他人都回家了。他们在改进板前围成一个半圆，然后一个接一个地发布所有的个人评分，并总结来自他们团队的反馈和改进建议。

在每个人都发表了自己的意见之后，他们退后一步，看看改进板，确定模式和主题。在大多数情况下，人们喜欢这个活动（主要是4分和5分），认为这是一个值得花时间的活动。

- “等等！这些人大多是开发人员吧？我以为开发人员讨厌开会？”- “是的，当我们刚开始实施这些规划活动时，我们很担心。但评级高于我们的预期，甚至在第一次规划活动的时候也是如此。似乎人们把这看作是实际工作，而不是会议。”

虽然有一些2分的，甚至有一些1分的，但是大多数人都有关于下次如何改进该活动的可操作的反馈。他们喜欢做大房间规划的想法，他们更关心的是我们如何执行它们，或时间长度。

这次迷你回顾会上出现的一件事是信心投票。这到底有多大用处呢？一些人想调整它，另一些人认为它是浪费时间，应该被删除。经过一些讨论，他们同意了一个实验 - “让我们在下一个PI规划中完全跳过信心投票，看看我们是否会想念它!”

快进：所以我们跳过了下一个PI的信任投票，正如我们所怀疑的那样，我们没有想念它！团队基于拉取而不是推动来承诺他们的计划，这意味着他们有足够的信心，因此投票是多余的。再见，信心投票！这只是我们不断试验和调整形式以实现价值最大化和浪费最小化的众多例子之一。
更进一步：在2016年第三季度，我们尝试了1天的版本（同样的活动，但被压缩到1天而不是2天），看到了明显的能量水平和评级的改善！所以我们还是用一天的版本。但普遍的共识是我们可能需要在刚开始的时候采用两天的形式，作为一个垫脚石，直到我们可以学习到如何更有效地开展它。

就是这样。结束了。团队带走他们的团队板和风险板并回家。主持人留下来互相做一个简短的汇报，记下下次要做的不同之处，然后开始打包依赖板和其他东西。

现在，你已经看到一个PI规划了！希望你能喜欢。

现在让我们后退一步。

除了大房间规划，还有什么改变？

很多！虽然PI规划是我们所做改变的重心，但显然还有更多。“真正的”工作实际上是两个PI规划之间发生的事情。

在PI期间，团队通常会进行Scrum和为期两周的sprint，通常会举行Scrum仪式，比如sprint计划、每日站会、待办列表梳理、sprint评审和sprint回顾。我们也有一个共享的PI演示和回顾。但我们不会在这里详细介绍。本文主要关注PI规划活动，因为它说明了我们正在努力实现的自下而上的去中心化的协作。PI规划就像一面镜子，可以看到整个流程和文化。

值得强调的一项活动是PI预规划，在这里，产品负责人聚在一起讨论即将到来的PI的特性并确定其优先级。在每个PI规划之前，我们有三个这样的预规划会议。在那里，特性从一个标题演变为根据价值、时间重要性和工作量进行优先级排列的易于理解的特性。如果你想了解更多，请先阅读“延迟成本”或WSJF（加权最短作业）。如果你想深入了解，可以看看Don Reinertsen的《产品开发流程原则》一书。

PI规划活动的实际目标是什么？

一句话：对齐

PI规划是一个大房间规划活动，其目的是让团队保持彼此对齐。

大房间规划的价值与你有多少依赖关系直接相关。当然，最好的方法是通过设计你的团队结构和系统架构，以最大限度地减少依赖性，并避免像大房间规划这样的事情。但是，如果你有一群团队在开发相同的产品，或者（就像我们的情况一样）使用共享技术的紧密相关的产品，那么大房间规划是非常有用的。

通过sprint，每个团队都有2周的规划视野。PI规划增加了一个更高层次的规划视野，在这里，团队聚集在一起，展望未来（2个月，一个“产品增量”），但不包含太多细节。

诀窍是避免创建精确、详细的计划的诱惑。大致正确总比完全错误好。

请注意，产品增量（译者注：即Product Increment，也就是前文提的PI），不管它听起来像什么，并不是一个大爆炸的版本。这是一个同步点，一个所有团队聚集在一起，进行彼此对齐的时间和地点。这与发布周期完全解耦。不同的团队按照不同的周期发布，这取决于他们工作的性质。所以我们按节奏做计划，并按需发布。

PI规划解决了团队不一致的问题，以及由此产生的所有挫折和浪费。它是一个让人们对共同目标产生影响的平台，一个“大心跳”，可以同步一群或多或少的自治团队。

没有什么比面对面沟通更好的了。在PI规划中，共享的信息量和所做的决策数量实际上是相当惊人的。这是可能的，因为所有的大脑信任和授权都是在同一个房间里同时召唤的。你要找的人现在就在房间里。不需要发送日历邀请或等待合适的会议时间，只需要去交谈。

如果没有PI规划这样的大房间规划活动，我们将需要一系列单独的协调会议、电子邮件和电子表格来完成同样的事情，这会增加等待时间和误解。在PI规划之后（在sprint期间）讨论工作的更精细的细节，但是骨架是在大房间规划活动中创建的。

PI规划的另一个好处是它创建了彻底的透明性，揭示了大型软件开发的固有复杂性。对于外部利益干系人来说，这可能有点吓人，但是他们会获得更好的理解和对团队的更多尊重，因为他们的工作实际上是在试图驯服这个复杂的怪物（译者注：指前文提到的大型软件开发）。

那么缺点是什么呢？嗯，说成本很诱人，但实际上这并不是一个大问题。无论员工是否在PI规划中，他们的薪水都是一样的。唯一真正的间接成本是场地和食物，相对于所获得的价值而言，这是一个很小的成本。

心理上的一个缺点是，如果你是一个控制狂，你不会带着平和的心态和清晰的计划参会。整个设置可能感觉相当混乱和无组织。

然而一旦你习惯了这种形式，你就会意识到会议提供了足够好的概述，使你能够对目标的达成放心，同时仍然允许你将重点放在你认为特别重要的领域。剩下的你需要真诚地留给团队 - 毕竟，他们通常都是非常聪明和敬业的人，否则为什么要聘用他们呢? ：）

这带来了什么影响？

没有什么是完美的，但总的影响是一直是令人惊讶的正面和积极的，似乎没有人想回到以前的方式。

• 减少重复工作。团队之间更协调，所以他们在冗余工作上浪费的时间更少。

• 减少依赖性问题。团队之间相互等待所浪费的时间更少。团队与其他部门和利益干系人的互动更加顺畅。

• 管理者可以更快地更新优先级和解决障碍，因为他们对实际情况有更好的了解。

• 客户的信任度提高了，因为他们对团队的工作内容和原因有了更好的理解。

• 规划更容易，承诺也更经常得到满足，因为团队和投资组合规划人员了解我们可以承诺多少工作，以及我们的实际容量是什么。

更重要的是，这提高了团队成员的积极性。当困惑和浪费变得更少的时候，上班会变得更有趣。并且有动力的人工作做得更好，所以这是一个正向的循环！

我们看到的另一个影响是，乐高的其他部门参观了会议，获得了极大的灵感，并开始探索如何在他们自己的部门中实现这些原则和实践。事实上，敏捷就像病毒一样在公司内部传播，而且PI规划活动的高度可见性就像催化剂一样。

尽管如此，它仍然是复杂和艰苦的工作（我们喜欢称之为“艰苦的乐趣”），并且有很大的改进空间。但是，通过向共同的目标更紧密地保持对齐，获得更多的授权团队，更好地为客户设定正确的期望，更好地识别相互依赖关系 - 所有这些都让我们感到，我们已经更好地以正确的方式交付正确的东西。

这一切是如何开始的？

你还在吗？想知道这一切是怎么开始的吗？好吧，这是背景故事。

在90年代后期，生活是美好的。一小部分人（我们今天称之为跨职能团队）会用一些GIF和HTML制作乐高所有的在线展示。但是随着数字化的发展，交付数字化解决方案所需的人员数量也在增加，开发工具也变得更加先进。在大约15个团队中，我们真的踩到了彼此的脚趾阻碍了对方，并朝着不同的方向前进。

起初，我们试图让一群项目经理来解决这个问题，但并没有什么帮助。他们似乎总是落后一步。典型症状：不断更新计划，要求指导委员会增加资金或推迟发布日期。

我们仍然相信我们在2009年左右在团队级别引入的敏捷原则，但是我们并不真正知道如何扩展它。其中一个项目经理听说过一个叫做“规模化敏捷框架”的东西（译者注：即SAFe，目前全球最受欢迎的规模化敏捷框架，官方网址：https://www.scaledagileframework.com/ ），他去了解了更多关于SAFe的东西。当他回来后和我进行了分享，然后我们对其进行了考虑……好几年了。

但突然，推进的机遇来了。在与一些团队讨论之后，项目经理相信这个框架可以帮助我们。因此，部门的所有经理都被邀请来介绍这个框架。他们并没有完全被说服，但尽管如此，这似乎可能有所帮助，而且似乎不太可能使事情变得更糟，所以见鬼，为什么不试一试呢？所以一位高级经理支持了这一计划，并为部门的120名员工筹集了资金进行培训。

我们进行了三天的培训，其中包括一次模拟。并且接下来的日子我们信心大增，创建了一个项目集代办列表，并安排了我们的第一个PI规划活动。这是一个嘈杂、拥挤和混乱的开始。但是，令我们吃惊的是，我们很快就取得了成功，活动的执行结果比我们原先担心的要好。

下面是一些帮助我们成功开始的事情:

• 团队希望它能够工作。如果团队不接受，我们就会惨败。尽管对框架的某些部分持怀疑态度，但他们确实发挥了作用，并尽了最大努力使其取得成功。

• 现有敏捷经验。这些团队多年来一直在运行敏捷，组织中有相当一部分人理解这些原则。这是一个很好的扩展基础。

• 管理层支持。管理层有足够的支持和信心使其成功。尽管有相当多的高级经理直接参与其中，但他们接受了其中的风险，为风险的展开留出了空间，并确保我们有足够的资金支持来教育和培训所有相关人员。

• 非教条方法。尽管我们使用了”规模化敏捷框架“作为启动平台，但我们并没有教条地遵循该框架。该框架包含了太多我们需要的细节，而且它是为一群研发同一个产品的团队而优化的，而我们的团队则开发许多不同的产品和服务（译者注：目前最新版本的规模化敏捷框架SAFe的内容也包含了多团队开发不同产品或服务的支持）。因此，对于每一个新的PI，我们都对流程进行了定制和调整，添加了我们需要的元素，删除了没有带来价值的元素。这给了人们一种主人翁感，他们可以看到过程和结构是为他们服务的，而不是相反。

现在怎么办呢？你目前面临的挑战是什么？

我们不断试验。每一个改变要么改善了事情，要么使事情变得更糟，要么没有任何区别。但我们保留了有用的东西，抛弃了没用的，所以随着时间的推移，情况会逐渐改善。

最大的改进是在开始的时候，现在的变化比较小，我们似乎找到了一个可持续的流（译者注：该处的流指的是精益里的价值流动）。主要是小的调整和权衡。房间里有这么多人，我们不能确保每个人都超级快乐，但至少我们可以确保没有人超级不快乐。

我们最大的挑战是我们要做很多不同类型的事情。尽管我们是一个部门，使用的工具和技术基本相同，但我们没有构建一个统一的产品。理想情况下，我们希望根据特定的产品或价值流将团队重新组织成若干较小的团队集群（我们的“统一组织设计理论”）。然后可以有一些较小的PI规划，而不是大型怪物会议。但是我们还没有搞清楚，我们已经习惯了让每个人都在一个房间里进行规划。

因此，我们很难将PI规划仅聚焦在一个或两个主题上，并且有一个清晰的故事情节。相反，我们最终得到了一系列不同的目标，以满足不同的团队和利益干系人。对管理者来说并不称心，因为他们想要了解团队将要开展的工作的清晰故事情节。并且对团队来说也不称心，因为他们希望清楚地了解当前的背景和总体优先事项。这是一个先有鸡还是先有蛋的问题。

虽然试验和调整过程似乎是件好事，但我们有时会问自己这个元问题：我们真的在优化正确的变量吗？或者我们是为了改变而改变？例如，如果PI规划不再是最大的约束，我们真的应该继续尝试改进它吗？到目前为止，我们真诚地相信我们正在改进正确的东西，但偶尔检查一下是有好处的。

另一个挑战是势头。一开始，每个人都对这些变化感到兴奋（或焦虑），精力充沛，气氛很好。但有时我们陷入一种舒适的“一切如常”的心态，从而失去势头。PI规划期间的小变化和惊喜可能是一件让人思考的好事情。事情总是可以改善的，我们只是需要不时地提醒自己。

总结

希望这篇文章对你有用！当然对我们是有用的，给我们一个理由真正反思我们一直在做和学习的事情:o)

只要记住，我们的方法不是规模化敏捷的“答案”。这只是一个例子，一个正在进行的旅程的快照。敏捷就是持续改进 - 它是一个方向，而不是一个地点。

不过有一件事是肯定的。如果我们从一开始就计划整个改变，我们将一无所获！相反，如果你想要改变，就从现在开始，设定一个目标，然后开始尝试。关键在于人 - 如果他们支持这个改变，如果他们支持这个想法，那么你就会取得进步，否则就不会。

不要羞于使用现有的流程框架，或从其他公司或案例研究（如本文）中借鉴想法。没有必要重新发明轮子！只要确保你根据你的上下文来调整内容。你不会找到一个完整的解决方案来满足你的需求，但是你可以找到一些方法来让事情朝着正确的方向发展。

祝你好运！

- Henrik & Eik

感谢：许多非常聪明、充满热情、友善的人参与了这些变革！我们不会把每个人都列出来。我们的职责主要是支持这一旅程，并为之煽风点火。:o)

原文作者简介

原文链接：https://blog.crisp.se/2016/12/30/henrikkniberg/agile-lego

作者Henrik Kniberg，位于瑞典的一位非常著名的敏捷／精益教练，其LinkedIn地址：https://www.linkedin.com/in/hkniberg/ 。Henrik发表了许多敏捷和精益相关的优秀作品，其文风特点：洞见精辟，深入浅出。其手绘更是一流！部分内容如下：

• 《硝烟中的Scrum和XP--我们如何实施Scrum》

• 《看板和Scrum相得益彰》

• 《原创 理解MVP(最小可行产品)-以及为什么我更喜欢最早的可测试/可用/可爱的产品》

• 《Product Ownership in a nut shell》

• 《Spotify engineering culture (part 1) 》

• 《Spotify engineering culture (part 2) 》

• 《Lean from the Trenches》

• 《Agile@Lego》

译者：唐芳彬(Alex)，SAFe SPC,CSP,CSM,PSM1。Agile／DevOps Coach。长期服务于IT规模上千人的敏捷企业。前IBM敏捷／DevOps高级顾问，善于提供企业级从需求到生产的端到端DevOps工具链平台解决方案和分布式团队的大型敏捷项目实施服务。