以下是為什么敏捷方法行之有效的原因：
1. 敏捷方法和傳統的計劃驅動方法的兩個主要區別
i. 預測性計劃（Predictive Planning）和自適應計劃（Adaptive Planning）
計劃驅動方法首先計劃要做的工作（plan your work），然后著手工作以完成計劃（work your plan）。這是一種帶有預測性質的方法，其衡量項目成功的標準則是我們是否按計劃、按時、按預算完成了工作。這種方法在很多領域里是適用的。但是對于軟件開發而言，如果我們的需求沒有辦法做到不變更的話，我們就無法保證我們的計劃以及其后的工作是不會變更的。Martin Fowler 向現場觀眾提出了一個問題，大意是你們當中有多少人的軟件開發項目的需求是一成不變的，結果沒有一位觀眾舉手。因此，敏捷方法引入了自適應計劃的概念，既然我們無法保證需求不變更，那么就讓我們隨時準備接受變更，接受挑戰吧。自適應計劃將計劃驅動的流程縮短為以數周為單位的循環周期，在每一個周期中，我們根據當前的情況不斷地調整計劃以及計劃的執行過程，同時不斷地產生能夠工作的代碼，并且不斷地將代碼部署到應用環境中去。當然要實現這個目標我們需要一些具體方法的支持，如：自
測試代碼（Self-Testing Code），持續集成（Continuous Integration），重構（Refactoring），和簡潔設計（Simple Design）等等這些技術層面上的方法。Martin Fowler 指出，一些公司和項目之所以受困于敏捷方法，原因之一是他們忽略了這些技術層面的方法，而僅僅實施了
項目管理層面的方法。
ii. 以流程為本（Process First）和以人為本（People First）
在傳統的方法論中，我們總是需要事先定義好工作的方法和流程，然后“工人們”被要求遵照這些方法和流程來工作。在軟件開發領域，很多人把軟件開發過程等同于軟件本身，也就是說，軟件開發的過程也如同軟件程序般象機器一樣運行，組件之間環環相扣，嚴密地協同工作。問題是軟件開發的核心是人，人相對于機器零件和流水線而言，是相對不可預測的和不那么精密的。所以敏捷方法反其道而行之，提倡將“首先定義流程，然后要求軟件開發人員遵照流程工作”變為“讓參與軟件開發的人員自己來定義和選擇適合他們的流程”。簡單來說就是以人為本，不把人當螺絲釘，發揮人的主觀能動性，當然前提是需要團隊成員有較高的平均素質。
2. 溝通（Communication）
Neal Ford 讓我們回顧或想象一下失敗的軟件開發項目，它們的失敗是由于技術因素還是人的因素呢？《人件》的作者認為都是人的因素。人類的社會性決定了溝通的重要。Neal 舉了幾個有趣的例子，如：監獄里的犯人寧愿和其他人渣待在一起也不愿被關禁閉。很多國家禁止駕駛員駕駛時打
移動電話，那為什么和乘客聊天就沒有問題呢？原因是直接對話是最為有效和便捷的溝通方式，信息的傳遞在對話過程中非常順暢和完整。雖然現在的移動通訊已經非常先進，信號質量也很高，但是我們的通話過程仍然是有損的，我們的大腦這個時候就需要努力地試圖將通話信息拼湊得更完整以便能夠理解對方的意思，因此才會分散駕駛的注意力。隨后，Martin Fowler 舉了另一個例子，拿他做水果蛋糕的方法和他在酒店的浴室中沖涼的方法來進行比較。因為做水果蛋糕的整個流程和配料都是非常固定的，所以他只需要按步照搬地烹飪即可做出味道非常一致（地好或者差）的水果蛋糕。而在酒店中沖涼就有些不同，因為每一個酒店浴室的開關設計幾乎都是不一樣的，所以他需要不斷地調整開關來獲得一個理想的水溫，也就是需要不斷地重復“調整開關”（輸入），“用手試溫”（輸出）這個過程。相對于做水果蛋糕，在酒店浴室沖涼更好地反應了軟件開發的特征，這就是在軟件開發領域中，如果我們善于根據用戶反饋的信息來做出新的判斷和調整，就有可能提高產品的質量和用戶的滿意度。
溝通的確是一個非常重要的環節，它是敏捷方法的核心。在敏捷方法中，
單元測試是程序員和代碼組件的溝通，
功能測試是程序員以及QA和系統的溝通，故事墻（Story Wall）和回顧（Retrospective）是團隊和成員之間的溝通，功能演示（Showcase 或者 Demo）是團隊通過產品和最終用戶的溝通，持續集成（Continuous Integration）是產品和企業計算環境的溝通。溝通好了，什么事情都可以妥善解決，溝通得不好，好事也會變壞事。和廣大技術愛好者交流溝通也是酷殼存在的目的和意義。
整個演講時長一個小時，本文只是節選了我認為比較有意思的觀點加上本人的理解寫成，如有錯誤之處歡迎指正，不同看法歡迎交流。