Scrum 很糟糕
这里普遍认为，Scrum 和大写 A 的“Agile”都已演变成臃肿、仪式化的框架，制造过多会议、教条式指标和扭曲激励，却很少真正改善软件交付。许多工程师表示，Scrum 在响应式或运维工作、大型组织以及多团队环境中表现很差，并认为那些被归咎于“实施不当”的问题其实是结构性的。与其依赖流程表演，不如采用 Kanban、轻量级增量规划、扎实的回顾会，以及由团队自定义的流程；只要再配合称职的领导、真正的信任，以及对结果而非流程作秀的关注，效果通常更好。
理论中的 Scrum 与现实中的 Scrum
- 很多评论者区分“教科书式”的 Scrum 和公司实际在做的事情。
- 常见观点：这个框架在纸面上很轻量，但会被变成一种僵化、自上而下的官僚体系，伴随着认证、行话和工具（尤其是 JIRA、SAFe）。
- 有人认为，这种颠倒违背了《敏捷宣言》中“个体和互动胜过流程和工具”的原则。
会议过载与生产力损失
- 反复有人提到，由于各种仪式和状态会议，工程师每天真正能工作的时间只有 3–4 小时（甚至更少）。
- Sprint、站会、梳理需求、PI planning，以及“所有人”会议常常叠加在一起，尤其是当一个人同时在多个团队里时。
- 试图限制会议时间，往往只是把同样的讨论转移到“幽灵”会议或聊天里。
Story points、估算与速度
- 对 story points 的强烈不满：膨胀、政治化，以及尽管一直强调“点数 ≠ 时间”，却仍被和时间混为一谈。
- 团队常常会把估算做大，或者操纵燃尽图，让自己看起来更好，从而扭曲计划。
- 有些人认为点数对团队内部规划有价值；也有人主张 #noestimates，或者只用简单的任务数量 / T 恤尺码。
Scrum 何时有效，何时失效
- 更适合：小而专注的产品团队、出售 sprint 的咨询公司，或需要结构化管理的初级成员较多的团队。
- 经常失效于：Ops/DevOps、响应式 / 值班工作、基础设施、支持、硬件，以及优先级不断变化的大型组织。
- Sprint 会变成事实上的截止日期，并鼓励把原子化工作拆成人为的 ticket，以及把未完成的功能藏在 flag 后面。
替代方案与调整
- 许多人在运维和持续产品工作中更喜欢 Kanban：持续流动、WIP 限制、更少仪式。
- 也有人提到 XP、临时性的增量开发，或者 37signals 的 Shape Up，更接近敏捷的精神。
- 一些团队实际上在使用混合模式：最少的规划、短周期增量、少量会议、持续交付。
文化、管理与回顾会
- 一个强烈主题是：糟糕的文化和薄弱的领导力会让任何方法论都变得痛苦；Scrum 只是把这种失能暴露出来。
- 对“敏捷教条式模仿”（cargo cult agile）以及经验不足的管理者把流程和指标武器化、却回避真正责任的批评。
- 一些人认为 retrospective 是 Scrum 最有价值的实践；只要团队能诚实地改变流程，Scrum 往往会更有效。