每天的站立并非天生的坏 — — 但当它们变成仪式而不是调整时,它们会浪费时间和破坏信任。 这篇文章探讨了为什么仪式是税收,如何衡量其价值,以及让团队在不燃烧精力或时间的情况下保持一致的首选实际的同步选择。 Agile就是适应 — — 而不是坚持。
在我将近30年的软件开发过程中, 我参加过比我想数的更多的日常立体活动。有些是电动调整的短暂时刻,清除了阻截器,把我们送过去。另一些则是表演仪式,疲劳的开发者向一个静音摄像机的画廊朗读“和昨天一样”的话。
区别? 一种单立 赚取税款另一则只是仪式而已
我不得不承认:我是一个敏锐的游手好闲者。我经历了PRINCE、瀑布和重力程序框架的WORST,我成为了这样的人。我经历了“单一代码行之前的完整文件”时代。我参加了变革控制委员会的会议,在这些会议上部署一线固定装置需要三周的批准文件。
简单的事实就是: Agile是建立好软件的最佳方法。 用丘吉尔的话来说:
“事实上,有人说,Agile是软件开发过程中最糟糕的形式除了不时尝试过的所有其他形式之外。”
但事情是这样的: 支持罪并不代表支持罪状事实上,捍卫无可置疑的仪式就是 反对 敏捷。
以下是我学到的: 敏捷是指适应,而不是遵守然而,大多数团队都继承了斯库姆仪式的批发,认为它们是神圣的而不是实际的。 日常的游行、冲刺计划、回顾这些都是工具,而不是命令。 和任何工具一样,他们应该评估他们是否 工 工 工 工 工 工 工 工 工 工.
这篇文章不是关于消除伪装,而是关于质疑你的仪式是否带来与其成本成正比的价值。因为根据我的经验, 你能做的最敏捷的事情 就是调整你的敏捷程序.
请允许我明确指出: Scrum作为一个起点是辉煌的。 它为我们在瀑布中溺水时提供了团队结构。如果你只是从Agile开始,Scrum就和他们来的时候一样好 它提供了明确的仪式、确定的角色,以及一个为许多团队工作的经过验证的框架。
但是在沿线的某处 我们混淆了 之后的缩放( Scrum) 与 正在敏化.
Scrum 是一个 工具包工具包。 Agile 是一个 心态和心态.
下面是没有人谈论的部分: 一旦Scrum开始磨擦, 减慢你的速度, 或者提供的价值比它的成本低, 那就是你适应的时候。这需要经验,但真正敏捷性却是关键。在需要进化过程时,识别能力就是将成熟的灵活团队与这些货物加工仪式区分开来。
这就是不自在的真相: Scrum Masters 只有在你继续使用 Scrum 时才得到报酬。 所以接受他们的建议, 但记住他们的激励与“ 使用最有效方法”并不完全一致。
《危险宣言》 它重视“个人与互动, "自我组织团队" 作为核心原则。但我观察了一支9米的突击队 在三个时区横跨3个时区,因为“Scrum是这么说的。”这不是灵活性,这是传统,它被装扮成方法。
我意识到很多人在做“贪婪”时从未真正读过《Agile宣言》。这是2001年17名软件开发者撰写的基本文件,他们厌倦了重力、过程驱动的开发。他们开了三天会,总结了实际有效的四个价值报表。
现为:
《危险宣言》
我们正在发现开发软件的更好方法,通过这样做和帮助他人这样做。
- 个人与互动 进程和工具
- 工作软件 综合文件加综合文件
- 客户协作 合同谈判之后的合同谈判
- 回应变化 计划之后
也就是说,虽然右侧的物品有价值,但我们对左侧的物品更有价值。
注意里面没有的东西: 日常的展示, 冲刺计划, 故事点, 回顾。 这些来自Scrum, 用来执行这些价值观的。 但是在某个过程中, 我们开始把Scrum的落实作为目标, 而不是价值观本身。
《宣言》是关于 **原则原则、原则原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、原则、**而不是处方 。 “ 过程和工具的内在和相互作用” 意指如果过程( 观看) 妨碍互动( 实际合作) , 你就会反向这样做 。
自我组织团队不需要强制他们举行仪式,他们选择可行的做法。
graph TD
A[Agile Manifesto] -->|Inspires| B[Scrum Framework]
B -->|Provides| C[Ceremonies & Practices]
C -->|Should be| D{Adapted to Context}
D -->|Teams often skip this| E[Rigid Adherence]
D -->|True agility| F[Continuous Optimization]
E -->|Results in| G[Process Theatre]
F -->|Results in| H[Effective Delivery]
style A stroke:#e1f5ff
style F stroke:#d4edda
style G stroke:#f8d7da
style H stroke:#d4edda
以我的经验来看 最快的船队 并不是那些跟随史库伦的队伍 检查和调整自己的程序 他们严格检查和修改他们的代码
让我画一幅你可能认出来的照片:
现在是上午九点,你深入地解决了一个古老的货币错误。你的IDE是开放的,调试器是附属的, 心理模型是满载的。然后,ping,在两分钟后开始举行立体会议。
切换上下文。 加入呼叫 。 等三个人解开时 。 然后 :
10分钟后,你回到你的代码, 心理模型不见了,你再花15分钟重建环境。
那次会议取得了什么成果?
在我的经验中,失败的政见有共同的症状:
当这些症状出现时,你的站起来 并没有产生一致。它正在产生 同步疲劳.
坦白地说,在许多工作场所,九点起立是一个出席名单。这是一个验证人们是否“在办公桌”(或至少是醒着)的方法。这不是灵活的,而是监视场。
如果您需要每天站立以了解您的开发者是否在工作, 您就会遇到信任问题, 而不是进程问题 。 将开发商当作专业人士对待。 判决他们所表现的,不是判决他们是否按时到会。
graph LR
A[Standup Intent] -->|Should produce| B[Alignment]
A -->|Should identify| C[Blockers]
A -->|Should enable| D[Quick Decisions]
E[Ritual Standup] -->|Actually produces| F[Status Updates]
E -->|Actually creates| G[Context Switching]
E -->|Actually wastes| H[Focus Time]
style A stroke:#d4edda
style B stroke:#d4edda
style C stroke:#d4edda
style D stroke:#d4edda
style E stroke:#f8d7da
style F stroke:#fff3cd
style G stroke:#f8d7da
style H stroke:#f8d7da
以下是改变了我对灵活做法的看法的框架:
每个仪式都消耗资源:
在民主社会中,我们接受税收 当它为基本服务提供资金时道路、学校、医疗保健----这些都证明负担是合理的,因为我们得到回报的价值。
敏捷的仪式同样有效。
graph TD
A[Ceremony/Ritual] -->|Consumes| B[Team Resources]
B --> C[Time]
B --> D[Energy]
B --> E[Focus]
B --> F[Context]
A -->|Must produce| G{Value?}
G -->|Yes| H[Justified Tax]
G -->|No| I[Process Theatre]
H -->|Examples| J[Blocker identified<br/>Alignment achieved<br/>Decision made]
I -->|Examples| K[Status updates<br/>Calendar filler<br/>Nobody engaged]
style A stroke:#e1f5ff
style G stroke:#fff3cd
style H stroke:#d4edda
style I stroke:#f8d7da
任何仪式要证明其存在的理由,都必须如此:
交付价值 > 资源消耗
以我的经验来看,当球队不衡量这个等式的两面时, 单调就失败了。 他们继承了这个仪式, 永远运行它, 并且从不问: "这还值得吗?"
以下是我所看到的工作 跨越不同的团队背景:
而非同步会议, 请尝试 :
Slack/Teams Thread(达伊利)
👋 Good morning! Quick updates:
✅ Yesterday: Completed auth refactor (#234)
🎯 Today: Tackling payment integration (#456)
🚧 Blockers: Need staging DB access (@alice)
时间成本 : 2分钟对15分钟 时区影响: 零 可搜索历史 : 是 是
以下是一个关键BEYBENEFIT 大部分队错过: 黑报成为与任何对进展感兴趣的人沟通的地方。 产品经理、利益攸关方、设计师、其他工程团队-他们都可以订阅频道并随时了解情况,
你的任务就是把团队建设成一个特效送货机。通讯是让团队运转的石油。
当CEO问“团队在工作什么”时, 给他们发送链接。 当产品需要更新时, 他们被订阅。 当其他团队协调时, 他们看到你的实时进展。 这是通信 。 振动,而不是 间接费用.
以下是如何在任何时区 进行这项工作:
模式 : "在早上九点前更新现状" (当地时间) 离开 细细线中每项任务的详细注释。 不仅“ 进行验证” , 而且还“ 授权反构件: 完成 JWT 验证, 开始刷新符号流, 阻塞器: 需要在错误状态下进行设计批准 。
澳洲纸币在最适合他们的地方留下纸条--也许在他们一天结束的时候。在9点英国时间(如果是紧急的话),你读了它,然后行动 : “ Dave,你能帮助Joe批准设计吗? ”然后你让TEAM来安排它是如何发生的。
他们推动这一进程。 你不是在安排所有的互动,你正在清除阻塞器,让专业人士直接协调。
这是阿盖尔原则 自我组织小组 不是“遵循规定程序的团队 ” , 而是围绕工作本身组织团队。 信息是透明的,环境是共享的,团队决定了如何解决。
笔记中的细节意味着你不需要同步的澄清。团队自行组织信息。
将 GitHub 链接到您的 Slack 频道。 现在, 状态更新 BECOMES 公关。 代码审查是可见的 。 您通过 emoji 来庆祝胜利。 这不是轻率的, 而是文化 。
🎉 @alice opened PR #234: Add JWT refresh token flow
💪 @bob approved PR #234: "Beautiful error handling!"
🚀 @alice merged PR #234 into main
✅ Build passed: 47 tests, 0 failures
你的站立刚刚成为你的GitHub活动饲料 零税,自动可见度,同侪承认
将通信作为最关键的地方 成为NICE的场所 如果你的团队频道是工作的地方, 让它成为人们想成为的地方。 庆祝胜利, 欣赏良好的公开工作。 感谢大家的帮助 。
这是工程文化。 当主要通讯频道感到积极时,人们就会更多地参与,更快地寻求帮助,并自由分享知识。有毒或无聊的通讯频道?人们会哑口无言。你们的通讯机器崩溃了。
Async - First并不完美。通常的失败模式 :
关键词是: Async-first 并不意味着只代表 Async-first 。 当有东西被卡住时, 跳上电话, 同步会议会解决问题, 而不是报告状况 。
物理空间的同一航距
如果你还在办公室里,还有一间工作室...
不错的椅子 体面的咖啡 真正有效的白板 自然光 如果可能的话
当工作室舒适时,人们自然会在那里引力引力。交谈会发生。问题会在白板上解决。有人偷听到阻塞器,跳进来帮忙。这是有机合作,即站立试图(和未能)制造的有机合作。
就是这个 自我组织小组 事实上看起来就像。不是站在一个圈子里向Scrum Master报告。而是那些组织工作的专业工作者,因为环境使得工作变得容易。
家具破损和荧光灯照明的令人沮丧的房间? 人们在家里工作或躲在桌子上,你们的通讯机器仍然支离破碎。
关于同步会议 : 必要时,您仍然可以预订经常性会议 -- 您不必取消所有会议。 关键是故意。 每周一对一? 保留它。 它保留日历上的空间并显示其重要性。 区别在于它们变成 可选的同步讨论 而不是 强制性强制性状况报告.
故你们应当记录重犯的经过,你们应当说:如果你们本周没有什么好谈的,那末,你们可以回避它。
以下是我作为高级/领导的方法: 我从来没有取消一对一的取消, 从来没有。 但我说清楚了, 他们可以, 它就在那里, 它发出一个信息: “我已经为你保护了这次, 如果你需要, 使用它。如果你不这样做, 不要压力。”
有些星期,他们会跳过它,因为他们是头朝下流的。其他几周,他们会用所有30分钟,因为有什么东西困扰他们,或者他们想通过设计来交谈。
经常性会议 空间空间空间非义务。
这对以下方面特别有用:
目标不是零会议,而是 以便有定期的集会,而借计时的计时,.
以我的经验来看, 保持他们的堪萨斯人董事会的团队 并不需要站得住脚的能见度。
信号丰富的董事会指标:
如果你的董事会是可信的, 看着它应该回答 "大家在做什么?"
真正的阻力需要立即关注,而不是第二天的站立。
更好的模式 :
🚧 blocked我经常听到的论点是: "但站立让我们作为一个团队连在一起!"
有道理,但每日状况更新是否是 建立连接的最佳方式?
根据我的经验,这些创造 更强 债券:
graph LR
A[Team Cohesion Goals] --> B{Choose Method}
B -->|Status sharing| C[Async Check-ins<br/>2 min/person]
B -->|Problem solving| D[Pairing Sessions<br/>As needed]
B -->|Reflection| E[Weekly Retro<br/>1 hour/week]
B -->|Social bonding| F[Slack channels<br/>Continuous]
G[Daily Standup<br/>15 min × 5 days] -.->|Tries to do all| A
style A stroke:#e1f5ff
style C stroke:#d4edda
style D stroke:#d4edda
style E stroke:#d4edda
style F stroke:#d4edda
style G stroke:#fff3cd
并非所有的团队都应该采取同样的仪式。
团队概况 * 支持价值 * 更好的替代品 * |--------------|---------------|-------------------| | 质、 分布、 合成- 第一次 低 黑 报到 + 准确板 | 初小重队 * 低指导模式(见下文) | 紧最后期限,高风险 要看 平衡 : 15 分钟能拖慢你吗? 如果没有阻塞器,为什么你急着报告? | 稳定地特征团队 低税率更新; 只有在建立复杂的多人特写或关键问题时, 才会扩大到每日 | 开放源,全球时区 Async更新+每周视频摘要
另一边:青年开发者神话
常识:"青年需要每天的站立来学习。"现实:常有站立 增加焦虑 对于低年级学生,但实际上没有帮助他们成长。
你的团队 让你的犹太人。 不是站立,而是指导。给老年人分配时间帮助他们。让它们文化化:领导老年人,年长者管理少年。在更新之前,少年可以预知他们的年长者,但他们必须有自己的声音 — — 年长者从来不为他们说话。
专业发展是通过辅导而不是现状报告实现的。 扶手不会教授估计、建筑或调试。对称是的。代码审查是的。 1对1是的。
以我的经验来说, 错误不是有 站立或没有他们。 同样的仪式适用于每个背景环境.
事实是这样的: 一切都能适应你团队最好的方法
这就是阿盖尔原则 自我组织小组 并不是说"精顺史库姆的团队" 不断调整工作程序以服务于工作的团队.
一些团队为日常的监视活动而生活 — — 能量、连线、快速火力问题解决。 有些人甚至会抗议黑白信息,更愿意专心致志,尽量避免中断。
一个真正的自我组织的团队实验, 测量和选择。你适应了结果。
我说"团队决定"时 是谁打的电话? 铅或高级开发者 领导才能为改进创造了条件。
模式 :
透明度是关键。 依据证据(“我们有数据,这行不通”)而不是意见(“我认为这样更好”)。
如果你的团队不能表达对流程变化的关切, 你没有一个自我组织的团队 - 你有指挥和控制 与更好的嗡嗡声。
这是我爱的图案: 尖尖加。如果您使用短跑(或只是快速周期反馈),则钉钉就是您的实验预算。
注意任何“我们应该尝试X科技”的讨论。 当有人说“我不知道Postgres全文搜索是否比 Elasticsearch 更快,请写下来。不要辩论它。抓住它。
使用峰值作为重度开发期间的乐趣休息。 研究一个能把你磨碎的长长的功能? 计划一个钉钉。 “ Alice, 花一天时间尝试你提到的反应服务器组件。 看看它是否解决了我们的水合问题 。 ”
斯派克对Devs很有意思 他们可以探索 学习 可能失败 这是健康的
以团队方式追踪他们:
最后一点很关键。 钉钉以“ 以下是我学到的 ” 结尾。 可能是在斯拉克的10分钟, 可能是在白板上的20分钟。 格式并不重要。 重要的是 你贡献了团队的知识 不只是从中提取.
这对于初中生来说尤其重要。 他们正在成为该团队的Redis专家。他们研究、测试了它,现在他们正在教球队。
"你提到想学习关于缓冲的问题。这是2天的峰值:调查Redis和我们的API反应。星期五向团队介绍你的调查结果。"
现在小弟不光是食用 高年级学生的知识 促进小组的集体理解这就是你建立信心的方式 初中生不再觉得自己是冒牌货了
这里的经济论点是: 他们不只是学习练习, 而是决定加速器。
道路1:通过 下一个 dev 循环周期, 您可以使用该技术。 您通过加注而提供更大的价值。 它本身支付。 爱丽丝花了一天时间扑灭反应服务器组件? 两周后, 团队的特色比客户端JavaScript少了80%。 为期一天的投资节省了调试水分问题的日子。
路径2:消除 或者你排除一个选择,通过减少路径来让检验更有价值。 “我们尝试了GreagQL Federal, 这对于我们的团队规模来说太复杂了。 现在我们知道: 在接下来的6个月里继续使用REST。 ”这不是一个失败的峰值,而是一个失败的峰值。 成功决定你不再浪费时间去想"我们是否应该使用GreagQL?" 答案是否定的,有证据支持。
两种结果都有价值。 要么你获得一个工具,要么你消除分散注意力。 最坏的结果是从未出现过 — — 只是无休止地争论“ 我们应该尝试X吗? ”而没有数据。
甚至过程也会被钉死 您可以在团队中担任“ 流程所有人” 并使用流程钉 。 “ 让我们尝试以同步方式检查两周。 这是一个流程钉 。 我们将测量阻塞反应时间, 看看会发生什么 。 ”
原则:改变是由实验驱动的。 团队玩技术是健康的。玩过程是健康的。选择是停滞 - 同样的工具,同样的仪式,同样的挫折感 多年来。
Spikes 正常实验。 他们保证说"我不知道这行不行" 并尝试它。
问问你自己: 团队需要什么产出?
缩略 最佳结果 我受够Async 自我组织 Slack 方法了。 您确定什么应该是“ 脱线 ” ( 在利益攸关方的单独会议上) , 或者当您需要小组会议来讨论一些复杂的事情时 。
直到有一个特点可以玩, 您程序的产物是您开发机器的输出这才是最重要的
若贵公司需要滚动进度更新, 请考虑如何尽可能以CHEAPLY(税制)提供:
创意替代品:
有些选择比强迫人类每天手动报告进展要便宜。
目标不是消除交流,而是 使机械部件自动化,使人类能够专注于有价值的部件 - 决策,合作,创造性的解决问题。
如果你是开发者,您要监视您的系统。 您可以跟踪潜伏、 误差率和资源使用量。 您设置 SLO 并在 SLOs 退化时进行调查 。
为什么我们不这样做 为我们的过程?
在测量仪式之前,请先测量仪式,然后测量 通信本身的通信本身以下是我所追踪到的 揭示了真正问题的量度 :
对阻挠者的反应时间
审查时间到 PR-审查
答 答 答 答 率
部署频率
黑频道参与
模式 : 如果这些测量仪是健康的, 你的通讯基础设施是有效的 如果它们退化了, 任何仪式都无法修补它您需要解决根本问题(所有权不明确、心理安全低、工具摩擦等)。
问你的团队季度:
这个仪式要解决什么问题?
什么证据表明它起作用了?
有更快的路吗?
如果我们跳过它会怎么样?
我们是否测试过替代品?
我们每天有18个月的备战,然后我提议一个实验:
假设: 我们的成熟团队可以保持与 3x每周报到+同步更新一致。
度量 :
4周后结果:
我们让它永久永久存在,不是因为站立是坏的,而是因为 我们的环境没有证明税收是正当的.
graph TD
A[Current Ceremony] -->|Define| B[Success Metrics]
B -->|Propose| C[Alternative Approach]
C -->|Run| D[Time-boxed Experiment]
D -->|Measure| E{Better Results?}
E -->|Yes| F[Adopt New Approach]
E -->|No| G[Keep Original]
E -->|Mixed| H[Iterate & Re-test]
F --> I[Document & Share]
G --> J[Schedule Next Review]
H --> C
style A stroke:#e1f5ff
style D stroke:#fff3cd
style F stroke:#d4edda
style I stroke:#d4edda
我想说清楚一点: 我不是说要消除无处不在的僵尸.
一些环境真正受益于每日同步:
根据我的经验,每天的看台为以下活动提供价值:
新组建小组
少年重兵小组
高压力释放窗口
跨功能发现
关键原则: 当你们团队的背景改变时 你们的仪式也应该改变
我和团队合作 在6周的产品发布期间做过立体立体表演 之后改用合成。这不是不一致的 这是适应.
让我分享有效仪式在起作用时的模样:
最优秀的团队之一 我工作与运行的立体 像这样的:
格式 :
平均持续时间: 7分钟7分钟 会议取消: ~40%的时间 值 : 解决高带宽问题,无地位剧院
分布在9个时区的一个小组:
模式 :
时间成本 : 60秒记录+3分钟监视 时区问题: 已消除 连接 : 高一点(看脸,听音音调)
一个团队建立了一个简单的仪表板:
任务 任务 估计 信任 最后一次更新
|------|----------|-----------|-------------|
2小时前 5点 90% = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
5小时前8点 60% 6点 5小时前
DB移民 3点 30% 一天前
置信率低于70%触发的自动“需要帮助?”
结果: 阻塞器主动浮出水面,不需要开会。
以下是我对正统的表态感到困扰的原因:
《阿吉勒宣言》说 "响应变化 而不是遵循一个计划。"
我们继承了Scrum的立体立体立体 继续运行 即使有证据表明他们不起作用
那不是灵敏度,那是 传统传统传统.
以我的经验, 真正灵活的团队 提出棘手的问题:
graph TD
A[Agile Mindset] -->|Requires| B[Continuous Improvement]
B -->|Applied to| C[Product]
B -->|Applied to| D[Code]
B -->|Should apply to| E[Process]
E -->|Questions| F{Is this ceremony<br/>still valuable?}
d apply to| E[Process]
E -->|Questions| F{Is this ceremony<br/>still valuable?}
F -->|Yes + Evidence| G[Keep & Measure]
F -->|No + Evidence| H[Change or Remove]
F -->|Unsure| I[Run Experiment]
G --> J[Schedule Next Review]
H --> J
I --> F
style A stroke:#e1f5ff
style E stroke:#fff3cd
style G stroke:#d4edda
style H stroke:#d4edda
style I stroke:#d4edda
让我用一个简单的原则把这个带回家:
仪式不灵活, 因为它在 Scrum 指南中有一个名字 。 只有当它得到重担时它才灵活
站起来不是胡说八道 强制性的、无可置疑的、无背景的政体是。
以我的经验,最好的团队 对待仪式像代码:
这是 实际自组织小组不是完全按照规定程序行事的团队,而是不断检查和调整自己工作方式的团队。
危险不是保护仪式,而是... 保护清晰、流动和交付.
如果一个2分钟的黑卡, 达到一个15分钟的站立状态—— 你们的团队船只更快, 感到疲劳更少, 并保持一致—— 即动作的灵敏度.
这就是我对你们的挑战:
本周,请问您的团队:
很好,你现在有证据了,而不是假设了。
或者你可能发现这几个月的税收没有好处了。同样伟大的——现在你可以优化了。
无论哪种方式,你会做 最灵活的事情 尽可能: 适应基于现实,而不是仪式.
我很想听听你的团队有什么成功(或没有成功)? 联系 或在下文中留下注释。
© 2026 Scott Galloway — Unlicense — All content and source code on this site is free to use, copy, modify, and sell.