假敏捷Fake Agile
假敏捷 Fake Agile
作者：Steve Denning (from Forbes) 译者：乔梁 （微信公众号：持续交付2.0）
我现在的微信签名是“别提概念，只解决问题”。而在2013年之前，我用的签名是“别提敏捷，只解决问题”。 为什么呢？因为在2012年的腾讯，敏捷开发方法似乎早已成为“过去时”。但是，还有一大堆问题要解决呀。
（上图与腾讯无关，来自我朋友圈的@王宇）
今天的文章是Martin Folwer在“推它”上一个引用，原文发表于福布斯网站，作者是Steve Denning。点击文末的”原文链接“，看英文版。 正文如下：
有个公司请我去讲讲“假敏捷（fake agile）”。他们想讲我解释一下，如何识别假敏捷，以及如何处理这种情况。这个要求是可以理解的。 就像穿着弗拉门戈服装和谈论弗拉门戈的人一样，没有掌握弗拉门戈舞步或展示弗拉门戈音乐的感觉或天赋，一些所谓敏捷管理的例子的确与真正的敏捷是相关的，但又似是而非。
随着人们越来越认识到“敏捷正在吞噬世界”。德勤和麦肯锡的调查显示，超过90％的高级管理人员高度重视敏捷，而不到10％的人认为他们的公司目前非常敏捷。 愿望与现实之间的差距导致大量的经理，顾问和教练声称自己敏捷并提供帮助公司变得敏捷。 不少公司也有首席执行官问：“我们为什么不敏捷？”
因此，“敏捷”一词经常被抛出，而并未对其含义达成任何共识。 它通常适用于对任何敏捷性没有实质性要求的公司或公司的一部分。 在某种程度上，事实上，实际上非常敏捷的公司往往回避标签，“敏捷”，并使用他们自己的本土词汇，感觉更真实。
1、定义“敏捷”
为了解决困惑，我们需要对真实事物进行定义。 正如这里所解释的，我对过去十年的研究表明，敏捷的主要成果是体现了具有三个主要组成部分的思维模式的公司。
为了强调所有这三个组成部分的重要性，我只是半开玩笑地称它们为“法律”。也就是说，除非你遵守所有这些“法律”，否则你无法真正称你的组织是“敏捷的” 。 我在这里谈论的是整个公司的敏捷性或业务敏捷性。因为，经验表明，只有整个公司使用相同的步调运行时，才会产生敏捷的主要成果。
2、敏捷三定律
- 客户法则 - 专注于为客户提供价值，作为组织的全部和最终目标。
- 小团队法则 - 假设所有工作都由小型自组织团队进行，工作周期短，专注于为客户提供价值
- 网络法则 - 持续努力消除官僚主义和自上而下的等级制度，使公司作为一个互动的团队网络来运作，所有这些都集中在共同努力，为客户提供越来越多的价值。
该定义包括运营敏捷性（operational agility，使现有业务更好）和战略敏捷性（strategic agility ，生成新产品和服务，从而引入新客户）。 该定义独立于那些术语、标签，或者是特定的专有流程或特定品牌。
3、没有标签的敏捷
该定义认识到，一些最成功的敏捷最终都在企业内部实现了本土术语。 换句话说，这些公司甚至没有称自己敏捷并且回避标准的敏捷词汇，其中一些（如Scrum）被故意设计为对管理层没有吸引力。
亚马逊，苹果，Facebook，谷歌，Netflix和微软等大多数规模最大，发展最快的公司在其所做的大部分工作中都具有敏捷性，即使他们通常不使用标准的敏捷词汇。 他们的业务敏捷性是他们成为世界上最有价值公司的重要原因。
3、敏捷的初级阶段
敏捷是一段旅程。 没有哪个公司能够在第一天实施敏捷的所有元素。 掌握敏捷的各个方面需要时间。 当一家公司处于敏捷旅程的初期阶段时，人们可能会称之为“早期敏捷”。这不是假的敏捷，而是“它是不完整的”。 如果旅程顺利进行，那么公司将逐步掌握所有三项敏捷法则以及战略敏捷性。 旅程永无止境：公司继续寻找变得更加敏捷的新方法。
公司敏捷旅程的路径顺序可能不同。 例如，微软大约十年前开始使用小型敏捷团队，如下图所示。 它继续在2008 - 2014年期间以稳步增长的规模进行试验。 只有在Satya Nadella成为微软首席执行官的这段时间之后，这种方法才开始传播到整个组织，人们可能会认为微软是一家开始体现业务敏捷性的公司。 人们可能会称，2014年之前的微软是一个”敏捷初级阶段“公司。
相比之下，亚马逊从1997年股票市场首次亮相开始就接受了对客户的痴迷，明确承诺致力于为客户创造价值并实现市场主导地位。 仅仅五年之后 （大约2002年），亚马逊就拥抱了“双披萨团队”，并开始将网络连接在一起，而不是自上而下的层级。 在此之前，将亚马逊称为早期敏捷实例是合适的，尽管其旅程中早期步骤的顺序与微软不同。
4、冠以敏捷之名
不是每个人都按照我定义的方式使用“敏捷”。 有些人使用“敏捷”来指代任何自称或声称自己敏捷的公司。 这种用法导致许多公司被称为“敏捷”，即使他们没有与传统的官僚机构进行任何不同的管理。 它还排除了一些最成功实施敏捷的公司，因为它们不使用敏捷的标准术语。 因此，这种用法导致许多公司可能被称为“名义上的敏捷”或者我有时称之为“假敏捷”。换句话说，要了解公司是否敏捷，我们必须超越公司所说的和 看看他们是如何运作的。
“名义上的敏捷”有时也适用于那些正在实施“敏捷”仪式和流程但没有敏捷思维的公司。 他们正在做敏捷而不是”敏捷”。 例如，2016年之前的沃尔玛有许多据称敏捷的团队，但没有从这项努力中获得太多好处。 这些团队正在执行敏捷流程，但管理人员心中却没有。 他们缺乏敏捷的心态。
直到2016年，当沃尔玛收购Jet.com并招募Marc Lore领导沃尔玛的努力时，事情才开始“以初创企业的速度发展”，并且收益开始流动。 在一年之内，沃尔玛大规模扩大了在线提供的产品，提供免费的两天交付，而无需客户支付亚马逊Prime的会员资格，并将其商店部署为履行中心。 很快就会有更好的财务成果。
5、敏捷，只关乎软件开发么
对于许多敏捷专家来说，2001年敏捷软件开发宣言是敏捷运动的北极星。 它的四个价值观和十二原则已经成为数十万软件开发人员的指南，这些开发人员“通过实现和帮助其他人来实现软件开发的更好方法”。
敏捷宣言通常也是那些寻求将敏捷信息传播到软件开发之外的人的起点，因此也成为业务敏捷性的重要参考。 2011年，“宣言”的原始签署者中有10个人聚集在一起，表明没有倾向于改变宣言中的单个词或将其扩展到超越软件。 “宣言”现在具有标志性历史文件的地位，类似于“大宪章”或“独立宣言”。 虽然这些历史文件今天没有说明各自主题的最后一个字，但它们仍然是后来的永久信标。
然而，“敏捷宣言”的措辞仅限于软件开发这一事实使其不足以作为业务敏捷性的定义。 为了公平起见，“宣言”的起草者没有考虑商业敏捷性。 他们的当务之急更多是为了让软件开发人员安全。
但是将敏捷限制在软件开发上会成为一个问题。 当敏捷思维在传统管理的组织中接管软件开发时，它不可避免地开始与组织中移动速度较慢且不太灵活的其他部分发生冲突。
6、停滞的敏捷之旅
我们看到许多例子，其中敏捷成为软件开发团队日益重要的动态，但最终未能赢得最高管理层的支持。 最初，软件开发以敏捷方式运行，而组织的其他部门以传统的官僚方式运行得更加缓慢和不灵活，这并不是问题所在：管理层很高兴看到更快地交付软件。
但随着敏捷运动的扩散，两种不同操作模式之间的紧张关系可能开始成为冲突的根源。 软件开发人员对组织的其他人使用其软件并开始游说改变的速度缓慢感到沮丧。
在某些时候，由于软件开发人员想挑战那些所谓的完善管理实践，这种游说可能会激怒最高管理层。 因此，管理层可能会关闭敏捷实施并解雇敏捷领导者和教练。 当然，最高管理层不会使用这些词语。 相反，他们宣布胜利：“我们已经敏捷了。 我们不需要灵活的领导者或教练等等。“因此，敏捷之旅可能会停滞或死亡，或至少进入地下。
然而，促使公司首先追求敏捷的市场问题仍然存在。 如果没有敏捷，该公司就无法足够快地开发和调整软件 - 这是快速进行数字化世界的一个关键障碍。 通常，几年后，我们看到该公司开始了一项“变得敏捷”的新努力。
我并不是说，“仅仅为软件而敏捷”是假敏捷。 只是当敏捷管理仅限于软件时，它的预期寿命有限。 与组织其他部门的冲突是不可避免的。 敏捷和官僚主义是相互矛盾的：只有其中一个能够生存下来。
7、品牌敏捷
顾问和培训师推广的各种敏捷品牌有数百种之多。这些是与“敏捷”有相同基本思想的多种变体。然而，他们通常都坚持使用某种特定术语和特定命名过程，并这种形式来定义自己，用于区分其产品与竞争顾问和培训师的商业目的。 结果是大量混乱，如下图所示。
在这些品牌变体中，有一些可能是敏捷的。 其中许多人专注于实施“敏捷第二定律（小团队法则）——因为这是最容易训练的事情。 他们往往很少关注第一法则和第三法则——客户法则和网络法则。
并不是小团队法并不重要。 这至关重要。 但这还不够。除非公司继续执行其他两项法律，否则敏捷团队的任何收益都可能会消失并被官僚机构吞没。
另一个问题是，强调敏捷的任何特定变体作为“答案”，以及坚持使用特定的品牌标签，流程和术语，往往会分散人们对敏捷的基本内容的注意力，因为敏捷是一种根本不同的运行方式。是组织，一种新型的管理，而不仅仅是特定顾问的商品。
大约十年前，人们可以会同情Luke Halliwell的咆哮。 “我烦死了。 我等不及有一天，每个人都意识到，对于一群顾问来说，这是一种时尚饮食，宗教崇拜灵感，赚钱活动的多少。 我不能等待人们醒悟到敏捷的唯一优点只是基本的常识，不需要“宣言”或福音传道者来支持他们。”
品牌敏捷的多种形式令人困惑，并且可能导致敏捷本身可能会混淆的印象。 总体而言，“品牌敏捷”包括一些真正的敏捷和一些假的敏捷。 这里的主要警告是——提防顾问和培训师坚持认为，他们的品牌版Agile是“唯一真正的方式”。
8、大规模敏捷框架：SAFe
它是一种特别不幸的“品牌敏捷”形式，涉及大规模框架。这些计划旨在帮助那些拥有一些团队实施敏捷实践并希望解决敏捷团队与组织后台系统（如战略，规划，预算，人力资源，财务）之间紧张关系的公司，这些公司通常是单一的和官僚。
挑战通常表现为“规模化敏捷性”。这里的问题是，如果公司正在考虑“规模化敏捷性”，那么它已经走上了错误的轨道。 真正敏捷的挑战在于：如何将大型的、以内部为中心的系统缩减为可由小型自我管理的以客户为中心的团队运行。
一个特别令人担忧的变体是Scaled Agile Framework（SAFe）。 从本质上讲，这是编纂官僚主义，客户几乎完全缺席。它现在在大公司中普遍流行，因为它赋予管理层一种权利，可以称自己为敏捷并继续做他们一直以来所做的事情。 从本质上讲，它将敏捷团队从属于官僚机构，而不是为了实现业务敏捷性而做必要的事情，即将庞大的内部集中系统转变为预算，人力资源，财务等灵活且外部关注的安排。 支持敏捷团队的运营。 客户在上图中的微不足道的作用表明了问题。
SAFe可能会破坏真正的敏捷。 这是格雷西姆定律的一个例子：坏钱驱逐了善。当这种情况发生时，SAFe是“假敏捷”的缩影。当SAFe由具有真正敏捷思维模式的管理者实施时，其负面影响可能会得到缓解。 我的问题是：“为什么拥有真正敏捷思维的人会首先使用SAFe？”
9、Agile Lite（精简敏捷）
另一种令人担忧的敏捷形式已经开始出现，这种形式被称为“Agile-lite。”这篇文章出现在《哈佛商业评论》去年的一篇文章中，该文章解释了一些人力资源服务部门如何试图找到变得敏捷的方法。 这篇文章提供了标题，《HR Goes Agile》。但文中提到“人力资源正在进行’敏捷精简’。”
我们了解到“人力资源部门正在应用敏捷的一般原则，而不采用科技界的所有工具和协议 “。
从这些例子来看，似乎”Agile lite“意味着采用敏捷的工具和实践，而不必用敏捷的思维方式部署它们。 没有敏捷的心态，敏捷仍然是一种惰性的，毫无生气的仪式。
10、篇后语 我常说的一句话是：”有一千个人，就有一千种DevOps”。真真假假，并不在于谁说，而是对于使用者来说，是否真正解决了他的问题。 如果使用者说：“这解决了我的问题！”那好吧，你做的没错~
原文链接：Understanding Fake Agile by Steve Denning https://www.forbes.com/sites/stevedenning/2019/05/23/understanding-fake-agile/
行动
每日问题
- 你身边有没有假敏捷的例子，欢迎分享
