實行敏捷開發以來，慢慢體悟到很多文化、思維與傳統模式（瀑布）上的差異。逐漸感受到這不只是一種方法論，而是一種文化及信仰的力量。一個失敗的產品，可能的原因很多。先不論外在資源、環境等因素，單單就團隊內部能量是否能夠完全展現，就是一個很值得討論的問題。
創新能量
在傳統的瀑布模式下，修改需求、功能異動，很自然的被視為一種麻煩、特例，不應該時常出現的東西，並不會擁有一個動態的 Backlog 記錄需求，需求異動就得重拉精美的 Excel wbs、PPT 簡報、Word 需求文件、設計文件...。在這樣的氛圍下，自然會導致團隊內部的聲音越來越小，最熟悉產品細部功能的開發人員漸漸的沒有任何意見，把一切需求相關的責任都推給 PM。最常見的情境是，尚未被同化的菜鳥提出相當有建設性的創意想法，卻被白眼，要求順道提供配套的執行細節等。友善一點的團隊會給予肯定，接著直接將這麼棒的點子 Assign 給這位有熱情的菜鳥執行，但瀑布開發忌諱不斷地異動時程，那就用燃燒熱情加班做完吧！久而久之再也沒有人會提出什麼好的點子了，造就了一個不鼓勵創新的文化。
然而，敏捷文化敞開雙手歡迎需求異動，今天若有任何人提出很棒的點子，那就直接記錄在動態的 Product Backlog 上，讓 PO 排序決定優先序。待某次 Sprint 要執行此項目時，再由有興趣的同仁自行認領開發。雖然不能說是有什麼鼓勵風氣，但至少是一個不排斥創新思維的文化。
發覺問題
除了創新之外，發覺既有問題也是提高產品價值的重要環節。團隊在開發過程中，必定會察覺開發流程、產品設計等總總問題。然而，有時候發現的並不僅僅是一個 bug，而是整個系統設計上淺在的問題，如同技術債一般依附產品中，總有一天會引爆。但在瀑布文化下，提出問題如同需求異動一般，是一種不被潛意識接受的行為。正因為這是一個令人煩躁的訊息，往往會聽到任何一個利害關係的老鳥、主管或 PM 表示：「提出問題的同時，請提出你的解決方針。」，造就一個不鼓勵提出問題的氛圍。產品就這樣附著著問題持續的滾動著，大家逐漸習慣這樣「不完美」的產品。
在敏捷文化中，擁有一個定時召開的 Retrospective 會議，鼓勵大家提出問題、描述事實、表達感受，最不一樣的是―提出問題的人不被要求同時交付解決方針。問題屬於團隊，而非個人，當這個問題是真正存在的事實，團隊就應該共同去面對。暫時無法解決的項次，也將被記錄下來。
組織撕裂
綜上所述，瀑布模式下，所有利害關係人戰成一片。資深戰資淺，不好好做事問題一大堆；RD 戰 PM ，需求不好好蒐集一改再改。耗費許多額外的精力在於內部溝通。
然而敏捷文化重視的是團隊，無論是問題或是需求，都是屬於團隊而非個人。大家關心的是如何能夠交付最棒的產品，而不是提出想法時的利害得失。
總歸來說，軟體開發唯一不變的就是變。採用瀑布式開發從根本上來說就是一種矛盾，於文化上更是衝突不斷。面對每次的變更都只能說服自己這是特例，下次不會這樣了，需求蒐集好就沒事、多作幾次就會順了、...。
