長期對軟件項目進行“成功(或失敗)”評級的斯坦希集團(Standish Group)認為，如果一個項目能夠“在計劃的時間、預算內完成，并達到所有計劃之內的預期特征和功能”，便稱之為成功。這個定義不是以創(chuàng)造價值為基礎的，而是以各種條條框框為基礎的。按照這樣的定義，項目經(jīng)理們就只能緊遵計劃執(zhí)行，而不會去應對任何突發(fā)的變化。
傳統(tǒng)的項目負責人也罷，敏捷的項目負責人也罷，都會制定計劃，而且會為之投入相當?shù)臅r間。但是他們對待計劃的態(tài)度截然不同。雖然他們都把計劃當作底線，但是傳統(tǒng)的項目負責人會按照這個底線，時不時對實際的結果試圖“糾正”。
計劃設定的條條框框依然重要，依然指導著項目的執(zhí)行，但是我們也應該清楚，計劃并非圣旨那樣尊不可違，而是具有一定的靈活性的;計劃應該成為行動的指南，而不是緊箍咒。相反，如果把客戶價值和質量作為最終目標，那么計劃就成了實現(xiàn)這些目標的手段，而非目標本身。頭腦敏捷的負責人會預見項目執(zhí)行中的不確定性變化，并靈活應對，而不是固守原來的計劃。實踐中，他們深知預估性判斷的局限性，因而更信賴自己的變通能力，即根據(jù)變化對項目的步驟和做法進行調整。
在敏捷項目管理中，我們采用“調整性行為”來說明應該采納的一些正確做法(其中之一便有可能是糾正計劃本身)。
在關于敏捷處理原則的文件中——包括敏捷宣言(Agile Manifesto, AM)和相互依賴宣言(Declaration of Interdependence, DOI)——有對怎樣隨機調整做出的五條主要說明：
預見項目執(zhí)行中可能發(fā)生的不確定性，并且通過試點、預估性判斷和隨機調整來管控這些不確定性。
通過采取符合具體情況的策略、步驟和做法，提高項目的效率和可靠性。
面對突發(fā)性變化，應該調整計劃予以應對，而非繼續(xù)執(zhí)行原計劃。
哪怕項目已臨近收尾，也要對客戶在項目要求上提出的變化持歡迎態(tài)度。敏捷的項目過程能夠控制并利用這些變化，來保證客戶的競爭優(yōu)勢。
對于如何更好地提高效率，團隊要定期反思，然后根據(jù)總結出的經(jīng)驗，對團隊行為進行調整或改善。
以上原則可以歸納為兩點：
知曉變化(即不確定因素)可能隨時發(fā)生，面對突發(fā)的變化，要進行相應的調整，而不能繼續(xù)按原計劃執(zhí)行。
必要時，對項目的過程和實施辦法做出隨機調整。
這種應對變化調整的能力，能夠激發(fā)團隊的競爭優(yōu)勢。想像一下，如果能夠每周發(fā)布一款新的產品，會為團隊帶來什么樣的機遇 (而不是問題);如果能夠整合性能，為客戶提供個性化軟件服務 (并保持很低的維護成本)，又會給團隊帶來怎樣的競爭優(yōu)勢!
因此團隊必須靈活調整，但調整的同時，也應保證項目的既定目標始終不變。此外，無論是做出調整，還是進行預估性判斷，都要問下面的四個問題，來對項目的進展做出時時評估：
(1) 最終的產品是否能夠體現(xiàn)(客戶/團隊的)價值?
(2) 產品的質量目標——可靠性和兼容性——是否達成?
(3)在可接受的限制條件下，項目進展是否令人滿意?
(4) 當管理、客戶以及技術等發(fā)生變化時，團隊能否做出有效的調整和應對?
字典上把變化(change)定義為：“帶來不同，給出一個完全不同的形式或外表”;把調整(adapt)定義為：“使適于或適應某一特定的用途或情形”。由