企业团队经常称自己为“敏捷”，但最终却陷入混乱的局面。问题出在哪里？与专家告诉你的截然相反...如果你是一个软件开发人员，你可能已经听过了这些话，“我们使用敏捷方法”，然后随着项目的进行，你开始怀疑，“嘿，这根本没有什么敏捷。”事实上，你开始觉得一切都是缓慢和官僚的。你整天都在和来自各地的12个人开会，试图决定一个特性（功能）。你甚至会见识到愤怒的脾气和政治倾向。
为了更好的理解，我们追根溯源回到敏捷的价值观上，敏捷软件开发宣言：
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档 客户合作 高于 合同谈判 响应变化 高于 遵循计划很简单，敏捷方法是关于人、交互和灵活性的。如今，71%的组织使用敏捷进行项目管理，而不是传统的瀑布式方法。瀑布方法怎么了？
瀑布方法是软件开发过程中一连串事件的逻辑流程。那么，如果传统的瀑布方法如此合乎逻辑，敏捷是如何获得优势的呢？因为技术本身和使用技术的企业已经变得超级快节奏并且由于计算机能力而具有竞争力，知识和市场机会变得更容易获得。今天可行的明天可能行不通。今天卖的东西明天可能卖不出去了。（为了便于理解，译者补充：上方内容描述的是时代的变革驱动敏捷的流行，下方表达的是因为敏捷不彻底，又出现所谓的AgileFall的现状）不幸的是，在现实世界中，特别是在企业软件开发中，最初作为敏捷的东西往往最终变为瀑布-人们等待着别人提供任务和详细的需求。有时它会变成两者的混淆。一个开发人员把这个（下方内容）发给我，由一位博主写的，并得到她的追随者的回应。她将这种困惑描述为“敏捷瀑布”-“一个软件开发模型，你试图做到敏捷，但却不断陷入瀑布的习惯”。可以参考下方的截图。
根据她的免责声明，作者一定是在IBM工作过...但为什么会发生这种情况，特别是在一个大组织中？
你也许经常会从顾问或“大师”那里听到这一点’。“我的工作是给你一个工作框架。有了它，你就可以找到解决办法。有了它，你将取得巨大的成果。”错了。框架有助于组织思想和过程。但他们没有完成任何其他的事情。然而，我已经意识到，良好的框架需要强有力的领导力，需要有头脑和执行经验来跟进；特别是在一个大组织中。实施时需要更多的关注领导力和协调，而不是伟大的团队结构和项目管理工具。这就是敏捷方法论，理论上很棒，但在实践中开始失败的问题点所在。领导力和文化，而不是昂贵的软件和工具，大量的企业软件开发团队由于缺乏人力协调和合作导致敏捷的使用陷入失败之地。他们过于依赖冰冷、毫无感觉的框架、工具和流程。快速、灵活的变化需要协作、理解和团队和谐。这就是我不太同意的敏捷宣言提出的原则之一：最好的体系结构、需求和设计来自于自组织团队为了让自组织的团队工作，公司文化和奖励制度必须提倡雇用自我激励、积极主动的个人。在创业世界中，创始人往往是开发人员，早期员工被给予股票期权，依靠主动性和自我激励可以工作。但是在有规则和政治的大公司里，让团队去自组织往往会导致团队变为一条无头蛇。因此，企业软件开发中的失败点往往是缺乏一个能够紧密协调、敏锐的决策、移情（有同理心）激励的强有力的领导者。这源于良好的逻辑和判断，以及良好的沟通和人际交往能力。这个领导者可以是产品所有者或项目经理；一个很好地理解最终用户和项目目标的人。这样就有人负责“大局”，可以看到零件是如何组合在一起的。敏捷都是为了应对不断变化的需求和技术限制。要做到这一点，人们必须相互交谈，而不仅仅是遵循任务分配和书面文件，冷冰冰地在像JIRA这样的工具上飞来飞去。不要浪费太多的时间写详细的需求和技术文档。直到你开始实际的设计和编码，并遇到实际的问题之前很难想到所有的细节和场景， 只有在它被测试并证明有效后，才能完完全全的记录它。最重要的是，记住这一点：机器和方法是不能构建软件的。人类才可以。
