背景

在一次线上活动的提问环节，观众问了这样一个问题：“我是一名Scrum Master，Scrum在我们团队已经跑了一年多，目前团队表现很好，不过我们在回顾会议上已经提不出改进意见了，我们应该怎么办？”

回顾会议可以帮助团队检视迭代中存在的问题，团队在回顾会议上提不出改进意见，则说明团队很难得到提高。如果团队自身有很多地方有待提高，“回顾会议提不出改进意见”将会是一个严重的问题。

本文就针对这个问题来聊聊“团队回顾会议提不出改进意见了，应该怎么办”。

问题分析

很多团队运行Scrum一段时间后，因为团队运作平稳，回顾会议上提不出改进意见，团队也自认为没什么好改善的。于是回顾会议从一个迭代开一次，变成两个，三个迭代开一次，甚至最后彻底消失。

除了上述情况外，笔者较常见的还有团队因为回顾会议做的不好，无法提出改进意见，表现如下：

1. 回顾会议气氛消极，团队成员不提建议

   回顾会议上团队成员对一个由某位成员引发，明显且对团队有很大影响的问题视而不见；或者在回顾会议上，团队成员不提改进意见，取而代之的是不停地抱怨。

2. 回顾会议不认真回顾，走形式

   团队每次回顾会议都会提出改进意见，可是始终没有看到改进成效，久而久之，团队成员对改进意见看的很淡，回顾会议的存在只是为了Scrum流程的完整，最后草草了事。

3. 改进点太多不知从何下手，索性不回顾

   团队在敏捷转型初期由于经验不足，频繁犯错误。

   回顾会议上，团队将所有问题都事无巨细的罗列出来，然后认为所有问题都需要改进；由于要改进的点太多，团队改善时不知从何下手，最终索性回顾会议不提改进建议。

促成以上几种表现的原因，大致有如下三点：

• 团队自认为已经完成敏捷转型

  团队顺利地达成某个目标或者里程碑，而且在近几个迭代，团队一直运作平稳。因此团队成员认为团队敏捷转型成功，不需要再回顾了。

• Scrum Master在会议上没有做好引导

  团队成员对明显的问题视而不见，通常是怕提出意见后，受到其他成员的打击报复，所以最后不提建议；对回顾会议上一直抱怨的成员来说，他们可能认为通过抱怨让别人理解自己是有效的，相比于直接提出建议，他们更希望通过抱怨这种委婉的方式让团队明白他的想法。

• 团队对改进计划没有很好的跟进

  造成”回顾会议不认真回顾，走形式“和“改进点太多不知从何下手，索性不回顾”的主要原因是改进计划没有很好的跟进。

  改进计划中，大多数要改进的都是团队能力范畴之外的，譬如变更公司管理制度才能奏效的改进，这种改进很难落地，也很难见到成效，最终导致团队觉得提不提改进意见都没啥用；有的改进很好落地，但是团队提出后就认为回顾完成了，没有在后续迭代认真跟进，最后使得回顾会议浮于形式。

  如果计划中改进太多，在后续迭代中很难一一跟进，容易顾此失彼，到最后很可能一个改进也没做好，结果依然是让团队感觉在回顾会议上提意见没有用，浪费时间。

针对以上原因，Scrum Master应该如何解决呢？

解决措施

开篇简单的提到回顾会议的作用，我们再看看Scrum Guide中如何描写回顾会议的。

Scrum Guide对回顾会议的介绍如下：

“Sprint 回顾会议是 Scrum 团队检视自身并创建下一个 Sprint 改进计划的机会。Sprint 回顾会议的目的在于：

• 检视前一个 Sprint 中关于人、关系、过程和工具的情况如何；

• 找出并加以排序做得好的和潜在需要改进的主要方面；

• 同时，制定改进 Scrum 团队工作方式的计划。”

在Scrum中回顾会议是提高团队能力重要的一环。针对“团队回顾会议提不出改进意见了”这个问题，各位Scrum Master可以参考以下措施。

让团队理解敏捷是持续改进

“我们团队已经完成了敏捷转型”——这种做法看似合理，实际上是错误的——敏捷运作或敏捷转型没有“完成”一说，其本质是持续改进。

团队之所以认为敏捷转型完成了，通常是因为团队通过敏捷得到了一定收益或完成了一个目标，团队觉得很满意。Mike Cohn说过：“你不是变敏捷了，而是变得更敏捷了”，软件工程在一刻不停的发展变化，所以团队要不断得“更敏捷”，对应的就要不断的回顾。

当团队认为敏捷转型已经完成了，如何让团队理解敏捷是持续改进呢？笔者推荐两个方法：

第一个方法是“事件时间线”

在白板或者墙上画一条时间线，代表迭代的每一天；团队成员将迭代中发生的认为有意义的事件用便利贴写下，贴到事件发生的日期。这个事件可以是某次集成失败之类的问题，也可以是效率提升之类值得鼓励的事，不同类型的事件可以用不同颜色的便利贴进行区分如红色代表问题，蓝色代表相比之前有提高。

如果迭代中发生的事件太多，团队一时半会想不出来，Scrum Master可以在回顾会议开始前，提醒团队成员去Sprint Backlog中寻找线索（下图为华为云DevCloud的Sprint Backlog），看看这个迭代都做过哪些故事，并从中提炼出需要进入“事件时间线”的事件。

通过”事件时间线“，团队可以清楚的了解到迭代中发生的各种问题，从而促使团队提出改进意见，并且让团队明白，敏捷转型并没有完成，还需要持续改进。

如果团队的“事件时间线”没有问题，应该怎么办？没关系，我们还有第二种方法。

第二个方法是让团队回顾为什么认为自己无法再进步了

或者说，为什么不能再做的更好。这样的问题通常会让团队讨论出一个积极向上的结果，引导团队去理解敏捷是持续改进，应该要追寻更高的目标。

Scrum Master正确引导回顾会议召开

敏捷十二原则中有一条：“团队要定期反省如何能够做到更有效，并相应地调整团队的行为”，回顾会议就是践行这条原则的最好途径。作为Scrum Master理应正确引导团队召开回顾会议，并使团队从中受益。

Scrum Master应当给回顾会议营造一种积极的气氛，并充分调动团队积极性，比如：在会议场地摆放一些水果零食，营造出一种闲聊的气氛（也是对上个迭代团队付出的一种犒劳），让大家放松心态，畅所欲言——会议气氛过于严肃会导致团队成员很难有发言的欲望。

Scrum Master在会议开始前应声明：本次回顾会议上讨论的问题都是对事不对人的，并且应当在会议中，避免对个人责任进行讨论。比如：当团队成员讨论A成员捅了娄子，Scrum应该引导团队去发掘系统中什么原因导致会有成员捅娄子，而不是为什么A会捅娄子。

如果回顾会议经常有人抱怨，Scrum Master可以通过鱼骨图等工具，引导抱怨的成员分析出问题的根因，最终针对根因提出改进建议。如果抱怨是因为其他人（其他团队成员，其他项目组成员等）的原因，Scrum Master可以尝试邀请其参与回顾会议，当面讨论问题，从而提出改进意见。

选择部分可落地的意见改进，并持续跟进

回顾会议上，团队应该选取一部分可落地的，优先级高的改进意见进行改进。比如团队回顾出如下6个改进点：

“调整公司信息安全制度”是团队能力范围之外的，而且信息安全是对公司无形资产的一种保护措施，想调整很难，所以这条改进很难落地，不应当纳入改进计划；

“升级设备”需要公司出钱，意见的落地有很大的不确定性，团队也很难跟进，不建议纳入计划，团队可以将其当做一种诉求向公司申请相关物资；

“每日站会时间长”、“做好估算”、“加强测试”三项改进是相对较容易跟进且比较容易见成效的，所以团队可以将这三点纳入改进计划；

“持续集成”需要搭建应用，而且很可能一个迭代看不出效果，但放眼行业，持续集成确实会给团队带来生产力的提升，所以团队可以将它纳入改进计划，并跟进一到两个迭代——有的改进意见需要持续跟进多个迭代，才能看到效果。

想了解如何让回顾会议更有效果，可参考《如何让敏捷回顾会议更有效果，这样做就对了》一文。

引入外部敏捷教练

• Scrum Master和团队合作时间长，其思维和团队保持一致，发现不了团队的问题，不能很好地引导团队提出改进建议；

• Scrum Master缺乏经验或者能力不足，无法正确引导团队成员在回顾会议上提出改进意见；

这时候，引入外部的敏捷教练也是个不错的选择。

“当局者迷，旁观者清”，外部教练可能很容易的就在回顾会议上引导团队提出合理的改进意见，让团队更上一层楼；同时对缺乏经验或者能力不足的Scrum Master来说，外部教练的介入是一个很好的学习交流机会。

参考附录

《如何让敏捷回顾会议更有效果，这样做就对了》

文章论坛地址：《回顾会议上已经提不出改进意见了怎么办》