下面就讓我們來看看敏捷流程如何將瀑布式流程的問題逐一破解：
● 瀑布式流程問題之一：
版本發布的時間越來越長。在敏捷流程中，版本是由一系列增量集成在一起組成的，這些增量通過一個一個迭代按順序開發。我們還可以在任意時間停止迭代。一旦發現產品的價值已經達到最大，尤其是發現軟件里過半的功能很少被使用的時候，就可以停止迭代。我們還可以在到達交付期限或者預算上限的時候，停止迭代并發布軟件。我們只會開發并積累有價值的增量。
● 瀑布式流程問題之二：
無法按時發布。在敏捷流程中，版本的發布延遲最多不會超過30天，因為每個迭代的最長期限就只有30天。當到達交付期限的時候，就可以交付累積的增量。由于不會在迭代中開發低價值的功能，因此可以比以往更早地發布完整的系統。在傳統開發流程中，常用功能占所有功能總數的不到一半。而在敏捷流程中，我們根本不會在不常用的功能上浪費時間。
● 瀑布式流程問題之三：
在版本發布的最后階段讓軟件穩定的時間越來越長。在敏捷流程中，每個迭代所產生的增量都是完整和可用的，后續迭代所產生的增量都會包含之前所有迭代產生的增量，因此任何迭代產生的增量都是完成且可用的。也就是說，沒有軟件穩定化時期，因為軟件一直保持穩定。
● 瀑布式流程問題之四：
做計劃的時間越來越長，而且不準確。在敏捷流程中我們不再做大而全的計劃，而只是設定最終目標，然后確定為了達到該目標所需的高價值功能和特性，同時還會確定交付日期以及估算成本。這樣在第一個迭代開始前做計劃所需的時間通常只有瀑布式或預測型流程的20%。我們只會為即將到來的迭代的需求做詳細的計劃，因此我們把每個迭代的計劃稱為“及時雨計劃”。另外值得注意的是，需求是涌現的，在評審迭代產生的軟件增量的時候，我們可能會發現下一個迭代需要實現的最佳需求。
● 瀑布式流程問題之五：
在發布期間很難進行改變。版本發布中期的概念在迭代增量式項目中已經不復存在了。我們能夠以最小的代價，在每個迭代開始前發現或者提出需求。
● 瀑布式流程問題之六：
質量持續惡化。在敏捷流程中，每個迭代產生的增量都是完整可用的。因此，增量必然已經通過質量測試。而后續迭代產生的增量同樣要滿足相同的質量要求，也就是說我們再也不必在項目的最后階段為了趕上交付期限而犧牲質量，因為質量始終伴隨著這個軟件的整個開發過程。
● 瀑布式流程問題之七：
拼命競賽進度使員工士氣受挫。版本穩定化階段已經不再需要了，因此加班的“死亡之旅”也隨之而去。