为何企业敏捷团队会失败

原文地址：
https://medium.com/startup-patterns/why-enterprise-agile-teams-fail-4ae64f7852d6
翻译君：敏杰小王子

上周，我站在一家市值 200 亿美圆的公司的会议室里，推进了一个关于敏捷的研讨会。出席会议的小组由这家大公司的一个产品线中的每一个职能部门的董事和部门经理组成。从 UX、工程和产品管理的岗位中挑选出来的十几位领导者组成了一支团队，他们表明着约 150 人的产品线。做为一个团队，他们踏上了“敏捷”的旅程。

这不是咱们平时认为的企业转型。他们的高层既没有明确支持也没有明确阻挠此次转型，这家公司对敏捷的官方态度最准确的描述是“良性冷漠”。所以，这个团队基本上只能靠本身来尝试，不管最终结果是成功仍是失败。

我在那里的惟一缘由，是由于到目前为止敏捷旅程还不顺利，个人任务是帮助他们找出症结并解决它。好巧不巧，他们出现的问题与我在过去 5 年中遇到其余团队的缘由相同。为简单起见，如下都是直言不讳的事实陈述，但也并不是都适用于您的状况。

不明确的愿景

若是你在办公室走廊拦住任何团队成员，问他：“同窗，咱们产品的长期愿景是什么？”他们可否用一两句话来回答？八成不行。他们可能对目标客户有所了解，也能够明确地知道解决方案的功能。可是，他们真的能够说出客户想要解决的痛点吗？我猜不会。

一些高级管理人员在权利更迭期间，以临别顿悟为基础传达了本身的“突发奇想”。这个“想法”被投入了预算计划角逐会议中，这位特别的高管最终赢得了影响力战，并获得了 12 个月的项目资助。紧接着这一消息的全部内容经过一个既成事实的 PPT 传递给你，功能和时间表提早计划好了，你被正式告知“请实现它”。如今你正试图完成那个不可能完成的任务，并但愿敏捷能帮到你。

解决方案：花一些时间阐明产品的清晰愿景，使用业务模型或精简图片表达您的设想，邀请团队中的每一个人参与，将这些设想反馈给高层管理人员（若是他们拒绝参加），并确保你的相关信息出如今同一页面上。

PS：若是他们找你麻烦，给我打个电话。

被混淆的业务指标

该团队不会考虑平常的成本和收入。事实上，团队可能不知道公司要让他们赚多少钱，他们也不知道他们须要拓展多少客户，每一个时间段须要支付多少钱，以便他们在这个疯狂的想法上实现收支平衡。他们基本上不太关心本身的工资来自何处。

但若是你问大多数初创公司，他们对本身总体燃烧率和销售业绩会有更好的了解，由于收入和盈利能力对于他们来讲始终是最重要的。

其实这个成本在任何状况下都不难计算。直线经理（Line Manager）一般能够在几分钟内得出工程团队燃烧率的准确数字。而后当咱们将这个数字（实际成本）与咱们当前的销售数据（咱们做为一个团队实际产生的收入）进行比较时，这就会是一个全新的业务竞赛。
译者注：直线经理（Line Manager）是指诸如财务、生产、销售等职能部门经理，每个直线经理肩负着完成部门目标和对部门进行管理的职责。

解决方案：计算您的产品成功所需的团队收入和成本，并确保每一个人都知晓。它颇有可能会让人大开眼界。您应该在下一次业务规划会议上与您的团队一块儿尝试。

持续不断的干涉

因为方向上的某些紧急变化，您最后一次中断正常工做流是何时？它能够是最近的客户投诉或请求，也能够是来自首席执行官措辞强烈的电子邮件——邮件涉及团队在上周产品演示中使用的配色方案。

不管如何，若是你老是打破团队的正常工做流，会给团队带来巨大的压力。这种压力转化为吞吐量下降、士气低落、人员流动率增长、航运延误、工艺粗劣、以及对团队绩效的广泛拖累。因此把这个坏习惯丢弃掉吧，您并无由于在组织中的管理地位而拥有在事务优先级排序方案中的特权。

解决方案：每周为计划外工做分配一些容量，好比总容量的 20％，只安排 80％ 的团队时间，而不计划其他的时间。能够在发生“紧急状况”时使用此容量，而不会影响原来的正常计划。无人认领的话能够用它来偿还技术债务。您能够轮换团队成员来执行此操做。

不够专一的团队

我工做过的每一个大公司都有这个问题。项目中的大多数人被分配到多个其余项目当中。当我问团队中都有谁时，我获得的答案通常是某位工程师分配了 50％ 在这个项目上，而某位工程师与咱们在一块儿的时间占 20％，超过一半的项目人员将一半以上的时间花在其余项目上。难怪项目的最终结果每每是事故，由于这种工做方式无论用。

产品开发是一项团队活动，团队成员之间须要极大的关注和大量的沟通和协调。您团队中的每一个人在部分时间内被分配到其余项目，这会使交付日期经常延迟数周或数月。

关于这一点我从企业管理者那里获得了更多的案例，举一个具体的例子，你也许会问：“咱们真的须要在团队中设置专门的产品体验人员吗？若是他们一半闲着怎么办？咱们不是在浪费钱吗？”

让咱们思考一下：

假设你有十个工程师和一个交互设计师（原本不该该是这个 1/10 的比例，但你可能会这样作，因此咱们姑且先这么选着）。设计师为工程师构建了 100 个线框，如今你有 10 名工程师开始工做，设计师又回到了其余项目。

工程师几乎当即向设计师提出了要求，但设计师此时被其余项目束缚，因此工程师必须等待（延迟）。也许工程师选择打开另外一项任务并开始工做。当设计师从新上线时，工程师必须暂时放下第二个任务以从新打开第一个任务（延迟）。

如今，第二位工程师须要帮助，可能还有第三个工程师，他们都在等待（延迟）。设计师再次有空并开始与第一位工程师合做，而其余两位排队等候（延迟），后二者的任务未完成（延迟）。全部三位工程师都失去了他们正在研究的一些事情的背景（延迟）。

在与第一位工程师合做时，设计师发现了设计中的错误，须要更新全部 100 个线框（大延迟）。如今，每一个工程师都必须中止并从新检查他们的工做以应对新设计（大延迟），已经完成的一些工做必须废弃并从新开始（更大的延迟）。

因此你是选择执拗己见仍是有所改变？您能够试试把上面的示例中替换成后端 API 开发人员，事情的结果会变得更糟。

解决方案：请组织小型、跨职能、专一的团队，将一小组做为一个单元一块儿工做，并不断得到双方关于事务进展的反馈与澄清。

分散各地的团队

大型企业团队每每由一个地理位置分散的大型池的“资源”组成（原谅我用“资源”这个词）。所以，企业产品团队的成员处于不一样的时区和地区，这使得沟通协调效率低下且成本昂贵，结果就会发生不少延迟等待和错误传达。远程通讯的保真度绝对不如面对面沟通，视频通话确实让沟通变得更容易一些，但它与可以一块儿走到白板前讨论出来的东西并不相同。

解决方案：将全部团队成员放在同一个房间，或至少在同一建筑物的同一楼层。若是您必须与远程人员一块儿工做，请根据康威定律分解任务，按地理划分（具备明肯定义的接口的模块）而不是按功能划分（设计、工程）。

太过臃肿的团队

一般状况下，在企业中找到大型团队来构建产品不是那么复杂的事情。但因为各类缘由，团队规模经常大得惊人，这主要与高管倾向于经过指挥大群人来创建自个人事实有关。

100 名工程师构建一个 SaaS 产品？你肯定？较大的团队效率更慢，由于协调成本是巨大的。您须要更多层次的管理，更多会议和更多文档。大型团队对其速度的负面影响随着其增加而渐渐变得更强烈。

解决方案：您应该使用尽量小的团队在企业中构建产品。若是你能够把它减小到几十个，甚至一打，那就更好。

过重的技术债务

企业每每有不少旧的代码库。然而这并非企业敏捷团队积累技术债务的真正缘由。我敢打赌，您当前项目中的大部分技术债务是从您当前项目开始以来由您的团队建立的，而不是经过来自较旧的遗留系统的继承。

这是由于，尽管敏捷社区重复了 15 年：
（1）结对编程技术实践的重要性
（2）测试驱动开发
（3）对代码的持续集成
但很是少的企业团队真正去作这些事情。出于各类缘由（主要是由于那些专一于流程而非卓越技术的大型咨询公司向高管出售的所谓“敏捷”），企业敏捷团队不多接受：核心技术实践使得敏捷出色。结果大型的工程团队开始设计和执行有缺陷的系统，而后在漫长而痛苦的发布周期中相互折磨。

解决方案：考虑采用“极限编程”，使用敏捷的技术实践。此外还要考虑使用敏捷构建的现代技术工具和语言。

太多的并发事务

拥有专门团队的关键是一次只作一部分事情而且把它作得很是好。大多数企业团队可能由于他们的人员太多而倾向于同时处理数十种特性。

将迭代限制为几个关键功能会好不少。在看板语言中，咱们称之为“在制品”（WIP）限制。实际上您能够经过强制许多人在相同的项目上一块儿工做来建立更加协做的环境。因为 WIP 限制，不容许任何人在未完成目前事务前开始新事务。它可使事务一次作得愈来愈少，愈来愈好。减小返工和减小错误，会带来更多团队合做、更高的品质和更高的士气。

方案：当即实施 WIP 限制。若是您有一个 10 人团队，请将 WIP 限制设置为 5 个项目，以便每一个人都被迫与其余人结对工做。相信我，效果会让你感到惊讶。

更长的部署软件时间

大多数企业所处的遗留系统的问题是部署时间过长。企业一般由一个运维团队负责将代码引导到生产环境。这些人员通过培训，须要确保代码被批准在公司服务器上运行以前是安全，高效和可用的。

当你火烧眉毛让凡人工程师将他们本身的代码手动部署到生产中时，像亚马逊这样的公司已经迅速抢占你的市场份额。您可能依然在权衡开放生产环境访问权限的风险以及在市场中灭绝的风险，这是由于您对竞争威胁的反应太慢。

解决方案：DevOps。任何工程师都应该可以随时启动新的开发和测试基础架构。软件推送到生产环境应该经过一个自动化过程，并具有全部必要的测试和标准。

被忽视的企业其余成员

最后，在您的敏捷“实验”中，对您和团队来讲很是重要的成员，那些不须要完成任何关键特性可是你不得不合做的团队：采购、法律、营销、人力资源等这些岗位人员。若是您必须及时与组织中这些非敏捷团队进行协调，那么您会很容易心累。须要有一种方式与团队外的团队合做，这种方式不会彻底搞砸你的努力。

咱们在敏捷社区中注意到，由高层管理者提供自上而下的命令，敏捷转型每每并不会真正起做用。除非被雇佣的执行层人员对转型十分兴奋，不然敏捷转型这事就不会被坚持下去。没有执行支持，也不会自下而上。

解决方案：基本上您有三种策略能够处理转型问题，须要同时完成全部操做：

• 在您的组织内进行持续影响力的活动，以赢得关键的高层支持者。我保证您的企业中还有其余高管和经理也在尝试或考虑在某个范围或规模上尝试敏捷，去寻找他们并结成联盟。毕竟，在大型人类社会中变化是如何发生的，在大公司也不例外。
• 找出你须要从非敏捷特性团队获得的东西，并确保提早与这些团队交谈。告诉他们你正在作什么，事情是如何运做的，最重要的是如何让他们更容易地与你一块儿工做。
• 无情地削减你的依赖。这部分或多或少在你的控制之下。推进使用工具、基础设施、营销材料、法律语言等，您和您的团队能够本身构建、借阅或购买。要作到这一点须要时间，因此你应该立刻开始行动。

敏捷，作得对的话，效果惊人

尝试敏捷并不疯狂，事实上，我认为这是让你的公司进入下一代所需的竞争斗罗场的惟一途径。另外一种选择是缓慢地或快速地倒在更小、更灵活的竞争对手石榴裙下。