作者 | 亚当·阿德
编辑| 爱丽丝
1、由于所有产品决策权都属于“产品所有者”，因此Scrum不允许工程师在产品方向的各个层面做出任何产品决策，并严格控制他们的产品管理权限。
2. Scrum以严格管理的方式占用了工程师的所有时间，从而阻碍了大多数自发发生的创新活动，并且无法适应任何具有良好可预测性的时间表或系统。
3. Scrum 鼓励“尽可能减少工作量”的解决方案，旨在满足严格的可预测性要求。
4. 通过将每项任务分解为理论上可由团队任何成员完成的较小项目，Scrum 实际上并没有鼓励工程师对他们正在从事的工作产生自豪感或主人翁意识。 缺乏所有权会导致：
5、Scrum对于修改任务极其不友好，这一理念的支持者在实施中往往采取全有或全无的态度。
“Scrum 的角色、工作、事件和规则是一成不变的，虽然可以只采用 Scrum 哲学的一部分，但结果与 Scrum 无关。 Scrum 只是存在于其中，并充当其他技术、方法和实践的容器。 ”
6. Scrum 对自我反思的低容忍度贯穿于它的所有实践中。 只有在 Scrum 框架内运行的流程才能被修改——就 Scrum 本身而言，它的基本规则是神圣不可侵犯的。
7. Scrum 是一个重型管理工具。 一个典型的团队将有产品负责人、Scrum 和团队负责人。 但实际上，创新和积极的团队需要更少的干预和更好的管理——Scrum 显然相反。
8. Scrum通常使用非常差的任务管理工具（如Jira、tfs等）。 这些工具会对Scrum的执行提供非常官僚的解释，从而导致开发人员大量时间被浪费。 此外，Scrum 将工程师锁定在一种操作模型中，无论效率有多低。
9. Scrum 不鼓励修复错误、减少技术债务或承担风险，因为它极其狭隘地专注于执行产品负责人认为有价值的项目。
10. Scrum 是虚伪的：
11. Scrum 做出了很多错误的假设：
12. Scrum 故事点被广泛认为毫无意义，但它们仍然在组织的各个层面上被跟踪、记录和显示，并且仍然是团队绩效（即速度）的唯一指标。
13. Scrum 旨在管理能力最差的工程师，但这可能会限制更有才华的人。
14. Scrum 与最初的敏捷宣言中提出的许多想法完全相反：
15. Scrum忽略了这样一个事实：软件开发领域中任何已完成的任务都可以重复使用和再次使用，而无需重新构建。 这意味着在 Scrum 范围内，任何新的软件任务都是从头开始，这使得我们很难对其进行估计。