一、個體和互動勝過過程和工具

　　團隊的構建要比環境的構建重要得多。許多團隊和管理者就犯了先構建環境，然後期望團隊自動凝聚在一起的錯誤。相反，應該首先致力於構建團隊，然後再讓團隊基於需要來配置環境。

二、可以工作的軟體勝過面面俱到的文件

　　對於團隊來說，編寫並維護--份系統原理和結構方面的文件是一個好主意，但是那份文件應該是短小的(short）並且主題突出的(salient)。“短小的”意思是說，最多有一二十頁；"主題突出”的意思是說，應該僅論述系統的高層結構和概括的設計原理。

三、客戶合作勝過合同談判

　　不能像訂購日用品一樣來訂購軟體。你不能夠僅僅寫下一份關於你想要的軟體的描述，然後就讓人在固定的時間內以固定的價格去開發它。所有用這種方式來對待軟體專案的嘗試都以失敗而告終。
　　成功的專案需要有序、頰繁的客戶反饋。不是依賴於合同或者關於工作的陳述，而是讓軟體的客戶和開發團隊密切地在一起工作，並儘量經常地提供反饋。
四、響應變化勝過遵循計劃

　　較好的做計劃的策略是:為下兩週做詳細的讓劃，為下三個月做粗略的讓劃，再以後就做極為粗糙的計劃。我們應該清楚地知道下兩週要完成的任務，粗略地瞭解下以後三個月要實現的需求。
至於系統年後將要做什麼,有-一個模糊的想法就行了。
　　計劃中這種逐漸降低的細緻度，意味著我們僅僅對於迫切的任務才花費時間進行詳細的計劃。--旦制定了這個詳細的計劃，就很難進行改變，因為團隊會根據這個計劃啟動工作並有了相應的投入。然而，由於計劃僅僅支配了幾周的時間，計劃的其餘部分仍然保持著靈活性。