我们为什么放弃了Scrum

一、我们放弃 Scrum，不是因为敏捷不对，而是我们连“为什么要站会”都回答不了

2023年第三季度，我们团队连续三个迭代都没有按时交付。不是代码写不出来，而是每次站会之后，所有人都陷入一种奇怪的沉默，任务看板完美无缺，燃尽图漂亮得像是教科书范例，但产品负责人私下告诉我，客户已经两周没有收到任何有意义的更新。

那天下午我把过去八个月的迭代数据全部拉了出来，结果让我坐立不安：我们团队在站会上汇报“无阻碍”的比例高达94%，但实际交付延迟率却达到了37%。这两个数字在逻辑上不可能同时成立，除非站会上所有人都在说谎，或者说，大家都在说一种被规训过的“正确的话”。

这就是我们决定放弃 Scrum 的起点。不是因为 Scrum Guide 写得不好，也不是因为我们对敏捷价值观有什么怀疑，而是因为我们突然发现，当一套流程让团队学会了如何“看起来敏捷”，而不是“真正敏捷”，这套流程就已经从工具变成了枷锁。

这篇文章记录的是我们从一个30人研发团队的真实困境出发，如何在180天里逐步拆解、实验、放弃 Scrum 标准框架的过程。我不会说 Scrum 已死，也不会说我们找到了什么银弹，我只想诚实地还原：当你的团队和我遇到一样的症状时，你可以怎么判断、怎么取舍、怎么行动。

二、我们是怎么走到这一步的：一个典型团队的 Scrum 崩溃时间线

1. 蜜月期（第1-3个月）：一切看起来都很美

我们引入 Scrum 的原因非常典型：团队从15人扩张到30人，之前那种“谁有空谁接活”的口头协作模式彻底失效。我们急需一套结构化流程来管理跨职能协作。

最初三个月，效果显著：

• 需求终于有了统一入口，产品经理不再在群里吼需求；
• 站会让大家知道别人在做什么，重复劳动大幅减少；
• 迭代评审让客户第一次看到了阶段性成果，信任度明显提升。

团队士气高涨，Scrum Master 甚至在回顾会上说：“我们只用了三个月就完成了敏捷转型。”现在回头看，这句话本身就是危险信号，我们把“安装了一套流程”等同于“转型成功”。

2. 僵化期（第4-6个月）：流程开始自我繁殖

从第四个月开始，问题陆续浮出水面：

（1）站会变成了“安全表演”

每个人只说三句话：昨天做了什么，今天做什么，没有阻碍。但“没有阻碍”不是因为真的没有，而是因为说出阻碍的成本太高，你可能要当众解释一个技术细节十分钟，或者在站会后被拉进一个额外的一小时专项会议。于是最优策略就是：在站会上说一切正常，会后私下找人解决问题。这直接导致站会丧失了它最核心的功能，暴露风险。

（2）Sprint 计划会变成“工作量分配会”

产品负责人讲解高优先级需求之后，团队在估算时已经不讨论“这个故事到底要解决什么问题”，而是在讨论“这个故事点应该算3还是5”。故事点原本是用来衡量复杂度和不确定性的相对单位，但我们把它用成了精确工时估算的替身，一旦管理者开始对比“这个迭代你们做了28个点，上个迭代做了32个点”，故事点就彻底变成了另一种形式的考勤表。

（3）回顾会变成了“情绪垃圾桶”或者“形式主义过场”

最糟糕的一段时间，回顾会上列出的改进项次次都是“提高需求文档质量”、“加强前后端沟通”这类永远正确但永远不改变的东西。为什么？因为真正的痛点，比如技术负责人从不参加站会、产品经理在迭代中途插需求，从来没人敢写在回顾板上。回顾会变成了一个情绪宣泄出口，但没有行动闭环，久而久之大家就麻木了。

3. 崩溃期（第7-8个月）：数据不会说谎

第八个月末，我做了那次数据复盘。除了站会和交付的矛盾，还有几个指标让我意识到问题已经系统化了：

• 迭代内需求变更率：41%。这意味着近一半的迭代承诺其实做不完或者做错了方向，但站会上从来没人说“我们的迭代目标可能达不成了”，直到最后一天才暴露。
• 开发人员在非开发任务上的时间占比：34%。包括站会、计划会、评审会、回顾会、每日代码审查、以及与产品经理的“对齐”会议。这意味着一个两周迭代中，每个人有将近3天花在流程上。
• 迭代评审上展示的功能，客户后续实际使用率：12%。我们交付了大量“符合需求文档”但用户根本不用的功能。

这些数字放在一起，指向同一个结论：我们不是在敏捷开发，我们是在用 Scrum 的壳子包着瀑布的芯子，同时加上了每天一次的汇报表演。

三、在放弃之前，我们问了自己三个诊断性问题

在决定放弃 Scrum 之前，我花了很长时间做一件事：区分“Scrum 本身的问题”和“我们执行的问题”。因为如果你只是执行坏了，换一套框架该坏还是坏。我建立了一个自检清单，用来判断团队的困境到底是哪一层面的：

1. 问题出在“框架层”还是“文化层”？

框架层问题指的是 Scrum 的结构性缺陷，比如固定迭代长度不适合你的业务节奏。文化层问题指的是团队缺乏信任、管理者缺乏安全感、成员缺乏责任感。这两者的诊断方式完全不同。

我们的自检方法是：做一次“静默迭代”，两周内取消所有 Scrum 会议，只保留看板，观察团队行为。如果取消站会后，团队成员依然会主动找相关方同步信息，那说明沟通文化是健康的，站会的形式确实多余。如果取消后信息彻底断流，那说明你的团队根本没有协作文化，Scrum 之前只是用会议强行维持了信息流动。

我们的结果是：信息没有断流，但出现了选择性同步，复杂问题被私下讨论解决，简单问题通过看板评论异步沟通。这说明我们的文化基础不差，Scrum 会议确实过度设计。

2. 问题出在“角色”还是“人”？

Scrum 定义了三个角色：产品负责人、Scrum Master、开发团队。但现实是：大多数中小团队根本没有专职的 Scrum Master，这个角色通常由技术负责人兼任。当一个同时要写代码的人来执行 Scrum Master 职责时，天然会产生冲突，他自己也有开发任务，怎么有动力去暴露自己的阻碍？怎么有精力去观察团队动态？

我们的产品负责人同样有问题。按照 Scrum Guide，PO 应该是一个决策者，能独立确定优先级。但在我们的组织里，PO 上面还有业务总监，业务总监上面还有客户。这意味着 PO 实际上是一个需求传声筒，而不是决策者。迭代中途的需求变更，90% 来自 PO 无法拒绝的上级压力，而不是 PO 自己的优先级调整。

当一个框架需要特定角色能力，而你的组织短期内无法提供合格的角色人选时，坚持框架反而是在制造系统性失效。

3. 问题出在“迭代长度”还是“业务节奏”？

Scrum 的标准迭代长度是1-4周，绝大多数团队选择两周。但我们的业务特点是：客户需求的高峰期集中在月初和月末，月中相对平稳。这意味着两周迭代的边界恰好卡在需求波动最剧烈的节点上。月初启动的迭代还没结束，客户已经扔过来一波新需求；月末的迭代又赶不上月初的验收节点。

这不是 Scrum 的错，但固定迭代长度如果和业务节奏完全不匹配，它就变成了刚性绊脚石。

四、我们做了哪些失败的修补尝试，以及从中学到什么

在决定放弃之前，我们其实做过三轮修补。这些尝试虽然最终没有挽救 Scrum，但让我们看清了很多东西。

1. 第一轮：削减站会频率

我们把每日站会改为每周三次（周一、周三、周五）。结果是：周二和周四的异步更新质量极低，大部分人只是在群里发一句“正常推进”。但有趣的是，当我们把站会改为“每周两次同步 + 每日看板评论”后，看板评论区的信息密度反而大幅提升，因为没有会议兜底，大家都知道必须在看板上留下有效信息。

教训：站会的核心价值不是“每天见面”，而是“信息透明”。如果你能找到更高效的信息透明方式，站会就是可替代的。

2. 第二轮：拉长迭代到一个月

我们尝试把迭代从两周拉长到一个月，希望减少计划会开销，同时给复杂任务更多弹性。结果是：迭代内的变更率从41%飙到了62%。因为四周的时间窗口太长，外部需求变化根本等不了，团队也不再有“快结束”的紧迫感，前三周松散，最后一周加班。

教训：迭代长度的真正约束不是工作量，而是“外部世界能保持稳定的最长周期”。在我们业务中，这个周期大约是1.5周。这解释了为什么两周迭代还不够灵活，我们需要更短的交付节奏，而不是更长。

3. 第三轮：取消故事点，回到工时估算

我们尝试把故事点弃用，改用理想的开发工时。结果是：估算精度确实提升了，但团队开始和产品经理讨价还价工时，协作关系变得更像外包开发。产品经理开始问“这个功能你说要8小时，能不能压缩到6小时”，开发人员则开始预留缓冲，把所有工时估高20%。

教训：估算单位的形式不重要，重要的是管理者和团队之间的信任关系。只要有人用估算数字来考核产出，任何估算方法都会变形。故事点也好，工时也好，只要被用作绩效输入，它就不再是协作工具。

五、放弃 Scrum 之后：我们到底用了什么

先说清楚：我们放弃的是 Scrum 的标准流程和仪式，不是敏捷原则。我们依然坚持：尽早交付价值、持续获取反馈、团队自组织改进。这些我们一个字都不会放弃。我们放弃的是这套特定形式：固定迭代、标准三角色、每日站会、计划-评审-回顾的固定会议节奏。

替代方案不是某一个名字响亮的框架。如果你期待我说“我们换成了 Kanban”、“我们换成了 Shape Up”，那你要失望了。我们实际上是根据自己的业务特征，从零拼出了一个工作流。我把这个过程公开，不是因为它多成熟，而是因为拼凑的过程本身比结果更有参考价值。

1. 按业务节奏而不是日历节奏来设定交付周期

我们分析了过去18个月的客户需求波动数据，发现客户需求峰值间隔大约在8-12个工作日，且需求之间存在较强的逻辑关联关系。基于此，我们放弃了固定迭代，改为“功能切片交付”，每个工作日结束时，必须有一个可演示的功能切片或者一次明确的用户反馈录入。

这意味着：一个复杂功能可能被拆成3-5个切片，每个切片独立交付、独立收集反馈。如果反馈推翻了之前的方向，后续切片直接调整，而不是等到迭代结束才发现问题。

这个模式的落地成本是：我们要求产品经理必须在开发启动前，把每一个功能拆成最多两个工作日可以交付的粒度。这倒逼需求方必须想清楚自己到底要什么、优先级是什么。那些只想“先做出来看看”的需求，因为拆不出清晰切片，自然被过滤掉了。

2. 用看板代替站会，但看板上的信息必须满足“替代站会”的标准

我们取消每日站会之后，对看板提出了严格要求：

• 每张任务卡必须在每天上午10点前更新状态和阻碍项；
• 阻碍项必须明确写出“卡在哪里”、“需要谁协助”、“预计解决时间”；
• 如果一张卡连续两个工作日没有进展更新，自动触发团队负责人的定向沟通。

这个机制运行的第一个月，我们发现：异步信息更新的质量比站会口头汇报高了不止一个量级。因为写出来需要思考，说不需要。写在看板上会被所有人看到，质量太差会被注意到。而站会上低着头念叨两句，没人会追究。

代价是：团队需要花更多精力在信息输出上，但站会本身节省下来的时间远远覆盖了这个成本。我们测算的净收益大约是每人每周节省2.5小时。

3. 干掉迭代评审，改成持续发布与定向邀约

迭代评审在我们团队异化得最严重：它变成了一场给内部看的演示会。真实的客户根本不会来参加你的迭代评审，来的都是业务总监和产品经理，他们本来就天天跟着项目走，评审会上看到的都是已知信息。

我们换成了两个机制：

• 持续发布：任何一个切片完成后，自动部署到测试环境，并生成一个访问链接。
• 定向邀约：产品经理根据切片的性质，定向邀请对应用户、业务方或技术负责人，给一个5分钟的操作演示和反馈收集。

这个模式的效果立竿见影：客户的反馈量增长了近3倍，而这些反馈又直接驱动了后续切片的调整。原因很简单：一个5分钟可以看完的东西，客户愿意看；一个放在正式会议上的1小时演示，客户不一定有空来。

4. 保留回顾，但不再叫 Sprint 回顾

回顾是我们唯一没有放弃的仪式，但改了形式：不再每个迭代开一次固定回顾会，而是按“事件”触发，每当出现交付事故、严重阻塞或者重大决策变更，就触发一次专项回顾。

专项回顾和定期回顾的最大区别在于：定期回顾讨论的是“过去两周大家感受怎么样”，没有具体锚点，讨论容易泛化；专项回顾讨论的是“这次发布为什么延迟了3天”或者“那个需求为什么要推倒重来”，有明确事件作为锚点，改进项天然有行动抓手。

我们保留了 Scrum 回顾的核心技巧，安全性、聚焦流程而非个人、形成行动项，但舍弃了它的节奏和形式。目前来看，回顾的质量反而比之前更高，因为讨论的颗粒度变细了。

六、这个模式我们用了半年，哪些数据说明它管用

放弃 Scrum 之后的前两个月是混乱的。主要是因为取消了固定迭代边界后，产品和开发之间的交付承诺需要重新建立。但到第四个月，数据开始走向稳定。以下是第六个月和放弃之前第八个月的关键对比：

这些数字不代表这个模式比其他框架强，它只说明一件事：一个自制的、根据自身业务流量特征调整出来的工作流，比一个标准框架更匹配团队的实际处境。

但数据也揭示了代价：

• 对产品经理的需求拆分能力要求大幅提高。过去产品经理可以扔一个“大需求”进迭代，由开发团队自己拆任务。现在必须在启动前拆到两天以内的粒度，这对业务分析和系统理解都有更高要求。我们有两位产品经理在过渡期离开，原因就是无法适应这种工作方式。
• 跨团队协作的边界变得模糊。过去迭代是一个明确的承诺边界，这个迭代我承诺做这些，其他团队的事我不管。现在变成持续交付后，其他团队随时可以插进来请求联调或配合，边界管理变成新的挑战。
• 管理者失去“宏观控制感”。固定迭代让管理者可以预期“两周后能看到什么”，放弃之后，交付节奏变成持续的而不是批量的，管理者需要学会用累计交付价值而不是单次迭代产出来衡量进度。

七、团队规模与流程选择：一个被严重低估的关键变量

在复盘整个过程时，我发现很多对 Scrum 的争论都忽视了一个关键变量：团队规模。Scrum Guide 建议开发团队规模在3-9人，但现实是大量30人、50人甚至上百人的团队在用同一套 Scrum 仪式，只不过他们把大团队拆成了多个 Scrum 小队。

拆队解决了部分问题，但产生了一个新问题：小队之间的交互成本被严重低估。在我们30人团队时期，6个Scrum小队之间的接口协商、迭代对齐、联合评审，占去了大量的“非开发时间”。这些跨队成本在Scrum Guide中几乎没有被阐述，因为原始框架是为单一产品单一团队设计的。

我观察过一个有趣的现象：当团队从15人增长到30人时，我们在“流程仪式”上的总时间投入增长的不是2倍，而是接近3.5倍。这不是线性增长，因为每增加一个小队，它不仅要和自己的PO对齐，还要和其他所有小队做接口沟通。用数学来说，沟通链路的增长是组合级的，而不是线性级的。

所以我们放弃Scrum的另一个深层原因是：这个框架隐性地假设团队规模稳定在一个小范围内，一旦超出，框架的边际维护成本急剧上升。至少在我们当时的30人规模下，继续维护标准Scrum的成本已经超过了它带来的收益。

对于不同规模，我的判断是：

• 10人以下、单一产品线：Scrum 的核心仪式可能仍然有效，因为它带来的结构化沟通在小团队中是正收益；
• 10-30人、一个产品多个模块：Scrum 的跨团队成本开始显现，标准仪式需要大幅精简；
• 30人以上、多个产品线或模块：标准Scrum大概率已经不适用，需要考虑更轻量的持续交付模式，或者至少对Scrum仪式的频次和范围进行根本性重构。

这个判断当然不是绝对的，如果你的组织有成熟的Scrum Master团队和高度自治的小队文化，30人以上仍然可能跑得很好。但对大多数从中小规模快速扩张上来的团队，这些条件往往是缺失的。

八、什么情况下你真的不应该放弃 Scrum

写到这里，我必须做一个重要补充：这篇文章不是一篇“反Scrum宣言”。事实上，在我们团队放弃Scrum的同时，我观察了一些同行团队，有些团队在Scrum下运行得非常健康。那么，差异在哪里？

我总结出三个你不应该放弃Scrum的条件，如果你的团队目前恰好满足，那么问题可能出在执行层面而不是框架层面：

1. 你的产品负责人是真正的决策者

如果你的PO有权独立决定优先级，不需要层层汇报、审批，且PO的优先级就是团队最终执行的优先级，那么Scrum的“PO单点决策”设计就能发挥最大效率。问题是大部分中国中型以上企业的PO，在组织架构上就是没有这个权力的。

如果你恰好是那个有决策权的PO，请不要放弃Scrum，你缺少的只是更好地使用它。

2. 你的业务需求变更周期恰好和迭代长度匹配

如果你的业务环境中，需求的稳定周期大约就是两周，那么两周迭代就是一个自然匹配。包括一些做标准化产品（比如工具类SaaS、基础设施软件）的团队，需求变更频率低，迭代规划可以相对稳定。这种情况下，Scrum的结构化节奏是加分项。

但当你的业务需求以天为单位波动（比如业务系统定制、营销活动型产品），两周迭代就是在强行削足适履。

3. 你的团队需要结构化仪式来维持纪律

这不是讽刺。有些团队，尤其是新手比例高、远程协作比例高、或者行业背景差异大的团队，确实需要明确的仪式来维持协作节奏。站会不是多余，而是这些团队建立协作习惯的脚手架。在这种情况下，放弃Scrum让团队“自组织”，反而可能导致协作解体。

所以关键判断是：你的团队是“被仪式约束着才能协作”，还是“仪式本身已成为协作的阻碍”？这两个症状看起来相似，但原因完全相反。前一种需要坚持仪式（同时培养文化），后一种必须拆除仪式。

九、从 PingCode 的实践看工具对流程的反作用

我们团队在Scrum时期和放弃之后，一直使用 PingCode 作为项目管理工具。因为我不是在给 PingCode 写软文，所以我只说和我们流程变化有关的一个关键发现。

PingCode 支持标准的Scrum流程，史诗、特性、用户故事、故事点、迭代规划、燃尽图，这些我们都深度使用过。但后来我发现：PingCode中最有价值的不是那些Scrum原生功能，而是它的看板自定义能力和数据面板。

当我们放弃Scrum之后，我们并没有换工具，而是在 PingCode 中重新配置了工作流：

• 废除了“迭代”的概念，改为使用“里程碑标签”来自由关联需求切片；
• 把故事点字段隐藏，改用自定义字段“切片交付日”作为进度依据；
• 在看板上设计了按“功能模块+交付状态”的双维视图，替代了过去的迭代任务板；
• 大量使用数据面板来监控交付周期、客户使用率、返工率这些真实效率指标，而不是燃尽图。

这个过程让我意识到一个更深层的问题：很多团队之所以被困在Scrum里出不来，不是因为他们相信Scrum，而是因为他们的工具只支持Scrum。当你的项目管理工具强制要求你创建迭代、填写故事点、站会看板默认就是迭代任务板，它实际上在用产品设计约束你的工作方式。

所以如果你在 PingCode 或者类似工具（Jira、Linear、Ones）上跑 Scrum 跑得难受，我建议你先做一件事：别再让工具定义你的流程，反过来，先把你要的流程画清楚，然后在工具里看看能不能配置出来。PingCode 的自定义能力在这方面给了我们很大的弹性，但前提是你得先想清楚自己到底要什么。

基于我们在 PingCode 上的配置经验和同行业客户的观察，不同业务类型的团队可以参考以下策略：

十、你现在应该怎么做：一个可操作的理性撤退路径

如果你读到这里，心里想的不是“我要立刻放弃Scrum”，而是“我想知道我的团队到底该不该放弃”，那这个章节是为你写的。

我给一个可操作的路径，分四步：

1. 先做数据诊断，不要凭感觉

你不是因为“站会浪费时间”而放弃Scrum，你是因为“站会实际浪费的时间与它暴露的风险不成比例”而放弃。这两者需要的证据完全不同。

收集最近三个迭代的数据：站会时长、站会暴露的阻碍数及后续解决率、迭代内变更需求比例、返工需求占比、开发人员在流程会议上的时间占比。把这些数据做成一面看板，团队一起看。如果数据显示“阻碍暴露率持续走低而交付延迟率走高”，这就是强有力的放弃理由。如果数据显示“阻碍暴露率高且大部分在迭代内解决”，那Scrum对你可能仍然有效。

2. 做一次“静默实验”

选一个迭代，取消所有Scrum仪式（站会、评审、回顾），只保留看板更新和必要的一对一沟通。在迭代结束时，和上一个“正常迭代”做对比。比较指标不用复杂：交付了多少功能、收了多少用户反馈、团队主观压力评分。如果静默迭代的三项指标都没有显著下降，甚至上升，说明你的Scrum仪式确实可以被替代。

这个实验的风险在于：如果团队文化本身不健康，静默可能导致协作崩溃。所以建议在团队基础信任较好的前提下进行，或者至少和成员充分沟通实验目的。

3. 如果决定放弃，先设计好“替代方案”再动手

最糟糕的情况是：取消了Scrum仪式，但没有建立任何替代机制。这会导致信息断流、承诺真空、协作退化。

至少要有三个替代：

• 信息同步替代：看板强制更新规则，取代站会的同步功能；
• 反馈收集替代：持续发布+定向邀约，取代评审会的展示功能；
• 改进闭环替代：事件驱动专项回顾，取代定期回顾的改进功能。

如果你还没想好这三个替代怎么设计，暂时别放弃。

4. 保留退出通道

我的最后一条建议是：不要把放弃Scrum当成一个不可逆的决定。可以设定一个三个月的评估周期，在这个周期后重新审视数据。如果替代方案的数据不如预期，回到Scrum并不可耻。

我们团队给自己定了一条规则：哪个流程模式能让我们以更低的沟通成本、更高的反馈速度、更少的返工交付价值，我们就用哪个。它不是Scrum，不是Kanban，也不是Basecamp的Shape Up，它只是一个我们在当前阶段暂时有效的拼凑方案。下一阶段业务变了，它可能也要变。

十一、这半年我学到的最重要的一件事

最后我想说一件最重要的事。

放弃Scrum这半年，我反复问自己一个问题：我们当初引入Scrum，到底是为了解决什么问题？答案是：当团队从15人扩到30人，口头协作失效，我们需要结构化流程。

但问题是，我们错误地把“结构”等同于“Scrum”。Scrum是结构的一种，不是结构的全部。它是由特定的人在特定时期为特定环境设计出来的一套约定。你的团队、你的业务、你的阶段，不一定在那个“特定”之中。

放弃Scrum不是反叛，不是潮流，更不是优越感。它只是一个团队在认真审视自己的处境后，做了一次诚实的取舍。我们保留了我们真正需要的东西，透明、反馈、持续改进；我们丢弃了我们不再需要的东西，为了维持框架而维持的表演性仪式。

如果你也在犹豫要不要放弃Scrum，我唯一的建议是：先搞清楚你到底在解决什么问题，再看Scrum是不是解决这个问题的唯一方式。大概率不是。

下一步行动建议：

1. 拉出你团队最近三个迭代的核心数据，对照本文第二章的指标清单做一次诊断；
2. 如果数据指向流程失效，尝试一次可控的“静默迭代”实验；
3. 在决定放弃前，确保你设计好了信息同步、反馈收集、改进闭环三个替代机制；
4. 设定三个月的复盘周期，把“放弃或保留”变成一个持续评估的命题，而不是一次性决断。

我们用了八个月才从Scrum的框架里走出来，希望你的路径，可以短一点。