理解“假敏捷”｜Understanding Fake Agile

​ 

审校：申导，Scrum Alliance认证CTC敏捷教练

目录

1	定义敏捷Agile Defined
2	没有标签的敏捷Agile Without The Label
3	早期阶段的敏捷Early-Stage Agile
4	挂羊头卖狗肉的敏捷Agile In Name Only
5	仅用于软件部门的敏捷Agile For Software Only
6	停滞的敏捷Stalled Agile Journeys
7	品牌化敏捷Branded Agile
8	（假）规模化敏捷框架：SAFe/（Fake)Scaling Frameworks: SAFe
9	轻敏捷Agile Lite

最近，一家大型企业邀请我做一个以“假敏捷”为主题的演讲。他们期望我解释什么是“假敏捷”，如何识别以及如何处理它。这个需求引发了我的思考：“假敏捷” 就像一个怪兽的许多化身，它出现的真正原因是什么？我们有可能驯服它、包容它或者把它转变成“真敏捷”么？

这个需求很容易理解。一些所谓的敏捷管理与“真敏捷”的差距，就如同穿着弗拉明戈服装对其侃侃而谈的人，却无法感知弗拉明戈乐曲的真谛也跳不出弗拉明戈灵动的舞步。

越来越多的人感受到“敏捷正在吞噬世界”，正如德勤和麦肯锡的调查显示，超过 90% 的高管将敏捷转型列为重要的优先事项，然而只有不到 10% 的高管认为他们的公司目前已经高度敏捷。理想与现实之间的差距使得大量经理、顾问和教练声称自己是敏捷的，并愿意帮助公司变得敏捷。很多公司的 CEO 会问：“我们为什么不敏捷？”

这股热潮带来的是“敏捷”经常被滥用。那些对敏捷没有任何实质性要求的公司或团队尤其热衷于此。以至于真正敏捷的公司反而不愿意将自己贴上“敏捷”的标签，反而用自己内部更加真实的语言描述自己。

1、定义敏捷 Agile Defined

为了理清这些困惑，我们需要定义“真敏捷”。如之前文章阐述的, 我过往去十年的研究表明，获益于敏捷的公司具备敏捷思维，由三个要素组成。

为了强调三要素的重要性，我诙谐地称之为敏捷“定律”。之所以称为“定律”，意味着除非你遵守所有的这些“定律”，否则你的组织就不能称为敏捷。这里我讨论的是整个公司的敏捷性或业务敏捷，因为经验表明，只有当整个公司执行同一个标准的时候，我们才能看到敏捷的成果。

敏捷三定律如下：

• 客户定律——执着于将为客户创造价值作为组织全部和最终目的。
• 小团队定律——假设所有的工作应都由小型自组织团队在短周期内完成并专注于为客户创造价值。
• 网络定律——不断努力努消除官僚主义和自上而下的层级制度，让公司作为一个互动的团队网络运行，专注于合作和为客户创造更多的价值。

这项敏捷定义标准适用于运营敏捷性（operational agility,更好地运行现有业务）和战略敏捷性（strategic agility,创造新产品和服务以引入新客户），并且独立于术语、标签、特定专属流程或特定品牌。

2、没有标签的敏捷 Agile Without The Label

“没有标签的敏捷”是致敬那些使用自身内部术语的最成功的敏捷践行者。换句话说，这些公司甚至不称自己为敏捷并且回避使用敏捷用语，有些敏捷用语，比如Scrum，本身就设计得不那么易于管理使用。因此，世界上大多数规模最大发展最快的公司比如亚马逊、苹果、脸书、谷歌、奈飞和微软——他们所做的大部分工作中都是公认的敏捷，尽管他们通常不使用标准敏捷语言。业务敏捷是他们成为世界上最有价值的公司的重要原因。

3、早期阶段的敏捷 Early-Stage Agile

敏捷是一段旅程。没有一个大公司可以在第一天就实施所有的敏捷要素。掌握敏捷的方方面面需要时间。当公司刚刚开始启动敏捷的时候，可以称之为“早期阶段的敏捷”。这不是假敏捷，而是未完成的敏捷。如果一切进展顺利，这个公司会逐步实现所有的敏捷三定律并实现战略敏捷性。敏捷之程是永无止境的——公司总会不断地发现新的方法以变得更加敏捷。

各家公司的敏捷之旅的顺序可能各不相同。例如，十年前，微软从建立小型敏捷团队开始他的敏捷之旅， 并在2008至2014年间进行持续性地试验，逐步扩大规模。直到萨提亚·纳德拉担任微软CEO，微软开始全面实施敏捷时，微软才可以被认为是开始实现了业务敏捷。2014年之前，我们可以称微软为“早期阶段的敏捷”。

与微软相反，亚马逊从1997年上市伊始，就痴迷于客户，明确承诺将为客户创造价值和实现市场主导地位列为首项要务。仅用了五年时间，大约在2002年亚马逊就启用了“双披萨团队”（two-pizza teams），并开始思考搭建团队网络而不是建立自上而下的层级组织结构。在那之前，我们可以称亚马逊为“早期阶段的敏捷”，尽管他启动敏捷旅程的早期步骤与微软并不相同。

4、挂羊头卖狗肉的敏捷 Agile In Name Only

并非所有的人口中的“敏捷”都符合我定义的标准，有些人用“敏捷’指代任何自称为敏捷的公司。这导致很多被称为“敏捷”的公司在管理上和传统的官僚机构没有任何区别。而且，它还将一些成功实施了敏捷却不使用敏捷标准术语的公司排除在外。这种做法使得很多公司只是“挂羊头卖狗肉的敏捷”或是我有时说的“假敏捷”。换句话说，要了解一个公司是不是敏捷，我们需要看看公司如何运做的而不是他们怎么说。

“挂羊头卖狗肉的敏捷”有时也适用于那些只实施了“敏捷流程和仪式”，但是却缺乏敏捷思维的公司。他们在执行（doing)敏捷但并没有真正成为(being)敏捷。例如，2016年前的沃尔玛，他们有很多敏捷团队但是并没有什么成效，这些团队执行敏捷流程但是管理者却心不在焉，缺乏敏捷思维。

直到2016年，沃尔玛并购了Jet.com并聘请了马克·劳尔，公司才开始“以初创企业的速度发展”，并且开始从中获益。一年之内，沃尔玛大规模扩展在线产品，客户无需支付亚马逊Prime会员费也可以享受免费的2日快递送达服务，并将店铺部署为订单履行中心。很快，便收获了更好的财务业绩。

5、仅用于软件部门的敏捷 Agile For Software Only

对于许多敏捷主义者而言，2001年发布的敏捷软件开发宣言是敏捷运动的北极星。它包含4项敏捷价值观和12项敏捷原则，成千上万的抱着“身体力行帮助他人做来发现更好的软件开发方法”初衷的软件开发者将其奉为行为准则。

敏捷宣言通常是那些寻求在软件开发领域外传播敏捷理念的人的起点，通常从敏捷宣言开始，因此，它也是业务敏捷的重要参考。2011年10位最初敏捷宣言的签署人聚集一堂，他们表示无意改变敏捷宣言的任何一个字或将其推广到软件开发外的领域。敏捷宣言具有标志性历史文件的地位，类似于大宪章或独立宣言。虽然历史性文件未必能为当今课题做出最终答案，但是他们却是后来者永恒的灯塔。

事实上敏捷宣言中的措辞只是局限于软件开发，使得其不足以定义业务敏捷（business agility）。平心而论，起草者并没有考虑过业务敏捷。他们更关注的是让软件开发人员的世界变得安全。

但是将敏捷限制在软件开发是有问题的。当敏捷思维在传统组织中接管软件开发时，它不可避免地开始与组织中其他速度较慢、灵活性较低的部门产生冲突。

6、停滞的敏捷 Stalled Agile Journeys

我们看到很多案例，敏捷让开发团队日益活跃，但最终却未能赢得最高管理层的支持。最初，软件开发部门以敏捷方式运行，而组织的其他部门扔按照僵化的、节奏更慢的传统官僚方式运行，这并不是什么大问题。管理层很高兴看到开发部门产出得更快。

但是当敏捷运动的蔓延开，这两种不同业务运行模式带来的张力变成了矛盾之源。软件开发人员不甘受制于其他部门的节奏，于是开始游说他们变革。

从某种角度来看，当软件开发人员挑战现有完善的管理实践时，这种游说很可能会惹恼最高管理层。于是，管理层可能终止敏捷实施并且解雇敏捷领导者和教练。当然，高级管理层不会用这些说辞，他们会宣告胜利：“我们已经非常敏捷了，我们不再需要敏捷领导者或者教练。”敏捷之旅就这样停滞不前，或就此失败，或者至少转入地下模式。

但是，促使公司追求敏捷的市场困境仍然存在。没有敏捷，公司无法充分发展或适应软件高速发展的软件开发——而这正是世界快速走向数字化世界的关键障碍。于是，我们经常看到，过了几年后，这家公司又开始新一轮的“敏捷转型运动”。

并不是说“仅适用于软件开发的敏捷”是假敏捷。只是当敏捷管理仅限于软件开发，它就注定了这个结局。敏捷团队与组织中其他部门的冲突不可避免。敏捷和官僚主义无法相容，到了中期，只有一个可以存活。

7、品牌化敏捷 Branded Agile

“品牌化敏捷”是指被顾问和培训师们宣传的数百种敏捷品牌，这些只是对相同的敏捷基本思想的不同变体。出于让自身区别于其他顾问和培训师的商业目的，他们坚持用某种特别的术语或者专用的流程名称。这导致了大量的混乱，如下图所示：

其中有些敏捷品牌变体可能是“真敏捷”。大部分则是着重于敏捷第二定律——小团队定律， 因为这是最容易进行培训的。他们很容易忽略第一定律和第三定律——客户定律和网络定律。

这并不是说小团队定律不重要。它至关重要，但是仅有小团队定律是不够的。如果公司不继续实施另外两条定律，敏捷成果要么会逐渐消失，要么会被官僚主义吞噬。

另一个问题则是强调某一种特定的敏捷变体为“答案”或坚持使用特定的品牌标签、流程和术语，往往会分散人们对敏捷本质的关注。敏捷本质上是一种新的组织运营管理方式，而不仅仅是特定咨询公司的产品。

人们可以感受一下10年前Luke Halliwell的怒吼。

我也很烦这个。我迫不及待地希望有一天，人们可以意识到所谓流行的，受宗教崇拜启发的、赚钱的活动都是为了养活那些咨询顾问而已。我迫不及待地希望人们意识到敏捷唯一有价值的就基本常识，不需要所谓的“宣言”或者传道人来支持。

各种各样的“品牌化敏捷”只是把敏捷弄得混淆不清并且让人觉得敏捷本身就是令人困惑的。总而言之，“品牌化敏捷”，有些是“真敏捷”，有些是“假敏捷”。需要注意的是要警惕那些顾问和培训师坚持他们包装过的敏捷品牌是唯一正确的路。

8、（假）规模化敏捷框架:SAFe/  (Fake)Scaling Frameworks: SAFe

一种特别不幸的“品牌化敏捷”就是规模化框架。这些框架旨在帮助那些已经拥有一些团队敏捷实践的公司化解敏捷团队和后台组织系统（例如战略、计划、预算、人力资源、财务）之间的紧张关系。这些后台系统通常是庞大而官僚的。

这种挑战通常表现为某种“扩展敏捷”。问题是当组织开始思考“扩展敏捷”就已经错了。“真敏捷”的挑战是如何将单一的、关注内部的系统缩减为可以由自组织的、以客户为中心的小型团队运行的任务。

特别令人担忧的变体是规模化敏捷或者叫SAFe。本质上就是在编撰官僚主义，客户在其中几乎完全缺位。这在大公司里面很普遍，因为它授予了管理层称自己为敏捷却继续像以前一样工作的权力。从根本上来说，它让敏捷团队服从于官僚主义，却不做实现业务敏捷必须要做的事， 即将庞大的以自我为中心的系统，例如预算、人事、财务等转变为灵活的和关注外部的设计，以此来支持敏捷团队。客户在上图中微不足道的角色正表明了这个问题。

同时SAfe正带来诋毁敏捷的风险。这就是格雷欣定律的例证：劣币驱逐良币。当这种情况发生，SAFe就成了”假敏捷“的缩影。然而，当SAFe由拥有真敏捷思维的管理者实施时，负面影响能被消除。但我的问题是：为什么一个拥有真敏捷思维的人会把SAFe作为首选？。

9、轻敏捷 Agile Lite

另一个令人担忧的敏捷形式是所谓的“轻敏捷”。这是哈佛商业评论去年的一篇文章种提及的。在这篇文章阐释了人力资源服务如何探索敏捷的方法。这篇文章的标题是“人力资源走向敏捷”。但是文中建议人力资源做“轻敏捷”。文中提到“人力资源正在运用敏捷的一般原则，但是不采用任何技术领域的敏捷工具和约定。” 从文中举的例子可以看出，“轻敏捷”是指采用一些敏捷工具和实践，却未必带着缺乏敏捷思维去实施。诚然，敏捷思维缺位，敏捷就只能是无效的、没有生命力的一系列繁文缛节。

点击链接阅读英文原文：Understanding Fake Agile

https://www.forbes.com/sites/stevedenning/2019/05/23/understanding-fake-agile/?sh=7280f7394bbe