2001年，在Snowbird滑雪胜地碰到了一群分享关于如何管理软件开发的简单理论的技术人员和程序员，以书面形式提出了其中一些概念。 这就是“
敏捷宣言”的诞生方式-这份看似简单的文档旨在重新定义软件开发的教条。 敏捷风格的软件开发已发展成为组织组织中的程序员工作的新标准。
Facebook ，
Amazon ，
Apple ，
Google和
Netflix等公司已按照本宣言的基本规定建立了内部开发流程。 考虑到敏捷的巨大规模及其在支持者之间的公众共鸣，很容易看出，敏捷是所有形式化软件开发解释中最具影响力的。 但是，敏捷是一种意识形态。 价值观和信念的规范体系，几乎可以吸收到软件开发业务中。 因此，当今的软件行业提供了一个有趣的机会，可以评估某种意识形态的名义目标如何与其在实践中的实施相一致。
从本质上讲，敏捷是对公司在软件开发领域的主导地位的骚动。 第一次，人们认识到软件开发是一个复杂且通常是神秘的过程，必须加以保护以防止公司官僚化。 变更，重塑，灵活性，活力-这些是贯穿敏捷清单的红色线程。 它们被证明具有无限吸引力：根据
一项全球研究 ，约有97％的所有组织以一种或另一种形式实践敏捷原则。 由于这种广泛的分布，敏捷在软件开发管理的理论上已实现了完全的标准化：如今，“敏捷”一词指的是意识形态，工作方法，甚至是用于在现代组织中开发软件的系统。 敏捷甚至超出了程序员团队的范围，并且在负责财务或人力资源管理的其他团队中越来越多地实践。 尽管
缺乏经验证据证明敏捷
性的有效性和实用性，但敏捷却被解释为一种普遍的管理理论，已被证明是极为容易获得和普及的。
有趣的是，敏捷清单没有试图阐明任何有助于开发敏捷风格软件的特定工作方法，规则，过程，系统或结构。 这不足为奇：毕竟，敏捷宣言从未声称对如何实现此宣言的目标进行了详细描述。 这种明显的模糊并没有削弱敏捷的流行：实际上，对特定敏捷方法和工具的需求的快速增长导致了基于敏捷资源的元产业的出现。 这种兴趣刺激了敏捷的引入，使敏捷及其衍生思想进入了新的行业。 事实证明，最明确定义的敏捷方法论（例如Scrum和看板-即对实现敏捷清单原则必须遵循的过程的详细描述）和专门设计用于支持敏捷开发的专用软件平台最为不同。 澳大利亚技术公司Atlassian销售一系列旨在支持敏捷风格软件开发流程的产品； 特别值得注意的是Confluence和Jira，它们实际上已成为行业标准。 对于那些没有在技术界煮熟的人来说，这类产品似乎很神秘。 此后，在Atlassian进入纳斯达克名单之前，出现了许多说明性文章。 文章旨在解释Atlassian的确切销售内容，以及该公司为何实现如此高的市值。
像Atlassian软件产品一样，描述敏捷过程和日常工作方法的词汇也变得越来越难以理解。 敏捷从业者谈论冲刺，看板，任务图，速度，用户故事，史诗和回顾-这些词的含义经常根据上下文而变化，这些术语本身可以与一种或多种定义明确的敏捷方法论联系起来。 难怪随着敏捷方法论变得越来越复杂，越来越多的专业顾问可以帮助您理解所有这一切。 贝恩公司拥有约1,000名敏捷从业人员。 这也许是最可靠的指标，它表明了敏捷咨询行业的盈利能力。 但是，如果敏捷清单如此简单，乍一看，那么为什么会有那么多顾问？ 这些服务中的任何一项如何切实影响典型技术公司的工作质量和效率？
尽管有词汇，专门的工具和大量资源可供想要在公司中进行敏捷风格软件开发的任何人使用，但通常很难跟踪实践中实现敏捷的准确程度，也就是说，它与清单中作者所记录的精神和文字相吻合。敏捷的 敏捷宣言被故意和不可避免地抽象化了。 也许这导致了敏捷方法论的逐渐扭曲，结果导致了整个软件行业的整个管理文化。 巨大的东西是建立在看似简单的基础之上的，这种机制使那些为第一次迭代奠定基础的人感到非常失望。 此外，由于敏捷的长期流行，没有正式的敏捷资格的专家开始失去竞争，而这些竞争者据说是精通敏捷的。 那些声称了解Agilr设备并知道如何使用它的人，有许多职业奖金等待着他们。 这样的现实刺激了顺从性，并淹没了对敏捷的主导地位提出质疑或对其有效性提出质疑的任何尝试。
敏捷宣言的创始作者之一安迪·亨特（Andy Hunt）
抱怨说，由于原始宣言的抽象表述，无休止的规则已经出现和传播，这些规则在上下文之外使用，并据认为构成了敏捷风格发展的基础。 随着时间的流逝，这些规则以专门的方法学的形式被编纂，而这些方法学则被遗忘了，而忘记了宣言的原始指南。 换句话说，敏捷思想已被证明非常难以学习，学习和实践。 因此，某些角色依赖于他们以敏捷给出的严格定义的规则或试探法，然后继续用符合宣言目标的敏捷实践代替这些规则（通常从上下文中删除）。 在大多数组织中，开发过程不会逐步完善。 相反，管理人员误入歧途，认为该过程不允许更改，拒绝逐步改进产品，并努力从开发人员身上剥下三层皮，主要是从天花板上取下并牢固固定的佳能进行操作。 无法从Agile中获得任何真正利益的组织（其中有许多组织）自然会倾向于监视某个Agile流程的执行情况，而忽略了流程中更模糊，但更重要的结果-即，可用软件的交付。
Scrum和看板的鼎盛时期充其量不过是试图形式化和传播敏捷意识形态。 在最坏的情况下，所有这些方法只不过是一种额外的官僚机构，产生了开发人员必须遵循的新的不合理规则和度量。 所有这些都是出于通常无法完全凭经验支持的原因而实施的。 在这种情况下，平庸的经理，顾问，开发人员，甚至整个组织都蓬勃发展：专注于名义上的意识形态规则变得更加容易，而且逐渐证明，这比实现实际目标更为重要。 基本上，在软件开发行业中，在单个员工级别上衡量敏捷的“贡献”和“回报”存在
狂热 。 这样的狂热导致对原始敏捷道德的忽视，转移了为每位员工收集统计数据的优先顺序，而实际上有必要逐步改善整个组织层面的流程。
这种退化的最大讽刺意味在于，最初的敏捷哲学旨在将普通程序员从微观管理和不必要的官僚监督的专横中解脱出来。 相反，这种意识形态的当前形式的本质已经对于创造它的人来说已经难以辨认。 更笼统地说，作为软件方法论的命运是一个苦涩的例子，说明随着其影响力的增长，简单抽象的意识形态是如何逐渐变形和扭曲的，并且进行了越来越多的尝试以将其付诸实践。