1、由于全部产品决策权皆归“产品拥有者”所有，因此 Scrum 不允许工程师们在产品方向的各个层级当中作出任何产品决策，且严格控制其产品管理权。
2、Scrum 以紧密管理方式占用了工程师们的全部时间，因此会阻碍大多以自发形式出现、且无法匹配任何具有良好可预测性的时间表或系统的创新活动。
3、Scrum 鼓励“尽可能减少工作量”类解决方案，旨在满足严格的可预测性要求。
4、通过将每项任务拆分成理论上可由团队中任何成员完成的小型项目，Scrum 实际上并不鼓励工程师们对自己的工作内容形成自豪感或所有权。这种所有权的缺失将导致：
5、Scrum 对修改任务极度不友好，而这一理念的支持者们在实现当中往往采取全有或全无的态度。
“Scrum 的角色、工作内容、事件以及规则是不可改变的，且尽管可以仅采用 Scrum 的部分理念，但结果却与 Scrum 无关。Scrum 只存在于其中 ，并充当其它技术、方法及实践的容器。”
6、Scrum 对于自我反省的低容忍态度贯穿于其全部实践当中。只有在 Scrum 框架内部运行的流程才能够进行修改——而就 Scrum 本身而言，其基本规则可谓“神圣不可侵犯”。
7、Scrum 是一种重度管理工具。典型的团队当中需要具备产品拥有者、Scrum Master 以及团队负责人。但实际上，创新且积极的团队要求更少干涉、更好管理——Scrum 显然恰恰相反。
8、Scrum 通常使用非常差劲的任务管理工具（例如 Jira、tfs 等等），这些工具会对 Scrum 的执行作出非常官僚化的解释，因此导致开发人员的时间被大量浪费。此外，无论效能多么低下，Scrum 都会将工程师们牢牢锁定在这一种运营模式当 。
9、Scrum 不鼓励修正 bug、减少技术债务或者冒险，这是因为其极为狭隘地仅关注执行产品负责人认为有价值的项目。
10、Scrum 具有虚伪性：
-
经理或产品拥有者往往并没有对所开发的产品进行全程追踪及评估，也很少提供指导性意见。
-
并未要求他们以每两周一次的频率组织会议以证明当前工作的正确性。
-
并未要求他们提供详尽图表以证明目标是否已经阶段性完成。
11、Scrum 作出大量错误的假设：
-
其假设工程师们不具备任务追踪系统（但实际情况恰恰相反），因此需要时间管理手段以约束其时间分配方式。
-
其假设工程师们无法指导自己的工作内容。
-
其假定工程师们在未经严格监督的情况下，无法与组织的最佳利益保持一致。
-
其假设工程师们无法在缺少协调员（Scrum Master）的前提下高效进行会议讨论。
-
其假设可以通过在冲刺阶段 / 库存清理阶段通过讨论规划软件任务中的各方面问题。
-
其假设所有工程师都以同样的方式工作。
12、Scrum 故事点被广泛认定为毫无意义，但其仍在组织内的各个层级中被加以追踪、记录与展示，且继续作为团队绩效的惟一指标（即速度）。
