我们中的许多人都去过健身房，最初取得了良好的效果。一旦你的身体适应了，同样的程序可能会帮助你保持，但你不会看到任何进一步的进步，你甚至可能开始倒退。
我觉得 Scrum 作为交付软件项目的方法也遇到了同样的问题。Scrum 循环，或实践 Scrum 的方式，要么过于字面化，要么过于严格地坚持。
Scrum的目的是什么？
Scrum 应该是关于定义一个可实现的两周冲刺目标。Scrum 应该鼓励团队从经验中学习，在解决问题的同时自组织，并反思他们的得失以不断改进。
根据我的经验，不幸的是，Scrum 最终破坏了敏捷的核心原则，即人高于流程。这在很大程度上归结为管理不善和经过认证的 Scrum Master 的兴起。
站立会议是为管理者准备的
每日 Scrum 应该是一个 15 分钟的、有时间限制的活动，供开发团队计划接下来的 24 小时。不幸的是，站立会议已成为关注 JIRA ticket全面移动的媒介。在一组泳道上移动icket有点像将代码行数作为成功的衡量标准。开发人员可以仅仅因为他们移动工单的速度有多快而显得富有成效。另一方面，对董事会的关注会使处理具有挑战性的问题的优秀开发人员看起来很普通。
自组织团队
如果做得好，Scrum 鼓励团队从经验中学习，在解决问题的同时自组织，并反思他们的得失以不断改进。
在臭名昭著的 scrum master 所提倡的 scrum 中，您需要清除tickets，而且也没有对工作质量进行实际检查，这往往是由非技术项目所有者决定的。这会激励人们进入空灵状态并专注于输出代码。
神话般故事点不是神话
故事点是用于表达对完全实施产品待办列表项所需的总体工作量的估计的度量单位。或者，至少，他们应该是这样定义。
根据我的经验，故事点可以鼓励团队对系统进行游戏。在几次冲刺中都未能实现目标后，精明的项目经理会害怕在冲刺中投入太多。
对失败的恐惧导致了小故事冲刺，其中只使用小票tickets项目以确保它们的完成。大局变得无关紧要，专注于小事最终会使项目脱轨。
我在一个项目中亲眼目睹了这一点，其中每个故事都必须进行自动化测试。这些测试伴随着高昂的维护预算，而该项目的自动化测试使开发速度几乎停滞不前。当自动化测试成为焦点时，将开发和维护过程调整到两周的窗口中将持续集成构建时间升级到两个小时。管道停顿，被迫改变。
另外一个极端：开发人员和测试人员在累积技术债务的同时偷工减料。债务永远无法偿还，旋转的盘子最终会掉到地上，导致大规模且代价高昂的重新思考。
我们应该跟踪完成的工作而不是我们估计的工作，而不是依赖故事点。我觉得这令人震惊。如果我想知道类似的工作需要多长时间，我想知道实际时间而不是估计时间。如果您的所有故事都足够小，那么您就不需要估算。
Scrum 的前提不应该是一个千篇一律的工具适合地球上的每个开发团队。许多团队只是死记硬背，而其有效性的证据为零。让优秀的开发团队根据他们的环境自组织。跟踪什么被运送到生产中，在事后加上它花费的时间（以天为单位！），并跟踪它。