规模化敏捷发展三部曲：敏捷领导力、运转敏捷和整体敏捷

从软件研发部门开始推行敏捷，该部门客户导向程度高，可以测试并优化敏捷方法。领导团队组建了咨询小组，负责培训、指导、嵌入新工作方法，并使用结果追踪工具，让大家清晰地看到成果。“用实实在在的例子向大家展现出敏捷法带来的生产率提升，这增强了组织内部对敏捷的兴趣。”当时咨询小组负责人塞巴斯蒂安·瓦格纳（Sebastian Wagner）说。接下来的两年间，公司在超过80%的研发团队中推广了敏捷法，创造出2000多个团队。销售和营销部门的员工为了能跟上步伐，相继敏捷化。一旦公司的前端部门快速转型，后端要马上跟上，因此SAP内部的IT系统也采用了敏捷方法。

 

然而很多企业想走捷径，却适得其反。面对系统化障碍，它们选择绕道而行，将团队交给外部孵化器。“温室培育”的方法也许会提高单个团队成功率，但无法在机构中创造学习环境，也不能带来变革，这些都是敏捷规模化必不可少的。公司第一批敏捷化的团队肩负着最终能否成功的重担。企业要像测试原型那样，在多样化的现实条件下测试这些团队。SAP等在这方面最成功的企业，都很重视关键客户体验，即孤岛部门最难解决的棘手问题。

 

无论如何，敏捷团队都应该准备充足再进行实践。充足并不代表计划详尽、胜券在握，而是这些团队：

 

聚焦于一个利益攸关的重大商业机遇

对具体结果负责

可以独立自主地工作——拥有清晰的决策权、合适的资源，团队成员为跨学科专家，人数虽不多，但都对这个机遇充满热情

承诺使用敏捷价值观、原则和实践

有权和顾客紧密合作

能够快速设计出原型，拥有快速反馈回路

拥有高管的支持，能够为其扫清障碍，并推广团队工作成果

 

按照这个列表自检，可以帮助你安排出对顾客和机构都拥有最大影响力的测试顺序。

 

完成大规模敏捷项目。许多高管难以想象小的敏捷团队可以完成大规模的长期项目。但原则上讲，敏捷团队的数量和项目规模并无上限。你可以在相关项目中，分离出“组中组”，这种方式扩展性很强。

 

举例来说，瑞典公司萨博（Saab）的航空业务部拥有100多个敏捷团队，负责软件、硬件，以及价值4300万美元、堪称全球最复杂产品之一的“鹰狮”（Gripen）战斗机机身的制造。该项目通过每日组中组的站会（stand-ups）协调工作。每天早上7：30，一线敏捷团队进行15分钟站会，列明工作中遇到的障碍，其中一些无法在组内解决。7:45，该小组将需要其他部门配合的障碍上报给另一个组中组。领导们可以选择解决该问题，或继续上报。接着不断重复这一方式，直到8:45，主管行动组拿到一份关键问题清单，想保持工作进度必须解决清单上的问题。航空业务部门协调团队的方式是：采用通用的为期3周的“冲刺”（sprints，创造迭代产品的一个周期——译者注）；制定项目总计划（一份动态文件）；让过去分散各处的部门同地办公。例如，让试飞员和模拟器组加入研发团队。这样做的结果相当显著：简氏信息集团（IHS Jane's）将鹰狮战斗机认证为全球成本效益最好的军用飞机。

 

在建立敏捷团队之后，协调其与传统架构部门之间的合作同样重要。下面将从四个领域进行阐释。

 

增加敏捷团队的数量是提高业务整体敏捷度的重要步骤。但这些团队和机构其余部门之间的互动也同样重要。即便最先进的敏捷企业，例如亚马逊、Spotify、谷歌、Netflix、博世、萨博、SAP、Salesforce、拳头公司（RiotGames）、特斯拉以及SpaceX等，都是既有敏捷团队，也有传统构架部门。为了确保官僚部门不给敏捷团队的工作造成障碍，不妨碍敏捷团队的创新成果商业化，这些企业一直在以下四个领域不断推进更深入的变革。

 

1价值观和原则

 

如果敏捷团队的数量不多，可以“寄居”在传统层级结构之中。部门间的冲突可以通过个人交流或变通的方法解决。但当公司推出数百个敏捷团队时，寄居就行不通了。敏捷团队在各方面以势不可挡的速度推进工作，而传统部门则誓死捍卫现状。面对任何变革，怀疑论者都能制造出攻击敏捷的抗体，包括拒绝配合敏捷团队时间表（“抱歉，我们没法按你说的6个月就完成这个软件模块”），或者在需要新式解决方案的大机遇面前，拒不拨款。

 

因此，领导团队如果希望规模化敏捷