[Day16] 检讨会议这样开，就可惜了

我认为整个 Scrum 架构中，对系统以及最终的自组织目标，最重要、最有价值的一场活动，就是检讨会议 (Retrospective)（後简称 Retro)。但是，Retro 也是我认为最难开，最难主持的的活动。常见的低效益 Retro 有以下的特徵：

1. 热烈的讨论公司与产品方向
2. 成员们轮流互相感谢
3. 针对 Sprint 遇到的问题，制定新的工作规则

本篇不深入的探讨如何进行 Retro ，网路上有很多大神的文章已经钜细靡遗的阐述过这个主题，自忖写不出什麽新意。我从管理的角度，来讨论为什麽上面描述的特徵会带来低效益，以及改善建议。

讨论公司和产品方向，错了吗？

除了两次不好的职场经验外，有三个让我尊敬 CEO，都有一个共同的特色：乐意聆听团队成员的意见，并鼓励大家思考。所以，这个命题的答案并没有错，有问题的是讨论的场合和心态。

Retro 既是 Scrum 开发系统（流程）的一环，它的讨论重点就应放在系统／流程本身。Scrum 的远景在於将团队发展成「自组织」(self-organization)，在「系统思考」一书中，有这样的描述：

系统通常具有自组织的特性，具有塑造自身结构、生成新结构、学习、多样化和复杂化的能力

Scrum 团队系统要发展成高效、成熟的自组织，在 Retro 中讨论公司与产品方向，显然无法达成目的。黄大米有一篇文章「月薪没有 20 万，你真的不用操烦到公司营运」，常常被我拿来当作自我警剔的工具：

• 我对这个议题有话语权吗？
• 我目前被交付的任务是制定公司策略，还是落地执行？

这是角色与责任（R&R）的基本认知。在错误的场合，用错误的 R&R 认知进行公司策略等级的讨论，讯息缺乏向外传递的「介面」，久而久之，团队成员容易落入一种「说这麽多干嘛，反正老板也不会听」的低潮情绪；而且，在缺乏充份的市场、经营资讯下的讨论，也难以形成改变公司决策的提案。

我的建议是：透过在 Retro 中有效的引导，让团队不断的针对系统／流程问题进行修正，进而形成互信、默契与文化，才是培养自组织团队的正确方式。

对夥伴充满感谢，错了吗？

畅销书「被讨厌的勇气」里面提到：人在被感谢的时候，会明白自己对他人有贡献，进而感受到自我价值。因此，这题的答案，依然是：没错。但问题在於整场 Retro，大部分的时间在互相道谢，对系统／流程面的问题讨论很少甚至没有，就是大问题。

通常会发生这样的状况，是因为团队不知道该讨论什麽议题，所以用大量的互相感谢来填补沉默的尴尬，但又很容易落入针对团队成员的本份进行感谢，我认为是多余了。感谢的艺术在於「觉察」。如果我们可以发觉某个夥伴，为了合作顺畅，用心与创新的做了巧妙的设计，且提升了团队效能，我们明确又即时的给予回馈，会最大程度的给予夥伴成就感与提升在团队中的自我价值。

举例来说，走味的感谢：

「这个 Sprint ，设计师有准时把图都出好给我，让我也能准时交付，感谢设计师」

「QA 帮我抓到 xx 个 Bug，让我在交付前可以修正，真是太感动了」

带来价值的感谢：

「这次的设计文件，设计师贴心的帮我点出了 xx 元件会在之後的 xx 画面中使用，让我可以朝模组化的方向去设计，节省了我下次的开发时间，对我帮助好大。」

「QA 这个 Sprint 在开发前，特地提醒我他在之前的经验中，发现某处要小心 xx 可能的问题；有了这个提示，我在开发中特别留心，发现真的如此，进而做了 xx 设计，让我这次的开发的品质提升了」

好的感谢，除了带来自我价值的肯定外，也能让其他的团队成员了解：「原来，这样做，就可以帮助到整个团队啊！」以此形成一个积极向上的正向循环。

制定规则，错了吗？

在以生产为主的企业中，有一个专有名词：稼动率。意思是设备在所能提供的运转时间，为了创造价值而占用的时间百分比。为了提供生产效率，操作设备的工程师或作业员就必须减少错误的发生。人类的判断充满了杂讯，为了避免现场业人员的判断出错，就必须制定规则，或是标准作业流程。一旦面临标准作业流程规范外的状况，就必须停下来，由更高层的主管在作业流程中新增规则。现场人员无法自行决定如何排除问题，这就是所谓的无法自我修复的系统。

在脑力密集产业，产出与时间，无一定的正比关系。我们需要的是弹性与启发创造力的环境。订规则固然是解决协作问题的最小阻力之路，但时间一长，我们就会发现到叠加的规则愈来愈多，然後就忘记了。

有什麽事情是不能每天在站立会议上沟通一下就解决的呢？廻避沟通的团队，就算有再多的规则，也无法成为 A team。我是建议是：放下规则，拥抱原则。

有关高效检讨会议的开法，「精实咖啡」（Lean Coffee) 是一个非常好的会议框架，可以看看这篇文章。最後再提醒一句：打造自组织，从充份利用 Retro 开始。