在真正的敏捷方法中，对问题的反应总是缩短反馈循环。从来都不是“更好地计划”。
众说纷纭：
这太绝对了，计划多少也是一个权衡。有时，使用软件您无法轻松撤销决定。有时您需要依赖于制造商、硬件采购、政府政策等。为什么要从工具箱中删除计划这种工具？可以改进计划。
这听起来有点“不假思索地向前冲”。我坚信有一个健康的计划，可以考虑已知的未知数。
如果失败的代价很小，这很好。“嘿，我的网站崩溃了”是更快速的反馈可以提供帮助的一个例子。“嘿，我的火箭因为故障而爆炸了”是一个反例。
缩短故障的反馈回路可能是对可疑设备进行台架测试可能的解决方案。最短的反馈循环不会是发射另一枚火箭。这通常是一个小故障，因为它是出乎意料的，而不是计划外的。
这个想法的另一种说法：“敏捷”的一个定义是：“当面临问题时，我们是倾向于阶段（瀑布）还是远离阶段（敏捷）？” 在这个定义中，强化冲刺和计划冲刺是瀑布思维。
我已经在敏捷团队工作了十五年。我还没有看到敏捷“完成”任何事情，但我认为这就是重点。这是繁忙工作的递归延续。
这段话应改写为：“当事情没有按计划进行时，传统方法是对未来更好地计划或聘请更好的实施者。敏捷方法是考虑缩短反馈循环是否更好。”
持续学习并对计划再计划，Planing必不可少，但是Plan毫无用处。