根据2018年PMI的发布的行业脉搏所述：只有47% 的项目采用传统方式，一半多项目用到了Agile。其中有半数采用纯粹的敏捷（大多数采用Scrum），另一半采用混合式敏捷。
大多数组织将敏捷性视为保持竞争力的基础 (71%)，这意味着你已经在Scrum的学习上做出了伟大的投资。接下来，让我们着眼于找出项目失败的主要原因，根据PMI的文章，以下是项目失败的主要原因:
- 改变组织工作事项的优先级
- 改变项目目标内容
- 收集的需求不准确
以下原因并列第四： - 愿景或目标不足
- 缺乏沟通
- 没有清晰定义机会和风险
当回顾这些方面时，它们与敏捷宣言中的哪些方面一致?事实上，敏捷直接解决了当前项目面临的主要挑战：目标、需求和沟通。了解到敏捷也在持续进化，在Verizon One的敏捷状态报告中看到，大多数项目都使用Scrum:
- 56% 使用"纯" Scrum
- 75% 使用 Scrum, Scrumban, Scum/XP, or Kanban
这是因为Scrum简单、有效，对于小型团队来说非常适用。但是正如我们所回顾的，在Scrum模型中没有提到的“组织”。那么对于大公司呢？这些使用Scrum的组织如何扩展他们的敏捷方法？
根据Verizon One的调查，目前有四种主要的规模化敏捷框架：
- SAFe - 29%
- Scrum of Scrums - 19%
- 内部建立的方法 - 10%
- Disciplined Agile Delivery (DAD) - 5%
- Large Scale Scrum (LeSS) - 5%
以上占了规模化敏捷方法的70%。我们经常看到内部创建的方法看起来像混合方法。在下一节中，我们将进行探索 SAFe, DAD, and LeSS。每一个都有以下共同点：
- 都使用Scrum作为管理团队的基本模型
- 都包含角色（Product Owner, Scrum Master, 和研发团队）
- 在如何管理 "Support Teams" 以及如何使整个组织更加敏捷方面各有不同。
理解规模化敏捷的最简单方法是看看最初用于衡量规模化敏捷的两种方法:
- Scrum of Scrums - 团队通过派遣代表在团队之间进行日常站会来协调工作
- Hybrid Methodology - 团队之间通过使用传统的控制来协调，例如根据实现定义的不同阶段的工作来管理交付
Scrum of Scrums:
- SoS站会：团队会派出一名代表参加，通常是PO或Scrum Master
- 可以跟标准的日常站会时长一样迭代进行
- 着重报告已完成的Task以及遇到的障碍
- 也是识别团队成员之间需要做哪些协调的机会
- SoS 也有Scrum Master
- 通常是组织内的高级别人员
- 负责协调工作
- 负责所有Scrum团队的整体生产力
- SoS适用于两个团队有潜在依赖关系的情况
- 存在共享资源 (人力, 服务等.)
- 共同研发同一产品
- 共同的目标或愿景
- 最早由Jeff Sutherland提出的，他是Scrum创始人之一，同时也是敏捷宣言的签署者之一。
- “Agile Can Scale: Inventing and reinventing SCRUM in Five Companies”
- 有些团队变得“超级高效”，这是Scrum团队的一种状态，Jeff Sutherland称，这种状态的团队效率要高出4到5倍
Scrum of Scrums提供了一种非常简单而优雅的Scrum扩展方法。事实上，许多大型组织都使用了这种实践来实现组织敏捷性。
在《哈佛商业评论》的文章《敏捷在大规模组织中的应用》(2018)中，有一些Scrum的例子：
- 萨博航空的鹰狮战斗机项目，拥有100多个敏捷团队(价值4300万美元的项目)
- 每日站会从7:30 AM 到 8:45 AM，时长45分钟
- 在SoS站会结束后，执行团队知道需要解决问题的关键
- 在不到1小时的时间里，有超过500人通过口述进行完整的汇报
在许多敏捷实践者中，这种模式正在复苏。特别是许多组织正在扩展他们对敏捷的理解，并使用混合式或SAFe的方法转型成为敏捷的组织。
组织最常使用的混合式敏捷相当简单：
- 传统的方法被用来控制主要的决策
- 阶段关卡特别用于需求、设计和操作(部署)
- 这为传统型领导批准项目的下一个“阶段”提供了机会
- 敏捷(Scrum)方法用于在每个阶段快速、迭代地开发产品
- 全部团队进行开发需求、设计、开发和验证
- 全部团队能够创建原型并创建可重用的文档
- 需求用用户故事来管理
- 故事在需求中产生，在设计中提炼，在开发中实现和关闭
- 为了提高速度和缩减学习周期，开发通常仍然是迭代的和增量的
- 在达到“阶段”或“试用”过程中，开发可能会发布多个版本
- 针对用户故事，根据进行系统级的需求进行验证
这看起来就像阶段关卡之间的迭代，而且在抵制敏捷的组织中往往更成功。因为组织对敏捷的抵制和对敏捷的误解是敏捷失败的主要原因， 这对于许多第一次学习敏捷的新手来说是言之有理的。
当我们看到敏捷失败的主要原因时，我们还会看到以下几点：
- 组织文化与敏捷价值观不一致 - 53%
- 组织抗拒改变 - 46%
- 管理层面支持不足 - 42%
- 缺乏敏捷方法的技能/经验 - 41%
这些统计数据显示了为什么混合式敏捷在传统敏捷实践者中如此流行。由于这些原因，“内部敏捷”是一种在没有高层管理支持的情况下证明方法有效性的好方法。然而，真正实现敏捷的唯一方法是获得领导的支持和良好的敏捷培训。
那么，我们如何说服那些不相信敏捷的领导者呢?给他们看数据：
- 采用敏捷的原因
- 加速软件交付 - 75%
- 管理优先级变更 - 64%
- 提高工作效率 - 55%
- 更好的统一协调业务和IT- 49%
- 提高软件质量 - 46%
- 采用敏捷的益处
- 更好地管理优先事项 - 71%
- 项目可见性/透明性 - 66%
- 业务和IT的一致性 - 65%
- 加速交付和产品上市时间 - 62%
- 团队生产力 - 61%
在影响方面，效益可能是生产力和价值产出的四到五倍。
参考资料:
The pulse of the Profession 2018, Project Management Institute:
12th Annual State of Agile Report, Verizon One
Agile At Scale, DarrellK Rigby, Jeff Sutherland, and Andy Noble, Harvard Business Review:
Scrum of Scrums, Agile Alliance
Agile Can Scale: Inventing and Reinventing Scrum in Five Companies, Jeff Sutherland, Cutter IT Journal:
