书评与访谈：Fifty Quick Ideas to Improve your Retrospectives-InfoQ

Tom Roden 和 Ben Williams 合著的《Fifty Quick Ideas to Improve your Retrospectives》这本书，旨在帮助人们从回顾和持续改进行动中获得更好的成果。这是50 个快速创意系列丛书的第三本，其它两本是《Fifty Quick Ideas to Improve Your User Stories》和《Fifty Quick Ideas to Improve Your Tests》。

InfoQ 有幸采访了 Roden 和 Williams，采访内容涉及他们为什么著作这本书，他们是如何描述这些创意的，什么时候应该进行回顾，为了建立安全主持人需要做什么，为什么主持人不应该成为解决问题的人，庆祝成功，完成行动的良好实践，团队从回顾中获得的价值。

InfoQ：已经有好几本出版了的关于敏捷回顾的书。什么使您决定继续著作这本的呢？

Roden：目前已经有数本关于回顾的伟大著作。我们希望通过 50 个快速创意让大家看到与之前接触的书籍或网站稍微不同的观点。对我们而言，我们已经经历和促进了数百场回顾，已经搜集了许多的创意。过去的很长一段时间，我们已经试验了这些创意，并进行了记录，检验了他们在不同情况下工作的好坏程度。同时，我们也将其中许多的创意施加给 Scrum Master，指导他们，让他们走的更远。

在本书中，与专注于流程步骤和格式相比，更多的是对使练习、技术和格式起作用的背后的原则的探索。这种探索允许我们描述更多的通用规则，技巧和模式，用于改进回顾成果。这些都是实践创意，可以用来解决我们在回顾过程中和持续改进过程中遇到的问题。除了这些伟大著作，我们看到许多团队仍然在回顾中挣扎，希望从回顾中获得切实的良好的结果，并且经常在中途放弃——我们希望这本书能够给他们带来信心，从而更好地提高他们。

Williams：正如 Tom 所言，对我们而言，我们已经促进和经历了数百场回顾，但是有时我仍然感到悲伤。我觉得许多团队没有发挥出他们全部的潜能，或者更糟糕的是他们脱离了要点，认为回顾这种创意根本就是一种浪费时间的方式，或者更糟糕的是讨厌参加这种回顾。经过思考之后，我得出了一个结论：这种脱离主要起源于缺乏对他们“为什么”这么做的欣赏。这种欣赏不是简单的“我们为什么要回顾？”而是更具体的“这部分的流程是什么和它会达成什么样的成果？”即使有人一字不差地执行了回顾流程或者创意的步骤，他们也不一定能够传达流程为什么是这样。通过这本书，我希望能够帮助揭露我们每个创意中的“为什么”。一旦人们理解了“为什么”，他们就可以进入我们的“如何使它工作”章节，并将其应用到他们自己的环境中，而不是一字不差地从字面上遵循。

InfoQ：正如标题所列，这本书有 50 个快速创意。您是如何描述它们的？

Williams：与 50 个快速创意系列丛书中其它书一样，这些创意都基于同一个格式，首先是一个简短的章节将问题抛给读者，随后紧跟着是如此做的好处，最后是“如何使它工作”的实践。这本书的宗旨是帮助那些希望利用回顾改进他们工作方式的群体。这意味着，这不仅仅是为职业主持人著作的一本书，同样适用于那些缺乏奢侈的专门的 Scrum Master 指导的团队成员。因此，我们试图帮助人们理解有效回顾的构建模块，以及他们为什么如此重要，而不是记录方法目录，让人们依葫芦画瓢。通过这么做，我们希望增加人们信心，基于他们自己的工作环境，设计他们自己的方法。

Roden：当我们开始写出这些创意的时候，根据我们的经验，自然而然就提出了哪种创意对应可以解决的问题，在实践中为什么这种创意和技巧能够工作。《50 Quick Ideas to improve your User Stories》这本书的格式是经过精心安排的，为了使它们排列整洁，最后我们决定用同一种格式。

我们在描述创意时主要考虑的是为实际遇到的问题提供一个合适的环境，然后结合我们经验中的实践建议，设计创意，使其成为一种可能的解决方案。这样做的目的是，当重点解决具体问题时，人们可以将此书作为一个参考，他们可以发现方法，试验方法，找出在他们环境中，能够适用他们处境的方案。

InfoQ：您觉得团队应该什么时候进行回顾？

Roden：在 Scrum 一统天下的形势下，何时主持回顾会议的常规答案通常是“每次迭代之后”。然而，现在随着越来越多的团队使用 Kanban，ScrumBan 或者其它一些“post-vanilla-scrum”方法，“每次迭代之后”已经不是一个明显的答案了。随着团队越来越成熟，对持续改进越来越得心应手，有其它方法可以用于安排回顾会议。

对于大多数采用敏捷实践的团队而言，每两周或者四周反映并寻找改进，这是一个革命性的转变。对于大多数团队而言，在 Scrum 中，不论你是否放弃评审和规划流程，这都已经成为了一种标准的实践方式，因此还出现了一种保持相同规律节奏的争论。并且许多团队成员很享受这种规律的心跳，强调这种连续工作流程的重要性。

虽然没有必要将回顾会议固定节奏。但是越接近你评审事件发生的时刻，它们在你脑海中就越清晰。所以为什么非要等到两个星期后才处理他们呢。持续改进意味着通过基于特定类型事件的触发主持回顾会议，随时检查和调整。例如，如果你有一个生产事故，应该立即举行一个根源或者“5 个为什么”会议。或者当你完成一个特别难以交付故事时，立即回顾难以交付的原因。

Williams：Ben，这是一个很好的问题。一直以来，我们都认为除非人们花时间去理解回顾的基础，他们才能正确地将回顾看成是 Scrum 中强制执行的一种仪式。通常这类会议可以塞进评审和规划之间，但是由于时间紧迫，多少会影响团队的提高。

书中的几个创意都是冲着“持续改进”和“按需回顾”这样的终极目标而去的。我觉得自己一直很幸运，能够与很多已经达到这种终极目标的优秀的团队共事。通过回顾降低成本，他们能够接受回顾，将此作为一次低成本的学习机会，并且离发生问题的时刻越近，这样的回顾就越能够即刻完成。我们的宗旨是“不要分批处理你的回顾”。

InfoQ：回顾中的安全是非常重要的，它能够让人们随意表达心中所想。您能给出一些案例，为了建立安全，主持人可以实施哪些措施吗？

Williams：Norm Kerth 的最高指导原则是一个很好的出发点，并且在某些形式下我仍然倾向于使用。我发现，在回顾的一开始，将其当做意向声明使用，并且在固定团队和主持人之间反复强调，这在一定程度上可以建立一个正确的思想状态。安全源自信任，并且记住“建立信任需要很多年，摧毁信任却只要几秒钟”，因此任何主持人不应该在未经许可的情况下与他人讨论回顾的内容。哦，当你离开回顾会议时，你要特别注意将回顾的内容从墙上拆下来，我们不想将我们的私人想法公示于众。

Roden：正如 Ben 所言，最高指导原则永远是一个有用的工具，尤其对新组建的团队或者处于转型的早期阶段的团队。但是，有时为了营造一个建设性环境，在这种环境下批评性的反馈可以在良好精神风貌下提出并被接受，这时我会对它进行补充。虽然这是一个敏感的领域，但是我认为安全同样意味着创建一个大家可以自由表达意见的环境，即使是批评性的意见，这是一个如何以一种合适的善解人意的方式激励大家的问题。如果这些意见没有及早地浮现出来，而是在下面不断升级，那么最终会以一种更加爆炸式和破坏式的方式迸发出来。如果不幸发生了这种情况，那么它将阻碍洞察和领悟，从而阻碍改进。

我曾经与这样的一个团队一起工作过，他们接受了一个实验性项目，对所有的一切都持有开放态度，认为不去尝试新鲜事物就无法学习新东西。他们回顾的座右铭是 Pepper slogan 博士的“可能发生最糟糕的事情是什么？”通过添加一些滑稽和轻松自然的东西，他们尝试创建这样一种环境“即使创造出来的新事物无法正常工作也是无关紧要的”。

对房间温度的检查可以衡量安全，要求人们（可能是匿名的）对表达他们真实想法和感受的舒适程度进行投票。一个简单的 1（对目前的讨论方式一点都不舒服）到 5（乐意公开讨论）可以作为会议上感受的一个很好的表现体。破冰行动和热身练习有助于更好地提高人们的参与度，并创建一个更加开放、建设性的环境。

然而，安全的根源在于对他人如何使用这些意见和反馈的信任。如果人们对反馈抱有防守和侵略性的态度，或者如果团队以外的人按照反馈行事，那么安全将会大受打击。正如 Ben 所言，这之后再建立安全将会花费很长的时间。

InfoQ：您在书中提到主持人不应该成为解决问题的人。您能解释一下这是为什么吗？

Roden：这里对 Scrum Master 和主持人的作用存在着一定的分歧。一方面，人们认为他们应该帮助疏导团队，消除障碍，帮助团队专注于交付。另一方面，人们认为他们应该帮助培养自组织团队，而这种团队不需要外部的支持。

如果 Scrum Master 总是在帮助团队解决问题，移除障碍，那么团队可能会丧失或者不能开发自己的这种能力。而这增强了团队对外部支持的需求。

所以，与直接帮助团队解决问题相比，主持人应该传授自己解决问题的技能和方法。

Williams：这是一个有时会被忽略有趣且微妙的问题。很多时候，Scrum Master 也是回顾会议的主持人。他们负责移除妨碍者，不幸的是我们已经看到这正被团队和 Scrum Master 滥用。在这一点上，默认地将所有问题移交给 Scrum Master 的做法并不少见。将这种问题移交并将潜在的瓶颈引入具有一定的破坏性，因此当我们考虑创建团队时，通常希望团队成员由那些为了“完成”产品可以付出一切的人组成。将问题移交给专家具有一定的破坏性，在许多环境下，产品从构想到上市所耗时间是最重要的竞争优势，因此在这种情况下，没有任何区别。不幸的是大部分工作系统运作的方式是，使人们认为资源的利用率是他们应该考虑的最重要的事情。这就导致了直观的行为：过度使用和开发那些昂贵的开发资源。如果我们认真对待反馈，通过更快地提供可持续的交付，提供快速反馈，我们就需要赋予团队自己解决问题的能力，而不是仅仅将它们移交给专家。

InfoQ：我经常向团队建议，寻找进展顺利的事情，并为此而庆祝成功。您同意这种做法吗？您能分享一些您共事过的团队真正实现了这一做法的案例吗？

Roden：当然同意。庆祝成功似乎被许多人忽略了，但是在适当的情况下，它可以成为一种动力，兴奋剂和建立关系的方式，在这一方面我跟 Ben 的意见完全一致——考虑到在构建产品的过程中，已经充斥着足够的汗水和泪水，试验和错误，因此团队应该对庆祝成功这种方式感觉良好。

当然，这需要注意一些社会方面的因素。包括邀请正确的观众，不要遗漏任何一个重要的观众，并在某次有意义和成功的发布或者业务里程碑之后庆祝成功（不是当支援的团队在生产环境中忙于救火的时候）。

我发现一个特别有趣的现象，对那些更深入地实施持续交付模型的团队，如果你有一个干净的构建，那么你可以在任何时候发布软件。我曾经在这样一个团队工作过，我们决定将我们的庆祝活动跟关键影响因素相结合。我们在内部设置了目标（业务和团队）和里程碑，当我们达到一个里程碑时，就有一个小型庆祝活动（通常是一个可口的午餐或者前往酒吧）。当我们完成一个更大的目标时，很幸运我们完成过几次，我们会做一些更具奖赏性的事情，我记得我们玩过一次卡丁车，有过一次欣赏 London 美景的郊游，和品尝过一些很不错的牛排。我发现了一个特别有趣的方面，通过这种达到里程碑的庆祝方式，我们获得了更多的能量，更好的专注于我们的交付，简简单单的只要有目标能够激励我们，几乎可以游戏化我们的工作。

Williams：完全同意。这样的一个学习的机会可以用来评估哪些我们完成的很好，和在未来我们想重现哪些。我曾经与一个金融服务公司的团队合作过，仅仅数个月后，他们就已经向客户交付了足够的功能了，并且达到了里程碑式的影响。他们正在交付一个端对端的期货处理系统。在庆祝活动中，我做了一些研究，并安排了大家下午离开办公室后的行程，首先，我们去伦敦金属交易所参观了最后一个公开喊价期货交易大厅，接着在公园我们趁机对此次交付进行了重点的回顾，然后前往办公室附近的一个酒吧，开始庆祝成功。

InfoQ：回顾的真正好处应该来自于改进行动。您有用于完成行动的良好实践吗，您愿意跟大家分享一下吗？

Williams：首先，我们不应该忽视这样的一个好处，从某个级别的回顾中，仅仅通过赞美他们已经成功实现期望这种事实，就可以让人们以更好的方式工作。也就是说，是的，我同意最大的好处来自于改进行动，但是不幸的是，当遭遇交付的压力时，美好的愿望通常会被打碎。在这本书中，我们有很多的方法可以帮助人们坚持到底。让改进思路成为头等公民是重要的第一步。实际上，它跟在你的团队白板上将其设置成最高等级的故事一样简单。另外，分配改进思路到每个人，让他们有具体的任务可以执行，这将会鼓励人们对其投资，而这是他们的回顾。

Roden：我真的非常喜欢 Ben 前面提到的创意，将你选择的改进思路放在白板的顶部。所以，常常即使团队写下行动甚至将它们添加到白板或者积压的事务中，他们仍然没有完成这些行动。这或许是因为，虽然希望让大家看到，从而以某种方式得以完成，但是他们一直在冲刺优先事项的最底部，从来没有达到或者提交到某种后台任务泳道。首先完成它们，承诺它们如此重要，真的可以改变动态，同时确保选择合适它们的时间。

另一个有用的技巧是评估和排列改进项目，就像你评估和排列任何其它的用户故事的商业价值一样。这样做允许更开放的交谈，并且当这么做时往往会让产品负责人惊讶，因为利用这种改进成果可以提供巨大的好处，尤其是在较长的时间跨度内。

InfoQ：您能详细说明团队能够从回顾中获得什么价值？是否可以衡量这种价值？

Williams：我们发现，通常随着团队获得更多的经验，通过分析，他们同样能够实现更加科学化。从这个角度来看，形成一个改进思路，并对其进行试验，同样有助于衡量和描述回顾和后续改进思路的价值。将改进思路设定成一个试验和假设，这种做法自然而然地描述了团队希望达到的价值并且这种试验的度量指标将有助于描述价值的进展。例如，与其说我们将会自动化我们的验收测试，不如说我们可以设定成“我们相信，如果我们投入 2 个人，为期 2 周，我们可以自动化我们 60% 的回顾测试包，而这又会节省我们 12 个人的工作量，并且将我们下次发布时间提前 3 天”。现在价值就很明显了，12 个人的工作量，并且将我们下次发布时间提前 3 天。我们可以看到这个提议花费了 2 个人，为期 2 周的工作量，并且我们甚至在下次发布之前有一个可用于测试的临时验证点。在这种情况下，我们可以判断 2 周后有多少回归测试包实现了自动化。

通常团队回顾倾向于关注人们在一起工作的好坏程度，常见的衡量价值的度量指标往往是那些基于周围的工作量和节省的工作量。然而，考虑描述更快地交付，减少生产周期（从接收订单到完成订单的时间）这种度量指标，将是一个很好的替代方案。

Roden：我认为在某种程度上你可以衡量任何东西，所以，是的，我认为可以衡量回顾带来的价值。

许多不同的方式方法都可以带来价值，我喜欢思索一种混合的度量指标，同时使用整体性以及任何更多的局部度量指标来衡量具体的改进行动。例如，如果你想实现一个想法，在零碎的基础上开始提炼用户故事，一次一个，你可能选择从未丢弃的已经提炼好了的故事中衡量减少的浪费量。你可能还会选择衡量故事整体的交付周期提高了多少，甚至在提炼的下游你都没有创建一个更加糟糕的瓶颈。

另一个回顾带来的价值体现在工作关系上，互相理解和尊重。这些对积极性有着最重大的影响，并且这种影响又会影响最终结果，这是他们不应该忽视的。同样可以衡量这些“更柔软”的方面。我曾经跟这种团队合作过，为了发现在哪种情况下，我们的工作效率最高，我们衡量过团队成员的幸福度，积极性，打断和交流。

关于受访者

Ben Williams是一位教练、顾问和转型专家，也是《Fifty Quick Ideas to Improve your Retrospectives》一书的作者。他帮助组织切实地、更快地交付真正的商业价值。Ben 通过对广泛的工具、技术以及经验的运用，对许多团队与领导进行了教练工作，以评定及精炼他们的工作系统。通过对敏捷及精益学科，例如Scrum 和看板的运用，Ben 曾多次以教练及仆人式领导的身份参与驱动激进的、大规模的敏捷转型的过程。他在英国及全球范围内经常举办演讲，在敏捷测试日2014 大会上也是最受好评的主题讲座演讲者之一。可以通过@13enWilliams 在twitter 上找到他。

Tom Roden是一位软件交付教练、顾问，以及质量保证的狂热支持者，也是《Fifty Quick Ideas to Improve your Retrospectives》和《Fifty Quick Ideas to Improve your Tests》的作者。Tom 与各种团队和人们密切合作，帮助他们做出必要的改变以获得成长，并且学会适应他们的环境所要求的各种变革。他与这些专业人士共同协作以交付高质量的软件，同时也保证了速度与弹性。也通过受敏捷与精益原则影响的流程与实践的精练支持进行中的改进任务。Tom 的专长是敏捷转型以及质量保证，他的经验涵盖了管理、策略、实践者的研究方法乃至各种技术，以帮助团队与组织持续地进行改进。他在英国及全球范围内经常举办演讲，在敏捷测试日2014 大会上也是最受好评的主题讲座演讲者之一。