在软件开发的浪潮中，各种敏捷开发方法层出不穷，传统的“瀑布式”开发一夕之间遭受各种质疑。为什么“瀑布式”开发的小船说翻就翻？到底哪里出了问题？
各类大中小型企业所运用的传统软件构建方法，即是众人皆知的“瀑布”型开发方法。此模型存在很多变体，但其典型性是在开发初期制定详细的计划，在计划中最终产品己被仔细研究，设计，并且一切详细资料都记录在案。
任务已设计制定，并且在工作中使用如Gantt (甘特)图表等工具和Microsoft Project项目管理软件。开发团队预计开发项目的时间是以累计其相每关一步骤而得出的。当项目管理者(stakeholder)全面审核开发计划并表示赞同，开发团队即时开始工作。团队成员完成他们所专长的部分工作，即刻转交给其他成员，形成生产流水线的形式。当全部工作都已完成，成品将会转交给产品质量控制部门，在这里将会进行在产品到达客户手中之前的全面检测。在整个流程中，所有相对于原始计划的分歧都将受到严格的控制，以保证生产的成品与原始设计保持一致。
此种模式有优点但也有不足之处。它的最大的优点是非常有逻辑性：在构建之前思考，并全部记录下来，按照计划实施，保持各项事务尽可能的有组织性。它有一个最大的弱点就是：人的参与。
比如：此种方式要求所有的建议和想法都要在开发周期的起始阶段提出，此时建议和想法将可以被融入开发计划之中。但是众所周知，好的想法和建议的出现会贯穿整个开发过程——在开发启始阶段，在开发中期，有时可以在产品交付使用的前一天，如果整个开发过程中不容许变化的产生，那么将会遏制创新的产生。在使用“瀑布”型开发方式时，开发末期出现的创新将不是好的征兆，而是对整个产品开发产生的危机。
瀑布型开发方式特别注重将事件记录在案，以此作为传递重要信息的首要方法。因此合理的假定是如果我可以把我的想法尽可能都记录下来，这样将会使信息更可靠的传输到团队每一个成员的头脑中；另外，因为所有东西都记录在案，这将是我完成任务的实际的证据。但是实际上，在大多数情况下，没人会读这些50页左右的详细规格要求资料。同样，如果有人读取该资料，那么将会产生许多的误解。记录的资料只是我头脑中想法的抽象提取；当你阅读此资料时，你将会产生另一个抽象的概念，此时与我的真正想法已经相距甚远了。所以严重误解的产生也就不足为奇了。
当人参与时,还有一种情况会发生——“实际应用中产生的灵感”——在第一次实际应用产品时，你可能会立刻产生20种使产品更加完美的灵感。但是遗憾的是，这些非常有价值的想法通常会在产品开发的末期产生，这时创新是困难和具有分裂性的——换句话说，是做正确抉择昂贵的时刻。
人的预知未来的能力是有限的。比如，某场比赛的终结果是出人意料的。不可预测的技术问题的突然出现，会强制开发方向的转变。此外，人们往往非常欠缺对于未来作出长远计划的能力——今天猜测未来八个月中每周你如何工作将如幻觉般渺茫，这正是Gantt (甘特)图表的衰败表现。
另外，瀑布型方式将会促使团队成员在交接工作时产生敌对的关系。“他要求我构建在规范要求中不存在的东西。”“她经常改变主意。”“我不可能对我不能控制的东西负任何的责任。”这些都引起我们对瀑布方式的另一种思考——在此种方式中工作毫无兴趣可言。事实上，进一步说，瀑布型方式是造成产品开发人员苦恼的根源，并且最终产品将不会体现出他们的创造力，技能和开发创造者的激情。人不是机器人，此种将人认为是机器人的流程将会造成人们工作激情的丧失。
一个僵硬的，拒绝变革的流程也会造成低劣产品的产生。客户可能会得到根据他们第一需求所生产的产品，但是产品在形成阶段时还是客户真正需要的吗？在开发之前收集所有的需求并将它们嵌入毫无改变可言的顽石般的计划中，此产品将被宣告只会和起始的想法保持一致，而不是开发团队在实践中不断发现可能性而使其尽善尽美。
许多使用瀑布型方式的团队不断的体验到了它的缺陷，但是它看起来是如此富有逻辑性的方式，因此第一的自然反应就是对内部工作的谴责：“如果我们尝试更好的使用它，它将会发挥作用”——如果我们计划的更详尽，记录更详细，更严格的拒绝任何变革，一切将会很顺利地进行。遗憾的是，许多开发团队只得到的相反的效果：他们越竭尽全力尝试此方法，得到的结果越差！
如此，“瀑布式”开发的小船说翻就翻就不足为奇了。