长期对软件项目进行“成功(或失败)”评级的斯坦希集团(Standish Group)认为，如果一个项目能够“在计划的时间、预算内完成，并达到所有计划之内的预期特征和功能”，便称之为成功。这个定义不是以创造价值为基础的，而是以各种条条框框为基础的。按照这样的定义，项目经理们就只能紧遵计划执行，而不会去应对任何突发的变化。
计划设定的条条框框依然重要，依然指导着项目的执行，但是我们也应该清楚，计划并非圣旨那样尊不可违，而是具有一定的灵活性的;计划应该成为行动的指南，而不是紧箍咒。相反，如果把客户价值和质量作为最终目标，那么计划就成了实现这些目标的手段，而非目标本身。头脑敏捷的负责人会预见项目执行中的不确定性变化，并灵活应对，而不是固守原来的计划。实践中，他们深知预估性判断的局限性，因而更信赖自己的变通能力，即根据变化对项目的步骤和做法进行调整。
传统的项目负责人也罢，敏捷的项目负责人也罢，都会制定计划，而且会为之投入相当的时间。但是他们对待计划的态度截然不同。虽然他们都把计划当作底线，但是传统的项目负责人会按照这个底线，时不时对实际的结果试图“纠正”。在敏捷项目管理中，我们采用“调整性行为”来说明应该采纳的一些正确做法(其中之一便有可能是纠正计划本身)。
在关于敏捷处理原则的文件中——包括敏捷宣言(Agile Manifesto, AM)和相互依赖宣言(Declaration of Interdependence, DOI)——有对怎样随机调整做出的五条主要说明：
预见项目执行中可能发生的不确定性，并且通过试点、预估性判断和随机调整来管控这些不确定性。
通过采取符合具体情况的策略、步骤和做法，提高项目的效率和可靠性。
面对突发性变化，应该调整计划予以应对，而非继续执行原计划。
哪怕项目已临近收尾，也要对客户在项目要求上提出的变化持欢迎态度。敏捷的项目过程能够控制并利用这些变化，来保证客户的竞争优势。
对于如何更好地提高效率，团队要定期反思，然后根据总结出的经验，对团队行为进行调整或改善。
以上原则可以归纳为两点：
知晓变化(即不确定因素)可能随时发生，面对突发的变化，要进行相应的调整，而不能继续按原计划执行。
必要时，对项目的过程和实施办法做出随机调整。
这种应对变化调整的能力，能够激发团队的竞争优势。想像一下，如果能够每周发布一款新的产品，会为团队带来什么样的机遇 (而不是问题);如果能够整合性能，为客户提供个性化软件服务 (并保持很低的维护成本)，又会给团队带来怎样的竞争优势!
因此团队必须灵活调整，但调整的同时，也应保证项目的既定目标始终不变。此外，无论是做出调整，还是进行预估性判断，都要问下面的四个问题，来对项目的进展做出时时评估：
(1) 最终的产品是否能够体现(客户/团队的)价值?
(2) 产品的质量目标——可靠性和兼容性——是否达成?
(3)在可接受的限制条件下，项目进展是否令人满意?
(4) 当管理、客户以及技术等发生变化时，团队能否做出有效的调整和应对?
字典上把变化(change)定义为：“带来不同，给出一个完全不同的形式或外表”;把调整(adapt)定义为：“使适于或适应某一特定的用途或情形”。由此看来，变化和调整不仅不同，而且差异很大。变化是突发的，是没有目的性的，比如字典中给出的这个解释：“发生了某件事”。而调