头脑敏捷的负责人会预见项目执行中的不确定性变化，并灵活应对，而不是固守原来的计划。实践中，他们深知预估性判断的局限性，因而更信赖自己的变通能力，即根据变化对项目的步骤和做法进行调整。
首先，看一下企业对“成功”是如何定义的。长期对软件项目进行“成功(或失败)”评级的斯坦希集团(Standish Group)认为，如果一个项目能够“在计划的时间、预算内完成，并达到所有计划之内的预期特征和功能”，便称之为成功。但是，这个定义不是以创造价值为基础的，而是以各种条条框框为基础的。按照这样的定义，项目经理们就只能紧遵计划执行，而不会去应对任何突发的变化。
相反，如果把客户价值和质量作为最终目标，那么计划就成了实现这些目标的手段，而非目标本身。计划设定的条条框框依然重要，依然指导着项目的执行，但是我们也应该清楚，计划并非圣旨那样尊不可违，而是具有一定的灵活性的;计划应该成为行动的指南，而不是紧箍咒。
传统的项目负责人也罢，敏捷的项目负责人也罢，都会制定计划，而且会为之投入相当的时间。但是他们对待计划的态度截然不同。虽然他们都把计划当作底线，但是传统的项目负责人会按照这个底线，时不时对实际的结果试图“纠正”。在敏捷项目管理中，我们采用“调整性行为”来说明应该采纳的一些正确做法(其中之一便有可能是纠正计划本身)。
在关于敏捷处理原则的文件中—包括敏捷宣言(Agile Manifesto, AM)和相互依赖宣言(Declaration of Interdependence, DOI)—有对怎样随机调整做出的五条主要说明：
>预见项目执行中可能发生的不确定性，并且通过试点、预估性判断和随机调整来管控这些不确定性。(DOI)
>通过采取符合具体情况的策略、步骤和做法，提高项目的效率和可靠性。(DOI)
>面对突发性变化，应该调整计划予以应对，而非继续执行原计划。(AM)
>哪怕项目已临近收尾，也要对客户在项目要求上提出的变化持欢迎态度。敏捷的项目过程能够控制并利用这些变化，来保证客户的竞争优势。(AM)
>对于如何更好地提高效率，团队要定期反思，然后根据总结出的经验，对团队行为进行调整或改善。(AM)
以上原则可以归纳为两点：
知晓变化(即不确定因素)可能随时发生，面对突发的变化，要进行相应的调整，而不能继续按原计划执行。
必要时，对项目的过程和实施办法做出随机调整。
这种应对变化调整的能力，能够激发团队的竞争优势。想像一下，如果能够每周发布一款新的产品，会为团队带来什么样的机遇(而不是问题);如果能够整合性能，为客户提供个性化软件服务(并保持很低的维护成本)，又会给团队带来怎样的竞争优势!
因此团队必须灵活调整，但调整的同时，也应保证项目的既定目标始终不变。此外，无论是做出调整，还是进行预估性判断，都要问下面的四个问题，来对项目的进展做出时时评估：
(1)最终的产品是否能够体现(客户/团队的)价值.
(2)产品的质量目标—可靠性和兼容性—是否达成.
(3)在可接受的限制条件下，项目进展是否令人满意.
(4)当管理、客户以及技术等发生变化时，团队能否做出有效的调整和应对.
字典上把变化(change)定义为：“带来不同，给出一个完全不同的形式或外表”;把调整(adapt)定义为：“使适于或适应某一特定的用途或情形”。由此看来，变化和调整不仅不同，而且差异很大。变化是突发的，是没有目的性的，比如字典中给出的这个解释：“发生了某件事”。而调整则恰恰相反，它意味着直奔目标而去(强调适合性)。由此可见，变化是无心而至，调整是有意为之。
调节项目中的已知和未知
哈佛商学院教授罗布·奥斯丁(Rob Austin)和同事李德文(Lee Devin)共同执笔发表了《艺术性管理》(Artful Making)一书。书中提到一个价值1.25亿美元的IT项目最终失败的案例。失败的原因正是由于合作企业一味坚持原计划，亦步亦趋死板执行，拒绝用调整来应对突发的变化而造成的。书中写道：“"为工作制定计划，然后按照计划做事"成了让他们盲从的真言，直接导致团队采取了毁灭性的做法，带来惨重的代价。……在商界，人人都以为这种问题很少发生，可实际上却非常普遍。”
每一个项目都有其已知的条件和未知的因素，有其确定的一面以及不确定的一面，因此每一个项目都必须在计划和随机调整之间取得平衡。这种平衡是必须的，因为项目可以是生产性的，也可以是开发性的，还可以是介于两者之间的。生产性的项目不确定性很低，而开发性的项目却是高度不确定的。开发性项目强调预见性，项目执行的过程，就是朝着预见的方向探索前进的过程，而不是制定出严密周详的计划，然后严格实施的过程。也就是说，计划或调整，不能说孰对孰错，管理者应根据项目自身的具体情况、具体条件，作出最恰当的选择。
