在观看世界橄榄球锦标赛时，你可能已经看到比赛中的许多冲刺和scrum。橄榄球语言中的scrum是，"一种重新开始比赛的方法，包括球员紧紧地挤在一起，低着头，试图获得球权"[参考文献]。 维基百科].像我这样的橄榄球门外汉需要时间来理解这一点，因为这似乎并不符合逻辑。为什么不直接拿起球就跑呢？
与橄榄球相比，Scrum如今似乎更与敏捷软件开发有关。它无处不在，而且非常成功。在我的公司（Kepner-Tregoe (KT)），我们的产品开发小组最近开发了一个新的产品系列 使用敏捷的方法.进步而不是完美是关键。
进展 - 这是否意味着 "没有时间"？
敏捷的使用对于许多应用来说可能是一条完美的道路。然而，根据我对某些团队和行业的经验，如何定义 "进展 "是令人担忧的，因为对我来说，"进展 "是决策的最重要标准。我的一个客户对我说："市场要求我们迅速做出反应，我们需要走在游戏的前面"。但是，考虑到不利的一面。为一个 "发现的根本原因 "制定的修复方案没有实施，那些负责根本原因分析的人向我解释说："为什么要找原因？反正它不会被修复"。而且，如果在冲刺阶段不优先考虑，他们为什么要找原因？令人不安的是，正常的维护等其他工作也被忽视了。团队被要求将开发活动集中在冲刺阶段的原因是为了获得竞争优势，并在市场上率先推出新功能。
把速度作为最重要的标准，就会有一种倾向，声称 "没有时间 "做其他重要的项目。当开发工作在压力下发生时，你如何将敏捷开发置于根源分析和实施修复之上？更不用说完成定期维护了？我同意在开发新的软件时可能不需要完美，但是，实施修复以消除根本原因是需要完美的。有多少次，一个新的软件引进失败是因为隐藏的问题没有被调查和纠正？我们把这些称为 潜伏的鳄鱼，随时等待攻击，尤其是在你最不期望的时候。
这不是一个 "没有时间 "的问题--我们都有同样的时间。是我们给某些事情的优先权造成了差异。
那么，谁在接球？
两党都应该。我知道这似乎是矛盾的。在橄榄球比赛中，只有一方可以拿起球，然而，双方都应该努力改善他们的战术，成为赢家。
负责根本原因分析的人应该为发展提供清晰和简明的投入。对问题的清晰描述和经过逻辑检验的根本原因，精确地描述假设，显示这个原因是如何产生麻烦的。这种描述应该增加开发团队内部的理解，为要采取的行动方案提供明确的理由。有了这种清晰的描述，开发团队就能更准确地评估出修复问题所需要的东西。例如，他们不是在 "这是一个软件错误 "上下功夫，而是在一个精确的原因上下功夫，例如，"当以xyz的速度运行时，由于限制设置得太严格，机器正在超时"。
清晰的描述，或者像我们在KT公司所说的那样，"分离和明确 "的工作片断也使团队能够通过研究来设定正确的优先事项。
- 当前的影响是什么？：它是如何影响当前的开发周期的。如果我们不修复它，我们的新开发还能工作吗？
- 未来的影响是什么：我们能把这个问题推迟多久，直到事情出现严重的问题？
- 时间框架：它是否适合当前的冲刺周期，我们需要多长时间？
如果双方都能集思广益，提高每场比赛的质量和战术，那么比赛的观赏性会好得多，参与的积极性也会高得多。
