各類大中小型企業所運用的傳統軟件構建方法，即是衆人皆知的“瀑布”型開發方法。此模型存在很多變體，其典型性是在開發初期制定詳細的計劃，在計劃中最終產品已被仔細研究，設計，並且一切詳細資料都記錄在案。任務已設計制定，並且在工作中使用如根特圖表等工具和microsoft project項目管理軟件進行項目管理工作。開發團隊預計開發項目的時間是以累計其相關每一步驟而得出的。當項目管理者(stakeholder)全面審覈開發計劃並表示贊同，開發團隊即時開始工作。團隊成員完成他們所專長的部分工作，即刻轉交給其他成員，形成生產流水線的形式。當全部工作都已完成，成品將轉交給產品質量控制部門，在這裏將會進行在產品到達客戶手中之前的全面檢測工作。在整個流程中，所有相對於原始計劃的分歧都將受到嚴格的控制，以保證生產的成品與原始設計保持一致。此種模式優缺點明顯。有點是非常有邏輯性，在構建之前思考，並全部記錄下來，按照計劃實施，保持各項食物儘可能的有組織性。弱點是人的參與。比如，要求所有的建議和想法都要在開發週期的最初階段提出，此時建議和想法將可以被溶入到開發計劃中，但是衆所周知，好的想法和建議的出現會貫穿整個開發過程，在開發最初的階段，在開發中期，也可能在產品交付前一天，如果整個開發過程中不容許變化的產生，那麼將會遏制創新的產生；另一點就是諸如定型老產品用新技術重新替換之類項目，由於需求分析階段的盲從性及時間緊迫等等因素的干擾，導致分析出現偏差，最終帶來的後果是預估時間不夠，項目進展達不到預期的目標，對整個產品開發帶來危機。瀑布式開發方式特別注重將事件記錄在案，以此作爲傳遞重要信息的首要方法。因此最合理的假定是如果我們可以把想法儘可能地記錄在案，這樣將會使信息更可靠地傳輸到團隊的每一個成員的頭腦中，但是很多情況下沒人會大量閱讀文檔，即便閱讀了也會有產生誤解的可能性。
當人蔘與時，還有一種情況會發生――“實際應用中產生的靈感”――實際開發過程中很多創意是到開發的最後階段才被提出並且實現的。在項目最初階段無法準確判斷開發的走向。
人的預知未來的能力是有限的。不可預測的技術問題的突然出現，會強制開發方向的轉變。此外，人們對於未來作出長遠計劃的能力的欠缺也導致了你無法估計出未來數月內每週你的工作安排。
另外，瀑布式開發由於成員經常改動想法或不能對不能控制的東西負責等等此類容易促使團隊成員產生敵對的關係，讓工作毫無興趣可言。事實上，進一步說，瀑布式開發是造成產品開發人員苦惱的根源，並且最終產品將不會體現出他們的創造力，技能和開發創造者的激情。人不是機器人，此種將人認爲是機器人的流程將會造成人們工作激情的喪失。
另外，一個拒絕變革的流程也會造成低劣產品的產生，最原始的需求未必和最終的產品相一致，拒絕開發團隊在實踐中不斷髮現可能性而是其盡善盡美的計劃也會是一個失敗的計劃。
許多使用瀑布型方式的團隊不斷的體驗到了它的缺陷，但是它看起來是如此具有邏輯性的方式，因此第一的自然反映就是對內部工作的譴責：“如果我們嘗試更好的使用它，如果我們的計劃更加詳盡，記錄更加仔細，拒絕任何變革，一切將會很順利地進行。遺憾的是，許多開發團隊只得到的相反的效果；結果越差。”