大规模敏捷之Big Room Planning

本文要点

• Big room planning是每季度举行一次的为期两天的计划会议，参与人员包括所有项目和团队成员
• 如果正确地推进，让100个或更多的人在一起做计划是可能的，有利的
• 人们一边在所在的团队中做计划，一边和其他团队协作计划
• Big room planning让每个人有个总体了解，知道其他人在做什么，了解谁和谁之间有依赖关系
• 达成共识和总体方向（总体规划，the master plan）是一个成功的big room planning的先决条件

大规模计划

大规模计划，包括切片和总体规划，是帮助你应对大规模计划挑战的程序化方法。大规模计划把组织整体战略目标（图中央的目标）当做出发点，包括4个层面的计划：

1. 切片
2. 总体规划
3. Big room planning
4. 冲刺计划

虽然不同规模的框架给每季度的big room planning提供有用的框架，所有的团队和利益相关者会聚上几天，大多数组织知道如何做冲刺计划，但是很多为了给big room planning做好完全的准备而苦苦挣扎。这就是含有1.切片和2.总体规划的大规模计划要切入的地方。

为什么是big room planning？

一旦你试过了，就知道答案了：是的，可以的。事实上非常棒。而且，是的，很值得。我已经看到这样的计划方法从重大的时间问题中挽救了项目。还不止一次哦。

我来举几个例子。

第一个是深陷交付问题的金融工具市场法规(Mifid)项目。然后，他们开始以不同的方式自我组织起来，也开始比以往更投入地做计划。现在，他们已经回到正轨上。这是第一篇文章《Scaling Agile – a real story》里提到的例子。

更近的例子是我最近正在提供咨询的为其客户开发应用程序的项目。这个项目由三个团队组成，分别是数字、IT和零售。这个项目已经进行了差不多两年时间，但直到几周前，才为其50位客户提供了为期两周的试点。

几个月前我开始跟进这个项目时，我听到很多这样的话，“但是我们不知道零售那边是怎么想的”，还有“数字团队的人真的什么都没做”，“我不知道”，“怎么事情总是IT团队在做”，“这只是一个应用程序？”

经过几个月的工作、与来自各个团队的人进行了数次总体规划会议之后，大家终于不再谈论所有那些不能完成项目的原因了。大家开始讨论该做什么，设法分割任务，并优先考虑某些史诗故事，一些潜在的版本。

各团队仍然不情愿优先把时间用于和其他团队交流。他们只是忙于自己的事。构建这个应用程序的IT团队不想放弃他们的Scrum流程、他们的冲刺目标，不想危及他们的计划速度。他们对零售团队为之苦苦挣扎的应用程序内容不感兴趣，对他们认为是表面文章的板面设计、用户体验也丝毫不在意。他们把这些看作是其他人的工作。他们好像在造一辆没有引擎，也没法加油的汽车。

我设法让他们聚在一起做了big room planning。每个团队把史诗故事分解成每个团队每周最多两个主要任务。他们也创建了项目板，并讨论了任务和成员之间的依赖情况。快结束的时候，IT团队的某个成员建议每天早上9：15碰个面，了解其他人的工作状况并加以协调。很多人在big room planning之后感激不尽，他们工作得很愉快，并说最终能和其他团队的成员进行有意义的交流真是太棒了。

Big room planning只过去两周，我们就准备好了。应用程序已经提交到应用程序商店，客户开始下载使用并从中获得益处。

那么，回到关于big room planning是否值得，是否有效这个问题上，答案就是肯定的。

最后一个争论：无论在项目中有多少人，每季度两天就是人们工时的3.3%。因此，如果big room planning在交付价值上提高了3.3%的生产效率，那么big room planning就是一个不错的投资。

Big room planning简介

Big room planning是每季度举行的为期两天的计划会议，所有项目和团队成员都要参加。

根据总体规划和项目目标，所有团队要讨论在接下来的三个月里将如何完成项目目标。

他们通过把总体规划的史诗故事分解成功能，讨论、估算和优先考虑这些功能，并给出在接下来的4个两周冲刺中可以完成多少功能的最佳选择。

在这两天里，各个团队几次聚集在项目板旁，张贴和讨论他们各自的功能。他们讨论整体情况，梳理依存关系，不断调整功能位置以建立最佳可能的整体规划。

那两天临近结束时，大家就接下来三个月的团队和项目目标达成一致，讨论了风险并加以规避。

为big room planning做好准备

正如“规模计划”插图所示，你需要把切片和总体规划安排妥当以获得成功的big room planning。

还有，要完全做好准备，你需要更多：

• 就谁来分享和更新每个人的项目愿景达成一致
• 就谁来展示解决方案的现状及整体架构达成一致
• 跟项目利益相关者沟通，确保相关人员在场。你希望在big room planning上有足够的了解和授权。
• 掌握所有总体规划的史诗故事，包括估算和优先事项。我倾向于把每个史诗故事都打印在A4大小的纸上并张贴于墙上，这样大家可以随时走近它们并讨论。
• 衡量团队的敏捷及Scrum成熟度，并安排相应的协调人员。成熟度越低，就需要越多的协调人员。每个团队至多一个协调人员，如果他们不熟悉敏捷，就分解史诗故事并利用计划扑克（planning poker）进行估算。我倾向于拥有不属于项目、在大规模敏捷上有丰富经验的外部协调人员。
• 准备好足够的计划卡、贴纸、标记笔、拥有标示依存关系的红线、标签等等

准备好合适的房间并布置好

虽然这是上面提到的“为big room planning做好准备”的一部分，那个房间也要考虑到。究其原因是都很重要，但是big room planning会议往往没有得到组织足够的重视。

物质上的准备可以促成或破坏big room planning，因此，请严肃以待。

• 确保提供一个足够容纳所有人的房间，每个团队要有一张专属的桌子，另外要为其他项目参与者和利益相关者准备一张桌子。我的经验法则是要找一个两倍于能容纳所有参与人员数量的房间。一定是一个房间，而不是两个或更多靠近的房间，因为如果所有人不是在同一个房间里，团队和人们之间的交流会受到影响。
• 布置好房间——最好是在进行big room planning之前一天。摆好桌子。把总体规划挂在每个人能看到的地方。在团队桌子边上的墙上贴好团队计划。准备好项目板，展示相关的项目海报等等，还有项目愿景、用例图等。
• 锦上添花的是：
  • 在项目板上显示每个冲刺阶段的起始和结束日期，让大家更清楚地明白这是事先确定的，对大家来说也更方便。
  • 让各团队在项目板上写下产品负责人和Scrum master的名字，方便每个项目参与人员。因为有很多要理解和记住的事，我们就不必让人们去记住这些名字了。
  • 为每个参与人员准备姓名牌，便于大家记住其他人的名字，也有助于建立关系。

实施big room planning

Big room planning的那天早上

大日子终于来了。第一天早上，你应该在项目开始前一小时就到达。或者提前两个小时，如果前一天没有准备好房间的话。

我建议你跟同事和主要利益相关者做最后一次简报，包括项目领导者、项目架构负责人、业务利益相关者（那些代表雇员/客户，那些会从项目中得到好处的人），最后过一遍整个项目和角色。

我也建议给各团队分配指定的协调人，这样每个团队就只能或者主要从一个协调人那里获得支持，从而比起从不同的协调人那里获取支持将获得更一致的支持和建议。

确保你及时完成为你自己和其他协调人要做的最后准备工作，然后迎接其他人的到来并把他们带到属于他们的桌子那里。

介绍

以介绍这两天的目的和议程开场——就像这样的：

上面的议程受到了SAFe® PI Planning所建议的议程的启发，但两者并不完全相同。上面的某些步骤相当直接，我不打算深入下去。对于其他有点棘手的步骤，我会分享一些技巧和窍门：

1.目的

我们在这里的目的是为接下来的三个月做个计划，完成XYZ目标。

如果这是项目中的第一个big room planning，那么我建议要讲清楚大多数事情可能会很顺利，但很有可能在那两天里会出现一些状况。希望大家都能谅解，把这些当做学习机会，也就是下次可以改善提高的地方。

这个XYZ目标是接下来三个月的总体规划的概览，不只是单个的史诗故事，还包括计划的目的及简要描述。因此，这给每个人一个大大的提醒，作为整体来说，什么是项目的目标。同样重要的是小一点的提醒，什么是接下来三个月的目标。

2. 项目愿景

展示/提醒人们（更新后的？）项目愿景

我们希望有一个主要业务利益相关者给大家鼓鼓劲，提醒我们大家我们在这里的原因。解释一下为什么项目战略目标对业务和整个公司都很重要。讲个故事比用演示文稿的效果好，如果我们能让利益相关者来讲讲他自己的故事，说说“为什么这对我个人来说是重要的”，那效果更好，

3. 解决方案和架构

通过一个对实际产品简单的现场演示，或者对于那些已经交付的东西给出一个视觉展示，以及还有哪些是缺失的，提醒大家我们离解决方案有多远。同时重复架构的指导方针，分享最新的技术基础的变化。

4. 总体规划

在解释的时候，要让每个人都参与进来，走一遍总体规划。把大多数时间花在接下来的三个月上。也要考虑接下去的每个季度，只是提醒大家我们现在在做的事，但不要花太多的时间。

5. 团队和史诗故事

哪个团队在哪个史诗故事有相关利益

解释这个问题的最佳方法是本系列文章中的第一篇《Scaling Agile – a real story》中反复提到的那一小部分。在第二个big room planning中，我们会讲一下，我们会试试跟第一个big room planning中不同的方法，每个团队选择他们认为是属于他们的史诗故事，和其他团队就此讨论一下或完全不讨论。

然后各个团队聚集在史诗故事概览板周围，那个时候我们就问他们一些问题，这些问题跟与团队相关的史诗故事有关。接着，我们让每个人在这些史诗故事上贴上一个代表他们团队的彩色即时贴（参看图Epics & teams II）。一个小时后，我们就会得到一个概览，知道哪个团队在哪个史诗故事上是主要的驱动者，在每个史诗故事中，有哪些其他团队涉及其中。

让我们感到惊喜的是这很有效果。在那块板子前，两天里有很多人来来往往，通常是来自不同团队的人们讨论他们彼此的需要。他们如何来互相帮助？

6. 团队分组介绍

说明团队把史诗故事分解成功能的具体情况，并进行评估和优先排序

提醒人们这两天的剩余议程，并展示进展的所有细节。通常包括这些事：

1. 对每个团队——谁是你们团队的主要协调人
2. 每个团队是否已经了解对于接下来的5个冲刺阶段中团队能力的概况。举个例子：你有一个6人团队，其中包括Scrum master和产品负责人。一个成员在为期2周的冲刺阶段休假1周。每个人在整个星期中算4个点。因此，这个团队的能力在这个冲刺阶段的点数是5x8 1x4 = 44点。让团队在其团队冲刺图和项目板上写下来。有一些备注：
   1. 如果这是项目的第一个big room planning，那么我通常让所有团队只做做这个步骤，并和其他团队分享他们的团队能力
   2. 那么，为什么不是一周每人5个点呢？历史证明，在做计划时，人们总是太乐观。每周只算4个点（约等于每周4天）是一种弥补乐观的机制。
   3. 为何把Scrum master和产品负责人也包括在团队能力之内呢？那是因为构建一个产品远不是把东西放在一起那么简单，比如在软件项目中写代码和测试代码。它还包括大量的业务讨论、决策、协调等等事物。换句话说，这些是Scrum master和产品负责人的工作。
3. 接下来，解释一下我们希望团队如何把他们的史诗故事分解成每个史诗故事3-5个功能（再少的话，你只是涉及了一点皮毛；更多的话，不可能看到在项目层面上的概况）
4. 我们希望把功能写在即时贴上。对于每个功能，要求有简短的名字、说明、对史诗故事的引用和评估。参看pincode验证的例子

1. 开始估算时，从寻找一个人一周或两个人在2天半内能完成的功能开始。算它5个点，然后以其为标准，估算其他功能。
2. 除此之外，团队可以继续工作，把史诗故事分解成功能，就好像他们在Scrum冲刺计划会议中分解主题那样。
3. 团队被要求定期通过项目板和其他团队分享他们计划进行的结果。

7. 团队分组

只需让大家按照团队分组介绍的指示做。确保各个团队从利益相关者和协调员那里得到恰如其分的关注。不至于太多而打搅他们，也给足了他们所需的引导。

8. 项目板

各个团队在项目板上贴出他们最初的计划，然后和其他团队协作

在首次项目板集合之前，给各个团队15-20分钟的提醒。他们要为每个功能写好一张即时贴，但是无需介绍项目板，这是为了创造一个更干净更好的概览。

当时间到了时，让每个人都站在项目板那里，从每个团队中选取一人（可能是Scrum master或产品负责人）把他们认为属于他们的功能贴到冲刺阶段那里。

你可能需要鼓励讨论团队和功能之间的依存关系，但是也有可能，当团队遇到这类问题时在没有你的帮助情况下就开始讨论。

通过用红线连接有依存关系的功能把依存关系可视化。一旦识别出依存关系，鼓励团队结束依存关系讨论，除非这个依存关系涉及所有的团队。

小技巧：第一次项目板集合早比晚好，不要晚于第一次团队分组开始之后那几个小时。你也许会碰到团队抵抗，因为他们觉得还没准备好。如果你等得太久，就不能得到早早做好能获得的跨团队协作。看到团队在第一次项目板集合后的相互影响更多会感到很不可思议。

9. 重复

重复团队分组和项目板讨论，一般在最终的项目板集合前要进行1-2次。记住温和地推动他们每1-2小时在项目板前搞个碰面会，就算他们在各自的团队中没觉得准备好也要做。这将推动他们更多地跨团队协作和协调。

10.团队分组

接着第一天的工作，鼓励团队和其他团队及利益相关者进行协调。

在这个团队分组之后，你应该开始看到每个团队的计划大纲。如果他们还没在其团队计划上贴出他们的功能，现在是让他们做这个的好时机。它让团队更容易理解其他团队正在计划的东西，什么时候要互相拜访。

11.项目板

用所有团队的功能和依存关系来总结项目板。记住，计划够好即可。每天都要重新审查计划，稍后进行细节整理。

12.风险

各个团队在冒风险，在全体大会上讨论和规避风险。有些风险促成规避操作，那是我们想在团队计划和/或在项目板上做的，因此我们不只是讨论它，还要实际做点事。其他风险我们只是接受。把大部分时间花在最主要的3-5个风险上，其他风险现在只需列出。

13. 项目目标

各个团队制定他们基本的业务目标，然后就接下来3个月的项目目标达成一致。

在一个有着很多团队、观点、史诗故事和功能的项目中，人们经常需要帮助来寻找和记住整体目标是什么。

为了帮助寻找，我们让产品负责人通过介绍接下来3个月的一些总体目标来指导团队。然后我们请产品负责人邀请业务利益相关者一起来讨论，并对接下来3个月的项目目标达成一致。目标写得越短小越好，它们帮助整个项目实现共同目标的能力也越强。

这里有个例子是很难实现的项目目标：“在实时数据上运行（Run on live data）”。

14. 信任投票

按等级从1到5，看看每个团队对各自计划的信任度

作为最后的测试，我们可以让每个团队的Scrum master询问团队成员对于自己团队计划的信任程度，也可以询问他们对整个项目的信任度，信任度等级最高为5。

我建议你只在跟进讨论为什么这些数字不高点时才这么做，另外，更重要的是，计划或情况如何改变才让大家更信任计划。一个好问题是：“做什么能让你更接近最高等级？”

15. 后续步骤

通常，下一个步骤是团队做冲刺计划，接着开始工作。也要讨论在不久的将来会发生的事情，记得要感谢每个人，谢谢他们付出时间给予配合。

16. 不断尝试

反思big room planning那两天

记得在big room planning的开场白中提到的可能出现的状况吗？

这就是你该为下次做得更好而收集信息的时候。我自己喜欢让人们在即时贴上写下来：

• 用1-5（5是最好）给他们对于那两天的想法进行打分
• 为下一次保留一件事
• 下一次试试用不同的方法做同样的事

让大家在出去时把它们贴在门上。当所有人离开后，拍下照片，或许读一下，但要等到准备下一个big room planning的时候，再去想一想。在这个时间点，在两天的big room planning之后，你的大脑也许不能正确运作了，无论如何都不能做合理的反应了。

在big room planning之后

如果你想拥有big room planning的好处和保持良好的跨团队协作，那么我建议每天在团队的站立会后来个项目板边上的Scrum-of-Scrum会议。

议程安排和站立会的一样，除了在Scrum-of-Scrum上的分享是以团队为单位而非团队成员。

作为协调人或项目领导者，你或许想用我喜欢的这些问题中的一个来结束每个Scrum-of-Scrum会议：

我或其他人能做些什么来帮助你更快实现我们的项目目标？

但是，只有你希望收集那些障碍问题，并解决它们的时候才问这个问题。我喜欢把这叫做障碍分离（impediment busting），因为它听起来比利益相关者管理和风险规避更酷更有力。

结语

Big room planning给出了一个在下个季度所有要完成工作的概述。那是所有项目和团队成员每三个月集结起来做计划的两天。

为了理解big room planning的目标，必须确保利用总体规划对整体方向有共识。

协调在计划的成功中扮演了很重要的角色。确保你有熟练的协调人，有个足够大的房间以容纳所有的人、桌子、计划板以及让计划和依存关系可见的所需材料。

最后，与任何敏捷实践一样，暂停一下以反思什么顺利进行了，什么在下次big room planning中需要改善是极有价值的。

行动号召

下次你如果有超过2-3个团队的项目，可以试试。提前几个星期定下总体规划和big room planning的日期，然后邀请参加人员并开始准备。如果有太多阻力，就把它当做一次实验。

如果你已经试过big room planning但感到失望了，那就再试一遍。如果你遵循这系列文章中提到的技巧和窍门，我可以保证下次你会有更好的体验。

也许你最终像Martin一样也说不定，Martin是我目前参与的一家银行的CRM项目的负责人。在总体规划和big room planning之后的几个星期，他说：“我爱上这规模化计划了。之前我们浪费了业务部门不关心的数以百万计的支持流程，我们甚至都不知道。现在我们齐心合力再次为我们的客户创造价值。”

然后，他还说：“我们早该这样做了。”