【敏捷FAQ 第7回】回顾会议不起作用…逃离ToDo会议和重播的方法

 感谢您阅读本文。我是隶属于敏捷团队的藤井智弘。
 人生中有时也需要“反省”。然而，这必须始终是为“前进”而进行的。
 在每日站会之后，下面将讨论有关回顾会议（Retrospective）的问题。

 使用 KPT（Keep=持续事项、Problem=问题、Try=下一步尝试事项，这是一种从三视角进行回顾的手法）开展回顾会议已经四个月了。P 和 Try 都会产生很多条，而且产生的 Try 基本都能执行。可是，我并没有感觉到团队在变好。
 仔细看内容，P 往往是“没有◯◯设计文档”“没有写△△测试”等作业上的遗漏，Try 则是“制作◯◯文档”。另一方面，对于“信息传达有遗漏”这样的 P，每次都会附上“改善沟通方式”这一 Try。
 这能算作改进吗？
 前几天，上司对我说：“如果每次都出现‘没有◯◯文档’，那不如一开始就按瀑布模型把所有设计书都写好更好吧。”我当时无法回答。虽然觉得不对，但说不出哪里不对，心里一直很迷茫。

 先从最后的迷茫说起。上司的指摘有一半是对的。瀑布模型中有“在设计阶段编写设计文档”的规定，只要有这个规定，“没有设计文档”的情况就不容易发生。也就是说，上司是在说：“你们团队没有一个用来防止遗漏的规定”。这是一个正确的观察。不过，就此跳到“所以要用瀑布模型”就太快了。规定不一定非要从流程表里拿来，团队自己也可以制定。而团队自己制定规定的场所，就是回顾会议。上司戳中的迷茫，正是“回顾会议没有发挥作为制定规定场所的作用”。

 剩下的两点，也有同样的根源。虽然“P 和 Try 都有并且也在执行”，却没有实感，是因为即使产出和执行的数量在增加，团队的做法却一点没变。“制作◯◯文档”只是再多增加了一份文档，但下一个冲刺还是会出现“没有△△文档”。消失的只是一个事件（实例），而在其根底重复生成同类事件的机制——没有确定谁来写、什么时候写、完成的标准是什么——依旧存在。这是作业而不是改进。相反，“改善沟通方式”中没有写明下周谁要改变什么，所以根本无法执行。这是愿望而非改进。提问者的回顾会议，连介于作业和愿望之间的“做法变更”都一次也没决定。

 回顾会议的工作，不是一个个地消除不理想的事件，而是以小而可试行的方式，改变不断造就这些事件的团队做法，一次只改一个，并在下一个冲刺中试验。对于好的事物也是一样，要把这次偶然成功的事物，有目的地转变成可再现的形式。

 以下，以 Try 的“粒度”和“归属”两个切入点，重新构建提问者的回顾会议。

     图1：列举后清理，又出现相同便签——列举会与重播

 在培训中，会这样教：

• 回顾会议每个冲刺都要进行。
• Try 要精简为少量，并务必执行。

 提问者遵守了这些原则，但依旧无效。
 越是严格遵守的人，就越会产生如下疑问：

• P 和 Try 都能产出很多，这不是好事吗？比起产出少的团队，这才更健康吧
• Try 的执行率很高。如果这样还是不行，那应该根据什么来判断“它在发挥作用”呢
• 对上司说的“那就用瀑布模型吧”，应该如何正确回应

 我的回答是：产出量的多寡是健康度的证明，但并不是回顾会议的成果。应关注的不是 Try 的执行率，而是做法改变的数量。同时，应该对上司回答：“您说得对，我们确实没有规定。从下个冲刺开始，我们会自己逐条制定。”
 原因将在下面说明，但首先来看一下那些无效回顾会议的常见面孔。

 无效的回顾会议往往有几种固定的“面孔”。请阅读时思考您的团队更接近哪一种。

第一种：列举会型——在 P 列出了各种作业遗漏，然后在 Try 中将每一条都改为“要做”，剩下的时间用来分配负责人。这看似会后立刻解决，但下一个冲刺又会出现其他遗漏（有时数量相同）。

第二种：重播型——像“加强沟通”“增加测试”“尽早请示”等，没人会反对但也没法着手的 Try，会跨越多个冲刺以相同措辞重复出现。即使觉得已经执行，也不清楚以什么标准算执行过，所以这些条目不会消失。

第三种：消化率型——以便签数量和 Try 的消化率作为回顾会议指标。产出很多，也处理很多，数字每次都很好，但团队的工作方式丝毫未变。提问者的团队很可能属于这一类。

第四种：反省会型——便签的主语变成了“谁”。“某某的实现拖延了”“由于某某确认遗漏”等。发言者的视线不是看向队友，而是看向领导，发言内容变得安全无波。这与上次在每日站会上，报告会的对象变成管理者的情况在回顾会议中重演了。

第五种：手法遍历型——不停地更换“产出方式”，从 KPT 换到 Fun/Done/Learn，再到下一个…。新的手法在前几次会带来新鲜感，确实会出现不同的便签。但如果处理方式不变，也只是几次后就会回到原点。

    图2：即使改变产出方式，若之后处理方式相同，也会在几次后回到原点

 这五种面孔看似各不相同，但都源自同一个误区：“只要产出并执行，回顾会议就算起作用”。持此想法的话，就会认为产出多是成功，执行率高则更好，若产出减少就换手法。五种面孔正是忠实执行这一判断的结果。

 面对这个误区，再回到之前的三个疑问。

 产出多不是好事吗——确实是好事。对于产出少的团队，首先需要想办法让大家产出。然而，产出只是回顾会议的“入口”，不是“出口”。便签是用来发现反复发生的问题的材料。“没有◯◯文档”本身只是一个事件。只有统计同一类型的遗漏在过去 3 次回顾中出现了几次后，才能看见机制上的问题——如“未确定谁来写和写作时间”等。材料越多越好，问题在于只停留在材料阶段。

 即使执行率高也不行吗——要看执行的 Try 粒度。Try 存在粒度，太细就是作业，太粗就是愿望。“制作◯◯文档”就太细，仅能消除一个事件；“改善沟通方式”就太粗，下周谁的行为都不会改变。所谓能够称之为改进的，是介于两者之间的内容——如“把设计更改的通知集中到某接收渠道，由当班人员发起”“在完成的定义中写明‘给谁、做什么’，并在评审时确认”等，这类能改变团队做法本身的措施。辨别方法只有一个：做了之后，下个冲刺同类型的 P 是否不再出现。即使执行率高，如果只是执行了作业和愿望，做法改变的数量仍为零。

 应该如何回答上司呢——对“没有规定”这一观察，可以直接赞同。不同之处在于规定从哪里来。瀑布模型通过流程表和开发标准一开始就为我们决定了“什么时候、谁来写什么”。Scrum 如第2回所讲，没有定义“如何开发”。取而代之的是，将决定做法的权限和责任交给团队，而回顾会议就是制定规定的场所。如果回顾会议不能产出规定，这个团队看起来就比从流程表里得到规定时更不可靠。在上司眼中，确实是这种印象。不过，回到瀑布模型也不等于解决问题。如第3回所述，按流水线写的设计书只能反映编写当时的状况，“没有文档”只会变成“有文档但已过时”，遇到的问题本质并不会改变。而流程表中的规定只能在一开始制定一次，而回顾会议的规定则可以在每个冲刺中修正。
 因此可以这样回答：“您说得对，目前的回顾会议确实没能制定规定。我们会把相当于设计阶段的内容作为完成的定义，由团队自行定义。从下个冲刺开始，我们将按类型统计遗漏，并逐一改进机制。”上司的指摘，作为外部审查，反而是有用的。

 为什么会误以为“产出并执行就起作用”——因为在导入初期，这样确实能奏效。刚开始的团队有许多“明显的浪费”，只要捡起来就能见效。只消除一个事件，团队就能让人看得见地变好。这种成功经验将“产出并执行”固化为回顾会议的模式。当所有明显的浪费都被捡掉后，剩下的问题都是根植于机制层面的，此时相同的模式就会开始空转。另外，大多数成员在 Scrum 之前就已经掌握了“反省会”的方式——举出问题、决定位负责人、以“今后注意”结尾的惯例。并不是有人偷懒，只是把旧方式灌输进了新容器。

 那么回顾会议本应是用来做什么的时间呢？上回我写到，Scrum 的核心是经验主义，其支柱是透明性、检验、适应三个方面。如果说每日站会是“今天的行动”之外的每日小循环，那么回顾会议就是“团队做法”的冲刺级循环。
 透明性——以事实而非观点来展现本次冲刺发生了什么。包括目标的达成情况、遗留与插入项的数量、等待时间，以及“同一类型的 P 出现了几次”。便签只有在这些事实为基础上被解读时才有意义。
 检验——将事实与冲刺目标和完成定义相对照，找出反复发生的现象及其产生的做法。区分单次的遗漏和机制层面的问题就在此环节完成。
 适应——决定要改变一个做法，定义负责人和完成条件，并将其纳入下一个冲刺的计划。变更本质上是一个假设，能否奏效将在下次回顾中验证。

 将上述三点作为标准，就能看出提问者的回顾会议缺了什么：有了事件的透明性，却没有检验环节来发现重复出现的现象，也没有将改变做法的适应事项纳入计划。当务之急是将回顾会议从“消除事件的会议”转变为“改变一种做法的会议”。本文的处方正是为此而设计的步骤。

 另，スクラムガイド2017 中有一句话：“在上次回顾会议中确定的改进事项至少要包含在下一个冲刺待办中”。スクラムガイド2020 已删除了这句话，但我认为，回顾会议的产出物应当是被纳入计划的做法变更，而非仅仅是议论意见，这一主旨至今仍然是有效的指导原则。

 以下列举的都是工具。正如之前所指出的，如果只是照搬形式、满足于“看起来做到了”的感觉，只会再多出现一种手法遍历型。请在尝试后，通过检查做法改变的数量以及同类型的 P 是否减少来验证效果。

首先，统计过去 3 次 P 按类型的出现次数
 在动手之前，用数字来呈现现状。请将最近 3 次回顾会议的 P 按“文档类”“测试类”“传达遗漏类”等类型进行归类，并数一数相同类型各出现了几次。同时，也统计这期间产生的 Try 中，有多少条是改变了团队做法（流程、标准、渠道、工具）的。在大多数团队里，前者会是“3 次都出现”，后者则是“0”。仅凭这两个数字，就能把“感觉回顾会议没起作用”转变为“同类型的 P 已连续出现 3 次，做法变更为 0”这一事实，也能直接向上司说明。

（1）区分单发事件与重复事件
 当所有便签都贴出后，讨论开始之前，先由全体成员进行分类。首次发生的单一遗漏直接归入待办列表，不再在回顾会议中讨论。只将那些重复出现、且可能由机制原因导致的事项留作议题。让“这是第一次发生吗？以前出现过吗？”成为主持人的开场常用句。

（2）统一 Try 的粒度
 在从保留的议题中制定 Try 时，过细的需提升一层，过粗的需降低一层。“制作◯◯文档”就过细，应追问“因为没有它，谁在什么方面遇到了困难”“这本来是谁在什么时候负责制作的”，并将其提升为修改完成定义或检查清单。“改善沟通方式”则过粗，应追问“哪些信息该何时从谁传递到谁”“这些信息目前通过什么渠道”，并将其降为调整渠道。上次看到的兼职成员时间声明，就是将“加强沟通”降到正确粒度的一个例子。合适粒度的 Try 能明确“何时、谁、做什么”，且可判定是否已执行，并通过同类型的 P 是否减少来衡量效果。

（3）将 Try 精简为 1 条，纳入待办列表
 将统一了粒度的 Try 精简到仅 1 条。与其说“有 5 条等会儿要做”，不如说“下个冲刺务必完成 1 条”。为选定的这一条指定负责人和完成条件，并作为正式条目添加到产品待办列表，在下个冲刺的计划中选择它。将改进从“回顾会议中的一时之意”升级为“规划中的工作”，这是阻止重播型出现的最关键一步，也正是回顾会议的“适应”环节本身。

    图3：需要改变的不是事件，而是做法的齿轮

（4）回顾会议一开始，就从“上次 Try 的后续情况”开始
 将议程的第一项固定为：上次的 Try 是否执行了？同类型的 P 是否减少？如果未减少，是粒度不合适，还是没有执行？仅仅这 5 分钟，就能向团队传达“不会做完就扔在一边”的信号，且每次都在此处更新改进的执行率和做法变更的数量。

（5）让 SM 的提问从关注事件转向关注做法
 成员的视线若不加引导，往往会聚焦于事件本身。Scrum Master 的工作就是用提问将视线转到做法上。以下列举几个可用的提问：

• “这是第一次发生吗？在过去 3 次回顾中，同一类型的 P 出现过几次？”
• “因为没有它，谁在什么方面遇到了困难？”
• “执行该项的步骤写在完成定义或检查清单的哪里？”
• “下周，由谁以与以前不同的方式做什么？”
• “如果将相同情况放在另一个人身上，会有不同结果吗？”
• “这次成功是偶然，还是因为我们做了什么改变？”
• “做了这个，同一类型的 P 会在下个冲刺消失吗？”

 相反，请避免问“为什么没做？”、“谁负责的？”、“下次怎么做？”。这些问题只能得到“我会注意”的回答，会将视线重新带回事件和个人。

（6）以可视化形式向上司展示做法变更
 这是对被告知“是不是用瀑布模型更好”的团队的处方。将在回顾会议中决定的做法变更列成一览表，如完成定义的修订、接收渠道的变更、检查清单的补充等，并标注“同一类型的 P 从几次减少到几次”。若能让上司看到团队正在自行制定规定，那么其质疑就会从“是不是没有规定”转向“下一步要制定什么”。上司也应关注这份列表及减少情况，而不是设计书的页数。团队制定规定的能力，就体现在这里。

（7）如果仍然陷入僵局，就转换视角
 在（1）〜（6）环节已开始运转的基础上，可以尝试主题型回顾（本次仅针对质量）、时间线回顾等手法的变化。请不要弄错顺序：如果“产出后的处理”方式不变，仅改变“产出方式”，也会在几次后回到原点。

 长期以来，“什么时候、谁来写什么”这种规定都是由流程表和开发标准从外部赋予的。让团队自行决定做法这件事，在许多现场都没有经验。Scrum 将这份工作交给了团队，但也并不意味着接手方已经得到充分训练。因此最初阶段团队会通过捡起“明显的浪费”而获得成功，等到所有浪费都捡完后，便无法进入决定做法的阶段而停滞。这时，外部观察者会想起能够提供规定的旧方法，并说“那就用瀑布模型吧”。这样的问答会在每个世代更迭时不断重复。

 回顾会议的价值不在于产生的便签数量，也不在于 Try 的消化率，而应当以团队做法改变了多少来衡量。在此次回顾会议中，是否改变了一项做法，并将其纳入下一个计划——只要确认到这一点，就能判断回顾会议是否在发挥作用。只要有了这个标准，回顾会议就不会出现“无话可说”的情况，因为在团队变得完美之前，总能找到无限的做法可以改变。而至今，我至少还没有见过完美的团队。

下次： 「冲刺评审中利益相关者不再来」