站会开成汇报，敏捷就废了

一、站会没死，是你的团队先“演”了起来

2019年我在一家中型SaaS公司带产品团队，每天早上9点15分，12个人围成一圈，对着墙上的看板开始站会。整整四个月，我以为我们在做敏捷。直到有一天，CTO突然站到我身后听完一整场站会，散会后把我叫到会议室说了一句话：“你不觉得他们每个人说话的时候，眼睛都在看你吗？”

他说对了。

那场站会的本质不是信息同步，而是一轮又一轮的微型述职。每个人用30秒向团队Leader（也就是我）汇报昨天干了什么、今天要干什么，顺便让我知道他们没有摸鱼。表面上看，三个问题一个不少；本质上，这不是站会，是“给老板看的晨间快报”。

我后来花了两年的时间在不同团队反复验证一个判断：站会一旦开成汇报，敏捷就已经死了。死的不是形式，是心态。一旦成员的心态从“我们需要协作”滑向“我需要证明我干了活”，站会就从团队的自组织工具退化成了管理者的监督工具。这个结论不是从书里读来的，是我踩过坑、复盘过失败迭代、对比过高效团队和低效团队的站会录音之后得出的。

这个数据不是大规模调研，样本量只有5个团队，但我对每一场站会的录音都做了发言方向标注和事后回溯，哪个阻塞被当场报了、哪个被拖到站会之后才私下说、哪个直到迭代最后两天才爆出来。坦白讲，这个分析做到第四轮的时候，我已经觉得不需要继续验证了：规律太明显了。

二、为什么“汇报化”会让敏捷废掉？核心逻辑就一条

很多人理解的Scrum，是一套由角色、仪式、工件组成的流程框架。Product Owner管需求、Scrum Master管流程、团队负责交付；Sprint Planning、Daily Scrum、Sprint Review、Retrospective四大仪式串起一个迭代。这套描述本身没错，但它有一个致命的副作用：你把仪式走完了，就觉得自己在做敏捷了。

而真正的敏捷，靠的不是仪式，靠的是“信息透明+自组织决策”。

我想在这里给出一个我自己的定义，这个定义你可能在别的文章里看不到。我理解的敏捷效能，可以用一个公式概括：

敏捷效能 = 信息透明程度 × 团队自组织能力

别小看这个乘法关系。乘法的残酷之处在于：两个因子只要有一个趋近于零，整体效能就会急剧衰减。你信息再透明，团队没有自组织能力，大家等着被分配任务，敏捷不生效。反过来，团队再有主动性，信息不对齐，各干各的，敏捷也不生效。

而“站会变汇报”这件事，恰恰同时攻击了这两个因子。

1. 信息透明被系统性削弱

汇报场景下，人天生倾向于包装信息。这不是道德问题，是生存本能，你在Leader面前说自己昨天阻塞了一天没进展，这需要极高的心理安全感。绝大多数团队没有这个安全感，所以站会上的信息会经过一层“社交过滤”：进展被适度放大，阻塞被轻描淡写，风险被延迟暴露。

我在2018年带的一个团队里，有个后端开发连续三次站会都说“联调中，进度正常”。直到迭代最后两天，他才在工位上拉住我说“那个第三方接口文档有重大错误，联调根本做不了”。我问他为什么不早说，他的原话是：“每天站会大家都说得挺快的，我觉得这个事情可能能解决，不想耽误大家时间。”

他不是不负责任，恰恰相反，他是太想负责了，所以选择自己扛。但站会的设计初衷恰恰是为了让这类问题被团队共同承担，而不是一个人扛到扛不住为止。当站会变成汇报，“不想耽误大家时间”就会异化成“不想在公共场合暴露问题”。

2. 自组织能力被Leader中心化摧毁

汇报式站会有一个你很容易忽视的特征：发言流向是放射状的，所有人向中心（Leader）说话，成员之间很少直接交流。你回忆一下你的团队站会，如果有人说了阻塞，下一个接话的人是谁？如果多数情况下是Leader，那你就要当心了。

自组织团队的核心运作机制是：成员之间的信息流动不需要经过Leader中转。A的阻塞应该由B来接，因为B昨天刚好做过类似模块；C的需求理解偏差应该由D来纠正，因为D之前踩过同一个坑。这个过程如果被Leader截流，团队就会退化成一个指令执行单元。

很多Scrum Master以为自己只要不说话、不分配任务，站会就不是汇报。但实际上，只要团队成员的潜意识里仍然把你当作“需要被汇报的人”，站会的底层结构就是汇报。这和你说不说话关系不大，和团队的权力认知关系很大。

三、你不是故意把站会开成汇报的，6个认知误区让你不知不觉掉进去

过去七年我在不同规模的组织里见过至少上百场站会，从8人的初创团队到200人的产品研发中心都看过。大部分站会的“汇报化”不是有意为之，而是踩中了一些很隐蔽的认知误区。我把最常见的6个拎出来讲清楚。

1. 把“三个问题”当作站会的全部

“昨天做了什么？今天要做什么？有什么阻塞？”这三个问题是Scrum Guide里给出的经典框架，但它只是一个最小启动单元，不是站会的全部目的。站会的唯一目的是让团队对齐，对齐进度、对齐依赖、对齐风险。三个问题是手段，不是目标。

但我见过太多团队把“每个人都回答了三个问题”等同于“站会开成功了”。至于回答完之后大家是否真的建立了对彼此工作的理解、是否发现了需要立刻协作解决的问题，没人关心。这种“走完流程即成功”的心态，本身就是汇报文化的一部分。

2. 站会对着看板讲，但看板本身没有实时更新

一个很讽刺的场景：团队成员站在物理看板或电子看板前做站会，但看板上的卡片状态是三天前的。每个人嘴上说“这个功能在测试中了”，但看板上还停在“开发中”。你说站会没有看板吗？有。但这个看板不反映真实的流状态，它就是一面墙。

这种情况下，站会实际上在心照不宣地进行一场“共识表演”：我们都知道看板不准，但我们都不点破，因为点破了就需要有人解释为什么没更新、为什么卡了那么久。这恰好是汇报文化的特征，维护表面秩序比暴露真实问题更重要。

3. Leader或SM无意识地成为“主持人+裁判”

很多敏捷教练会告诉你站会要由团队成员轮流主持，这当然对。但我要指出的是一种更隐蔽的情况：主持人是轮换了，但整个站会的“注意力中心”并没有发生转移。

怎么判断？一个小测试：站会之后随机拉住两个人，问他们“刚才谁说了什么你有没有印象”。如果多数人只能记住Leader说过的话，而对其他成员的发言记忆模糊，那说明注意力结构仍然是中心化的，换主持人只是换了一个名义上的发言控制者，没有改变权力结构。

4. 在站会上当场解决问题

这个误区很多人都知道，但我这里要讲的是更深的一层：为什么有些人明知不该在站会上深入讨论，还是会忍不住当场展开？

因为汇报式站会天然制造了一种紧张感，“我必须在我的发言时间内让Leader觉得我的问题值得被重视”。如果只说一句“有个阻塞我下来找谁谁”，某种意义上听起来像轻飘飘地糊弄。于是发言者倾向于在发言过程中展开解释和自证，Leader又出于责任感要当场表态，一来二去就变成了10分钟的双人讨论。

汇报式站会和“站会变讨论会”之间不是独立的两个问题，而是同一个病根的两个症状。

5. 只有当同步信息是“好消息”时才愿意多说

迭代顺利的时候站会其乐融融，每个人都恨不得多说两句；迭代遇到麻烦的时候站会就变得异常精简，每个人用最短时间说完三个答案就想赶紧结束。这个现象是不是很熟悉？

这说明站会在那个团队里已经不是信息同步机制，而是公开的绩效信号传递机制。当成员觉得“进展不顺=在站会上丢脸”时，他们自然会在困难期收缩信息输出，而困难期恰恰是最需要信息透明的时候。

6. 团队规模已经超出阈值，但拒绝拆分

Scrum建议一个团队不超过9人（Guide里说是3-9人），这不是拍脑袋的数字。当团队人数超过这个阈值，站会的发言焦点天然向Leader集中，因为群体注意力无法在15分钟内覆盖10个以上的双向交互关系。

我做过一个记录：一个9人团队的站会，平均有36个可能的双向信息配对（假设没有Leader中心化）；而一个15人团队的站会如果仍然沿用同样的模式，双向配对增加到105个，注意力根本处理不过来。于是团队本能地做简化，所有发言向Leader集中，Leader再统一理解后再分配。这不是有意为之，是认知过载下的必然退化。

很多组织坚持不拆团队的理由听上去也很合理：“业务模块就这么划分的”“人员能力还不成熟”“拆了之后反而增加沟通链路”。这些理由我都接受，但代价也必须被正视：你的站会已经不再是团队站会，而是组长的信息收集会。你如果接受这个代价，我无话可说；但你如果不接受，那你需要做的不是“把站会开得更好”，而是“把团队变小”。

四、PingCode服务过的团队里，我看到了一个非常典型的演变路径

这一节我会用一个具体的载体来讲现象，但这个载体的选择不是因为商业合作，而是因为PingCode服务的中大型团队规模恰好是站会最容易变味儿的区间，100人以上的组织，多个并行团队，Leader角色复杂，汇报冲动天然强烈。

2023年我和几个用PingCode做Scrum管理的团队有过深度交流。他们的典型画像大概是：研发中心150-300人，按业务线拆成8-15个敏捷团队，每个团队6-10人不等。这些团队在引入工具之前，大多数经历过“先混乱、后尝试敏捷、然后慢慢僵化”的三段式路径。

我印象最深的是一个金融科技团队的Scrum Master，她给我描述了她们团队的演变过程，我觉得几乎可以作为一个通用剧本：

第一阶段：刚引入Scrum，站会效果出奇地好。团队成员第一次有了一种“每天对清楚彼此状态”的感觉，阻塞被及时暴露，依赖被提前协调，迭代节奏感建立得很快。

第二阶段：业务压力上来之后，站会开始微妙地变味。产品总监偶尔会来旁听站会，一开始只是听，后来偶尔插一两句。团队成员开始无意识地在发言时多解释两句，不是汇报给Scrum Master，是汇报给坐在角落里的那个总监。站会时间从15分钟延长到25分钟，看板更新频率从实时变成了“站会前统一更新”。

第三阶段：站会成为形式，真正的问题转移到了别的沟通渠道。站会上大家说完就走，没人追问、没人接话。真正的阻塞和风险在外面私聊或者小群里解决，站会完全失去了信息同步的功能。但它仍然每天都在开，因为不开的话“感觉少了点什么”。

这个路径在PingCode的一个客户案例里有更量化的呈现。那个团队在PingCode里记录了从2022年Q3到2023年Q2共四个季度的迭代数据。我征得同意之后拿到了一些脱敏后的统计：

这里有一个反直觉但也非常重要的趋势：Q4 2022需求吞吐量是45点，反而是四个季度里最高的。这可能是因为当时团队刚进入“汇报化”的早期阶段，Leader的关注和频繁旁听带来了一阵表面上的“努力加速”，但阻塞延迟暴露也从0.8天上升到了1.6天。这恰恰是一个危险信号，表面交付量上升的同时，问题正在被掩盖。果然到了Q1和Q2，累积的未暴露问题开始反噬交付节奏。

我想强调的是：PingCode提供的看板、燃尽图、阻塞追溯这些工具，本身并没有阻止这个团队的站会慢慢滑向汇报化。工具可以做的是让问题变得可见，当你看到一个迭代的燃尽图在最后三天断崖式下降，或者某个故事卡在“开发中”超过五天没有移动，你是可以选择深入追问的。但追问的前提是：团队愿意面对这些信号，而不是在站会上用模糊的话术把它带过去。

五、站会变味的根不在站会本身，在“心理安全感”和“Leader的自控力”

我在前面反复提到了一个概念：心理安全感。这不是我发明的理论，Amy Edmondson 1999年就发表了团队心理安全感的研究。我这里不打算重复她的理论框架，我想结合我自己的观察说一个更具体的判断：

站会的“汇报化”程度，本质上是团队心理安全感的一个实时温度计。

你不需要做复杂的问卷调查，你只需要观察三件事：

1. 阻塞被提出时，其他成员的第一反应是什么？如果多数情况是沉默、或者Leader率先打破沉默，说明团队还没有形成共同承担问题的习惯。
2. 有没有人会在站会上说“这个我不确定”“我可能做错了”？脆弱性表达的频率，直接反映心理安全感的厚度。
3. 站会结束后，成员之间是立刻各自回工位，还是有2-3组人自发聚在一起快速对一下？如果没有自发后续对话，说明站会上获得的信息没有被认为需要立刻行动，也就是说，大家根本就没真信那些信息。

这三条的判断力比我见过的任何站会评分表都准。

很多人误以为心理安全感是“让人感觉舒服”。不是的。团队心理安全感指的是：成员相信在这个团队里暴露问题、表达不确定、提出反对意见，不会被惩罚、被排斥、被看低。

而这恰恰和汇报文化水火不容。汇报文化的隐含前提是“我需要证明我的价值”。当你需要证明价值时，暴露不确定性就是自毁行为。所以一个汇报式的站会不是坏人造成的，而是一个缺乏心理安全感的团队用集体默契保护自己的理性选择。

1. Leader的角色：从“裁判”到“沉默的观察者”

我尝试过一个非常极端但极其有效的实验，让团队的Leader在站会上闭嘴一周。

不是不说话，是不做任何评价性发言。不点头、不皱眉、不说“好的”、不说“这个事情为什么拖了这么久”。站会全程只能做两件事：在自己的笔记本上记，以及在站会结束时说一句话，“有什么需要我协调的，下来找我。”

第一天的站会非常诡异。团队成员说完之后习惯性地看Leader等待反馈，Leader面无表情，于是有3-4秒的尴尬沉默。然后有人主动接话说了一个关联的依赖情况，站会继续。

第二天，尴尬缩短到1-2秒。

第三天，已经没人看Leader了。成员之间直接接话。站会时长从之前的22分钟降到了14分钟。

第四天出现了更微妙的变化：有一个前端开发在站会上说了一句“昨天那个接口联调不太顺，可能是因为我对API文档的理解有问题”，这是三个月来第一次有人在站会上主动说“可能是我的问题”。

这个实验让我彻底相信了一件事：很多团队的站会变汇报，不是因为Leader强势，而是因为Leader没有主动退后。你不退后，团队就不会往前走。这和你是否友善、是否随和无关，只和你是否占据了信息流动的中心位置有关。

六、怎么把你的站会拧回来？我试过有效的五个具体策略

理论讲到这里，下面是我在实践中反复验证过的五个策略。这些策略不是通用真理，它们只是在某些情况下有效，我会标注每种策略适用的场景和可能的副作用。

1. 重构“三个问题”的语义

标准版本的三个问题是：昨天做了什么？今天要做什么？有什么阻塞？

这三句话的默认主语是“我”。主语一旦是“我”，就天然指向个人汇报。我的建议是把语义调整成以协作和交付为中心的提问方式：

这个调整不是文字游戏。当你把问题从“我做了什么”改成“我交付了什么”，发言者必须思考成果而非努力；当你把“我打算做什么”改成“我可以帮谁做什么”，发言者必须先想一遍团队其他人的状态才能给出回答。这就把站会的认知方向从“内向输出”扭成了“外向对齐”。

适用场景：团队有基本的信任基础，只是被习惯性汇报模式困住。如果团队连基本信任都没有，换问题模板的效果会大打折扣。

2. 强制推行“看板优先，嘴巴备用”

我在三个团队推行过一个明确的站会规范：站会开始前，每个人的看板卡片必须已经更新到真实状态。不是“站会前更新”这种软约束，而是硬规则，如果看板上你的卡片状态不准确，你在站会上不需要说话，直接去更新看板，然后下一个人接着说。

刚开始执行的时候，有一半的人在站会前5分钟才手忙脚乱地去拉动卡片。但坚持两周之后，更新看板变成了肌肉记忆。更关键的是，站会的重心从“听别人说”变成了“看板上流动”，讨论自然就围绕着卡片的阻塞标签、停留天数、以及谁需要接手展开。

适用场景：团队已经使用了物理看板或电子看板（PingCode / Jira / Linear 等均可），但看板更新习惯差。如果团队没有看板基础，你需要先建立看板再说。

3. 明确站会之后立刻做的事情

站会最容易被虚化的原因之一是：站会之后什么都不用变。说完了就该干嘛干嘛，这给了每个人一种心理暗示，“刚才说的那些可能也没那么重要”。

我要求每个团队在站会结束后的两分钟内，必须产出三个具体的动作项：

• 有人被打断：谁和谁需要站会后单独聊什么？时间定在几点？
• 有卡片状态被质疑：谁负责核实哪张卡片的真实状态？
• 有阻塞未被响应：Scrum Master需要跟进哪件事？

这三个动作项不是文档，只是在站会结束前口头确认一下。但它的心理暗示作用非常强：你说出去的话是有后果的，有人会根据你的发言调整自己的工作安排。这逼着每个人在发言时更审慎、更负责。

4. 用数据把站会的“假装同步”打回原形

这是我在一家客户那里学到的方法，后来我自己也反复使用。做法很简单：把迭代看板上每张卡片在“开发中”状态的平均停留天数拉出来，贴在团队可见的地方。

这个东西的杀伤力在于：如果站会上的同步是真实有效的，那么卡片在不同状态之间的流动应该是均匀的、可预测的。如果真实数据告诉你某张卡已经在“开发中”停了6天，但过去6天的站会上没有任何一个人主动提过这个风险，那全团队都要一起面对同一个刺眼的问题，我们每天的站会到底在同步什么？

这个方法的前提是：Leader和Scrum Master要有足够的成熟度，把数据当作“让我们共同面对的事实”，而不是用来追责。如果团队的文化是“谁负责的卡停留久谁就丢脸”，那这个做法会产生反效果，成员会更不更新状态，或者在站会上更卖力地表演。

5. 在回顾会上专门设一个议题：“我们的站会有没有价值”

别笑。很多团队开了两年的每日站会，从来没有在回顾会上正儿八经地质疑过站会本身。因为这听起来像一个禁忌，质疑站会的价值，不就是质疑敏捷吗？

错。回顾会的目的就是对一切流程提出质疑。我建议每三个月至少有一次回顾会专门花20分钟讨论这个议题：“如果取消站会，我们会失去什么？”如果团队的回答是“好像也还好”，那你的站会不是快废了，是已经废了。

这个讨论还有一个附带效果：当团队意识到“站会上说的信息其实可以通过异步方式（比如Slack bot、看板更新推送）完成80%的同步”时，他们反而会对剩下那20%需要真人交流的部分更加珍惜和认真。

七、站会的替代方案：当常规站会已经救不回来的时候

不是所有站会都值得被拯救。如果一个团队的站会已经彻底“僵化”，每天走同样的流程、说同样的套话、传递同样的无效信息、持续了超过两个月没有任何改善迹象，那么强行继续开下去不仅无效，而且有害。它会持续磨损团队对“会议”这件事的心理预期：反正开会就是那样。一旦这个认知泛化到站会之外的其他会议，整个团队的协作文化会遭受慢性的、难以逆转的损伤。

这种情况下，我的建议不是“加强站会管理”，而是试试替代方案。

1. 从站会切换到“异步站会”

异步站会不是什么新鲜事物。简单说就是把每人每天的三个问题发到Slack或Teams的一个专用频道里，每个人在上午某个时间点之前自主完成，其他人自行阅读。

这个东西的优点和缺点都很明显：

• 优点：不需要同步时间窗口，远程团队友好；信息是可追溯的；强迫每个人写清楚（而不是在站会上含糊带过）。
• 缺点：失了实时交互的机会；如果没有人认真读别人的更新，信息同步效果为零；缺乏团队共鸣和情感连接。

异步站会适合一种特定的团队画像：成员分布跨时区、或者团队成熟度较高个体能力较强、且团队内部依赖关系较松散。如果团队有大量的紧耦合开发依赖（比如前端后端每天都在对联调接口），异步站会大概率不够。

2. 从15分钟站会降级为“5分钟阻塞扫描”

如果团队的需求吞吐量暂时没有高到需要每天精细同步的程度，或者看板的自动化程度已经足够覆盖进度可视化的需求，那么你可以把每日面对面站会降级为一个极简版本：

所有人站成一圈，只问一个问题，“今天的看板上有没有哪个卡片需要别人关注或者帮忙？有就指出来，没有就散。”

我见过的最快的版本是40秒散会。12个人，只有一个人指了一张卡说“这个测试环境今天不稳定，有测试任务的注意一下”，其他人都说“没有”，然后40秒散会。

这里的关键是：把站会从冗余的进度汇报缩减到只保留依赖协调，砍掉所有可异步获得的信息。

3. 考虑取消每日站会，改用“更频繁但更轻量”的触达方式

有一种更激进的思路，适合功能团队非常独立、业务模块之间几乎没有跨团队依赖的组织：把站会完全取消，改成看板驱动的异步协作。

PingCode这类工具在做的一件事就是：通过自动化的看板状态流转、以及阻塞标签触发通知、加上迭代燃尽图的自动更新，让团队不需要通过一个每日会议就能获取迭代的实时健康度。如果一个阻塞被标记了，相关的模块负责人会收到通知，而不是等到第二天站会才被告知。

当然，取消站会的风险很高。如果你没有足够的工具和数据基础设施来保证信息的实时可见性，取消站会等于砍断了团队唯一的同步渠道。但如果你的团队已经做到“看板即真相”，那每日站会确实可能就是一个可以退休的仪式。

八、不同阶段、不同规模的团队，应该做出不同的取舍

最后这部分我想谈取舍。我知道你看完前面那么多内容之后，可能会有一个感觉：“这些策略好像互相之间有一些矛盾，一会儿说要加强站会，一会儿说可以取消站会。”没错，确实是矛盾的，因为不同状态的团队需要的策略完全不同。

我把团队状态分成四种，给出完全不同的行动建议。

1. 刚启动Scrum不超过3个月的新团队

核心矛盾：不熟悉节奏 vs 过早僵化。

建议：坚持每日面对面站会，不跳过，不做异步化。新团队需要大量的面对面交流来建立认识对齐的基础。这个阶段不要在意站会是否“完美”，15分钟超了就超了，讨论多了就多了。前三个月的核心目标是让团队形成共同的工作节奏和语言，而不是追求站会效率。

需要特别警惕的一件事：如果Leader在新团队的前几周就频繁在站会上打断或纠正成员发言，请立刻停止。新团队的站会习惯是从前几周的互动模式里定型的。一旦定型为“Leader评价模式”，后面改回来要花几倍的时间。

2. 已经跑了6个月以上、但站会开始明显“形式化”的团队

核心矛盾：足够的流程熟悉 vs 失去新鲜感的倦怠。

建议：这是最适合做“结构化干预”的团队。你可以从前面提到的五个策略中挑2-3个组合使用，比如“重构提问语义+推行看板更新硬规则+回顾会设站会专题”。这个阶段的团队有足够的流程基础来理解你为什么要做调整，而不是像新团队那样还在摸索基本节奏。

我个人的经验优先级：首先推行“看板必须实时更新”，这通常能单点解决40%-50%的信息滞后问题。然后再改提问方式，最后才去动Leader的角色定位（因为改Leader的行为最难，也最容易被反弹）。

3. 团队人数已经超过10人、但短期内无法拆分的团队

核心矛盾：人数过多导致的认知过载 vs 组织约束不能拆分。

建议：不要指望在15个人的站会上实现高质量的同步。你需要做的是承认现实并降低预期。具体做法：把站会明确降级为“依赖协调会”，不要求每个人汇报，只要求“今天需要别人关注或帮忙的卡片指出来”。同时把每人每天的进度更新全面异步化（消息群或看板更新），站会不再承担进度同步功能。

不推荐的做法：不要用“每人限时30秒”来硬控大团队站会时长。这个做法表面上缩短了时间，但只是把低质量信息压缩进更短的时间窗，信息密度反而更差。限制时长在逻辑上无法解决信息覆盖度不足的问题。

4. 已经成熟运转超过一年、团队成员稳定的高效团队

核心矛盾：成员之间已经有大量非正式沟通渠道 vs 站会可能已经冗余。

建议：定期（每季度一次）严肃地问团队一个问题：“如果取消站会，我们需要补上什么？”如果团队的答案是“好像不需要补什么”，那就真的可以尝试停一周站会，在周末做一次回顾，看影响是什么。高效团队没有必要为了仪式而开一个已经失去增量价值的会。

一个重要的提醒：高效团队取消站会的前提是看板数据实时可信、阻塞自动通知机制已经建立、团队有主动示警的文化。三个前提缺一个，取消站会都是危险的。

九、再说回那个公式，以及一个我用了很多年的自检清单

文章开头我给出了一个公式：敏捷效能 = 信息透明程度 × 团队自组织能力。写到这里，这个公式可以稍微补全一下了。

站会的真正价值，不在于它是一天一次的仪式，而在于它是一天一次的系统自检：昨天我们以为是对的事情，今天看还对吗？昨天我们认为不会阻塞的事情，今天出问题了吗？昨天我们互相之间的隐含假设，今天有没有被事实打破？

一个健康的站会就是一次微小的真相注入，把看板上看不到的人肉判断、隐形成本、犹豫和顾虑，在15分钟内摊开。

一个被汇报化的站会则相反，它每天都在强化一种伪装的稳态：“我们都在按计划推进”“一切都好”“暂时没有阻塞”。当所有人都在说一样的话的时候，你要非常警觉，因为软件开发史上从来没有一个迭代是“暂时没有阻塞”的。

最后，我把这些年自己用过的一个站会自检清单放在这里。它不是什么理论框架，就是一张A4纸上写了8个问题，每次我觉得站会不对劲的时候拿出来对着看一遍：

1. 今天站会上，有几个人说话的时候眼睛看的是看板而不是Leader？
2. 有没有人主动说出“这个地方我不太确定”？
3. 有没有人在别人发言之后追问了一句相关问题？
4. 站会结束之后，有没有人自发留下来找别人快速对一件事？
5. 看板上的卡片状态，真的是站会前才更新的吗？
6. 今天的站会结束之后，有任何一个行动项是因为站会上的信息而产生的吗？
7. 如果今天站会取消，团队会少掉哪些他们真正需要的信息？
8. 上个迭代里，有没有哪个重要阻塞是在站会上被首次暴露出来的？

如果这8个问题的答案让你不舒服，那不是站会的问题，是你们团队在用站会维持一种“看起来很敏捷”的秩序感。而这种秩序感每多维持一天，真正的协作能力就多损耗一点。

敏捷不怕乱，怕的是整齐地耗着。