在敏捷框架如Scrum或Kanban成为焦点的今天，有多少人在开始他们的首个敏捷项目之前，真正参考过敏捷宣言？本文将从更广泛的角度探讨敏捷的本质，以及为什么敏捷可能会失败。
回归基础，敏捷的核心是交付客户价值，并将客户满意度放在首位。它基于12条原则，这些原则支持敏捷宣言。
像Scrum和Kanban这样的框架是基于敏捷原则的交付模型的例子，它们实现了上述列出的大部分原则。这有助于团队对变化做出反应，通过优先级排序，进行自改进，为团队提供工作，以及促进面对面沟通。
这些交付模型不会做的是驱动如何为敏捷架构，或者应该如何构建组织以促进敏捷。这取决于。
忽略敏捷的这些部分，称之为“水平敏捷”。这是因为组织可能仍然是水平划分为部门和孤岛。这使得实现敏捷的一些原则变得更加困难，也是敏捷可能失败的原因。
在某些情况下，成为水平敏捷可能是与其他选择相比的最佳妥协。它将解决一些交付和规划问题，但它将限制敏捷性，因此限制竞争力。
关键是，仅凭敏捷交付框架或流程本身，并不能让完全实现敏捷的12条原则。
要完全实施敏捷，除了采用的交付模型之外，还有一些缺失的部分。它可能需要组织的转型。对于初创公司来说，它需要从一开始就构建支持敏捷的组织结构。
让回顾一下敏捷原则，并探索其中的一些。
通过敏捷交付模型，当然可以塑造需求如何进入团队，以及如何以小块迭代的方式开发具有价值的产品。但是，如何可靠和频繁地将这个价值交付给客户？
如果答案是一个单独的运营团队，他们管理整个组织的基础设施和发布流程，那么这就是对团队的限制。它也可能导致交接问题，并且它剥夺了原本以业务为中心的团队的控制权。
最高优先级是通过早期和持续交付有价值的软件来满足客户。发布频率对能力了解客户需求有多大影响？只能发布运营团队能够支持的频率，而项目可能不是他们唯一的焦点。一个运营部门限制了技术选择和支持它的工具。它将开发团队限制在一个框框里。
这让想到了：
最好的架构、需求和设计来自于自组织的团队。如果团队不能选择他们的架构和工具，那么产品的最佳架构就受到限制，并且不能随着需求的变化而轻松演变。
无论称运营团队为DevOps，还是将部门运营人员放在团队中并称之为DevOps，都不要这样做。DevOps是一种补充敏捷的文化，它有助于解决这些特定问题。它要求完全消除孤岛，以便运营和开发可以无缝地作为一个整体工作。
围绕有动力的个体构建项目。为他们提供所需的环境和支持，并相信他们能够完成任务。如果另一个部门根据组织的需求做出架构决策，或者与业务过于脱节，那么关键的敏捷性就会丧失。
一个敏捷团队应该拥有支持产品需求所需的所有技能。他们应该能够并且能够将可工作的软件交付到生产中，频率尽可能高。它促进了一种简单的精益方法，也补充了敏捷。它还保持了技术解决方案尽可能简单，以满足特定的业务目的。
简单性——最大化未完成工作量的艺术——是必不可少的。通过部门孤岛，沟通开销增加，面对面沟通更具挑战性。
向开发团队传达信息以及团队内部沟通的最有效和高效的方法，是面对面的交流。治理流程也是如此，如外部技术审查委员会，它们控制着控制权，或者服务于组织需求的架构团队。相反，构建支持产品的单个团队的能力，并保持它们的自主性。
伟大的领导者知道何时退后一步。”——Tara Jaye Frank
一个组织越支持跨业务的水平协作，它就越会稀释需要的协作，并限制对变化的反应能力。许多公司这样做是因为他们缺乏对这些传统结构之外的信任，很难摆脱这种心态。
实现所有敏捷原则的好处是，无论是对业务还是对团队，都具有高度的敏捷性。它允许快速对变化做出反应，并促进竞争优势。
如果一个组织在没有必要的组织支持的情况下尝试敏捷方法，那么它就是“水平敏捷”，并且不能实现敏捷的全部12条原则。在这种情况下，团队或部门议程的限制将限制敏捷团队。在最坏的情况下，它将导致失败。
强有力的领导是退后一步，信任、培养和授权他人朝着共同的愿景前进。放弃对组织的控制和治理是一个勇敢的步骤，但可以在小规模上尝试和测试。