回顾反模式

如果你使用回顾,或者任何人们应该讨论并从他们的讨论中学习的会议,你偶尔会遇到效率较低的会议。这并不奇怪,它发生在大多数人身上。本文描述了三种不幸情况的解决方案,并提供了解决方案:跳过生成见解、迷失在无法改变的事情中以及被大嘴巴主导。

2023 年 2 月 15 日


Photo of Aino Corry

Aino Corry 是“回顾反模式”的作者,她是一位教师、技术会议编辑和回顾主持人。她拥有计算机科学硕士学位和博士学位。她还教授如何向教师教授计算机科学,因此不负其公司名称;Metadeveloper。Aino 曾居住在斯德哥尔摩、隆德和剑桥,但她现在回到了丹麦的奥胡斯,在那里她和家人以及不断增长的毛绒头足类动物收藏一起生活。在她的空闲时间,她跑步和唱歌(但不是同时)。


回顾的概念几乎一直存在,但并不总是叫这个名字。只要人类存在,我们就一起回顾过一项活动,试图从中学习。在狩猎之后,在出生之后,在游戏之后,在手术之后,等等。

Norman Kerth 是第一个在 IT 界将它命名为“回顾”的人,在他的书中:项目回顾 - 团队审查手册,出版于 2001 年。他描述了一种正式方法,用于保存从每个项目的成功和失败中汲取的宝贵经验教训。这本书以详细的场景、富有想象力的插图和循序渐进的说明,开始了我的回顾主持人之旅。我喜欢这个想法,我开始实施它,首先是在我自己的团队中,然后是在其他团队中,后来是在我的组织之外。“首要指令”“制定时间线”“我太忙了”和其他活动都来自他的书。

后来,Diana Larsen 和 Esther Derby 撰写了这本书:敏捷回顾 - 让优秀的团队变得更出色。这引入了更短的回顾,可以适应敏捷流程。这对我是个改变游戏规则的东西。他们的书帮助我计划更短、更高效的回顾,但也包含了主持人工具,帮助我以更有效的方式规划回顾的实际过程。

在 Norm Kerth 的书之前,我们只知道事后分析。这些是在出现问题后进行的更长时间的反思。事后分析作为从错误中学习的工具非常有用。如果做得好,它们可以对相关人员产生治愈效果,但与回顾不同。我们进行回顾,即使事情进展顺利。这就是 Derby Larsen 的书的副标题是“- 让优秀的团队变得更出色”的原因。

但是,我对回顾的实际经验也向我展示了回顾很容易变得效率低下。如果你不遵循回顾的想法,只是走过场,你会浪费时间。由于敏捷方法的流行,回顾变得非常普遍。这种成功已成为回顾的一个问题。每个人都必须进行回顾,但他们没有花时间学习如何以正确的方式进行回顾。这导致了许多非建设性的,有时甚至是有害的回顾。当人们声称回顾是浪费时间时,我经常同意他们的观点,当我听到他们是如何做的时候。几年后,我开始注意到事情出错的模式,包括我自己主持的那些。

来自丹麦的故事

一个组织决定在软件开发方式上更加敏捷。作为其中的一部分,他们引入了回顾作为一种学习手段。一些团队成员觉得回顾“妨碍”了“真正”的工作。他们建议回顾可以比为它们预留的 90 分钟更短。由于主持人对回顾不太熟悉,她决定接受。

为了尽可能少地花费时间,他们缩短了回顾。这带来了许多负面后果。让我们在这里关注一个,我称之为幸运之轮[1]的反模式。在现实世界中的幸运之轮中,你有时会获得奖品,有时会输掉。赢或输是随机的,你没有做任何事情来提高胜算。这也会发生在团队的回顾中。

主持人决定使用流行的“开始、停止、继续”活动来收集数据。但为了节省时间,他们跳过了生成见解,这是回顾的 5 个阶段之一。相反,他们从收集数据跳到决定开始做什么、停止做什么以及继续做什么。

对于这项活动,主持人贴出了三张海报,一张写着“开始”,一张写着“停止”,一张写着“继续”。然后她要求团队写下便签,并把它们贴在海报上。其中一张便签写着“开始结对编程”,另一张写着“停止开那么多会”。团队可以从这些便签中创建行动点:“每周三天,结对编程三小时”。以及“周三不开会,午餐后不开会”。20 分钟后,回顾就结束了!

这种回顾方式会带来严重的后果。如果便签只显示了症状的解决方案,而不是实际问题,你只能解决表面问题。也许团队没有进行结对编程的原因不是他们忘记了,而是缺乏心理安全感。在这种情况下,强迫他们在日历中安排结对编程不会有任何帮助。要么他们仍然不会做,要么他们会做,人们会感到不舒服并离开团队,甚至离开公司。

另一个没有进行结对编程的原因可能是他们不知道如何在远程环境中进行结对编程。同样,这是一个无法通过在日历中安排结对编程来解决的问题。

关于会议的便签也是如此。会议的问题可能是质量而不是数量。在这种情况下,减少会议次数并不能解决问题,只会让问题不那么明显。当团队要求减少会议次数时,通常是改进会议卫生可以解决真正的问题。

幸运之轮

当一个团队“解决”症状而不是问题时,问题仍然存在,它们会再次出现。就像在真正的幸运之轮中,他们可能会走运。也许他们解决的一些事情可能是真正的问题。但我们通常只看到症状,我们急于找到“解决方案”,而这些解决方案没有解决根本原因。结果是,即使这些简短的回顾也感觉像是在浪费时间,因为仅仅讨论和应对症状是在浪费时间。

反模式必须有一个重构解决方案,即对比反模式解决方案更好的解决方案的描述。在本例中,重构解决方案是确保在决定要做什么之前生成见解。在你得出结论之前。你可以通过简单地讨论出现的问题来做到这一点。或者通过“5 个为什么”访谈。如果看起来像是一个复杂的问题,一个鱼骨分析可能会有用。复杂问题的例子是“错过截止日期”或“没有遵循同行评审流程”。这样说起来很简单,但简短的描述隐藏了复杂性:这些问题可能有很多不同的原因。

陷入困境

在接下来的回顾中,出现了另一个反模式。团队想要讨论供应商提供的糟糕软件的影响。这种软件的质量一直是团队的一个持续问题。他们自己的软件系统受到很大影响,他们试图将问题升级给管理层。团队之前多次讨论过这个问题。每次他们讨论这个问题,他们都会感到沮丧和悲伤,但没有任何改变。这使得回顾感觉像是在浪费时间,因为它确实是在浪费时间讨论他们无法改变的事情。这是一个陷入困境的反模式的例子。

当你陷入困境时,你把时间花在无法改进的事情上。而不是学习和改进你能改变的问题。

重构解决方案是使用一项名为陷入困境的活动,你要求团队将他们正在讨论的事情分成他们可以做些什么的事情、他们可以影响的事情以及陷入困境的事情。当事情陷入困境时,它们是你无法改变的生活的一部分。你最好把时间花在接受和找到适应这种情况的方法上。或者通过摆脱困境来改变你的处境。你可以在收集完数据后立即使用此活动,如下所示。或者你可以在决定要做什么时使用它,以避免在回顾中留下你无权实施的行动点。

In the Soup activity               during Gather Data

图 1:我们可以做的事情、我们可以影响的事情、陷入困境的事情。

大嘴巴

在这个团队中,他们现在知道如何将时间集中在他们可以改变的事情上,他们也了解了将时间花在生成见解上是多么有价值。但他们仍然有一个问题。他们在团队中有一个大嘴巴。在回顾中的所有讨论(以及所有其他会议)中,这个大嘴巴都会打断别人,讲长篇大论,让其他团队成员无法参与。主持人试图邀请其他团队成员发言,但情况没有改变。

这种反模式经常出现,但并不难解决。首先要意识到为什么这是一个问题。有些人可能会说,如果有人有话要说,那么就应该允许他们说,我同意。但对于回顾来说,时间是留给团队共同分享、欣赏和学习的。如果只有部分团队能够做到这一点,那么时间可能部分浪费了。

对于一个有“话痨”的团队,重构的解决方案是避免全体会议讨论。相反,将团队成员分成更小的组别,甚至一对一,进行讨论。你也可以引入更多书面交流和移动便利贴,而不是口头交流。 [2] 在回顾结束后,与“话痨”进行单独谈话也可能会有益。他们可能没有意识到自己对其他人的影响,而且通常他们会很感激能了解到这一点。我曾与一些“话痨”合作过,他们发现意识到这种倾向改变了他们生活的多个方面。有些人被称为“活跃思考者”,他们需要说话或做一些事情才能思考。显然,他们在思考时需要大声说话,但这并非恶意。

在这篇文章中,你已经了解了回顾促进中最常见的三个反模式,并且现在你有一些关于如何避免陷入其中一个反模式的技巧和窍门。但请记住,促进者最重要的技能不是记住很多活动,而是倾听,运用智慧化解冲突,并不断反思和学习什么对他们有效。


进一步阅读

你可以在我的书《回顾反模式》Retrospectives Antipatterns中了解更多关于回顾反模式的信息。这本书介绍了 23 种回顾反模式,每种反模式都描述了促进回顾时遇到的常见挑战,提供了克服这些挑战的实用方法,以及我个人在遇到这些反模式时的轶事。这本书基于我超过 15 年的回顾促进经验,以及超过 20 年的学术界和工业界教学经验。我花了一些时间研究如何教授和学习计算机科学,在这项研究中,我发现了很多关于为什么有些事情在教学和促进方面有效,而另一些事情无效的见解。

脚注

1: 每个反模式都有一个图片和一个名称,以便人们更容易记住它们并意识到它们。它通常是一只章鱼,因为我喜欢章鱼。

2: 有趣的是,这些建议也适用于非常安静的人,因为它们适用于“话痨”。

重大修订

2023 年 2 月 15 日:发布