为什么大规模 Scrum 框架大都只是跟风，迟早会被放弃？

我必须承认：我从未见过有哪个大规模 Scrum 框架获得了成功。不过这并不是说我已经见过了现实中所有的大规模框架。我非常怀疑世界上是否有什么人对所有这些框架都有着深入而全面的经验。

本文最初发布于 Medium 网站，经原作者授权由 InfoQ 中文站翻译并分享。

每隔一段时间我们就能见到新的大规模框架面世，感谢上帝，这个领域出新的速度好歹比 JavaScript 框架要慢一些。如果你就是那位对所有大规模框架都有实践经验的天选之子，请与我联系，我想向你学习。

尽管我已经熟悉了许多大规模框架，但没有一次实践经验是正面的。多年来，在引入大规模框架的过程中我遇到了许多挑战。我写这篇文章是为了表达这些担忧，并分享一种更好的方法帮助大家思考组织扩展的主题。

这个指尖陀螺的风潮我就一直没搞懂

并不是只有我才对大规模框架持保留态度。当 Jeremiah Lee 发表了他揭穿 Spotify 模型有效性的帖子后，我真的松了一口气。到头来总算有人提供了具体的证据，告诉大家为什么这个框架那么受欢迎、广告打得那么好，可就是没啥用。

Jeremiah 的帖子和我对 Spotify 模型的个人体验是一致的。我个人见到它被采用就有几次了，但我从未见过它产生了什么积极的影响。

它也不是唯一一个受到严厉批评的大规模框架。Stefan Wolpers 证实 Scaled Agile Framework（SAFe）实际上在从业者中具有负的净推荐值。简而言之，这意味着在 SAFe 环境中工作的专家会积极阻止其他人采用它。竟然会这样！

我曾在多家使用各种大规模框架的公司工作过。所有这些框架都引入了不必要的复杂性，让事情变得更糟。我所看到的只是一大堆占据上风的繁文缛节，而实际问题却被掩盖了。大规模框架往往不会解决问题，而只是在保护现状。它们具有破坏性，让人们懒惰成性，使组织走上平庸之路。

于是我提出了以下问题：

为什么大规模框架在实践中往往不能解决它们承诺解决的问题？

好吧，我不相信这个问题有一个单一的、简洁的答案。但我确实相信有几个重要的因素加在一起可以解释，为什么许多大规模框架在设计层面就注定要失败。

1 坚持让框架成为所有问题的默认解决方案

采用大规模框架后，组织的注意力就要从解决我们遇到的问题转移到遵循框架规则上。这里面的逻辑是，如果我们在引入大规模框架后仍会遇到问题，那么我们在实现框架的时候一定做错了什么事情。

我们相信广告词，自然也就认为框架提供的解决方案肯定是有效的。我们并没有追根究底，保持好奇心，而是死盯着一个问题：“我们在实现大规模框架的时候做错了什么？”因此，我们提出的所有解决方案都局限在框架里面。我们忽略了一种可能性，那就是这个框架可能并不足以解决我们的问题。

公平地说，许多 Scrum 团队都面临着同样的问题。他们关注的并不是如何才能更好地交付价值，而是如何更好地执行 Scrum。可是 Scrum 的执行从来都不是重点所在。请记住，大规模框架之类的 Scrum 都只是达到目标的一种手段，而非目标本身。

Scrum 的目标是帮助你找出交付价值最高的产品的最佳方式。你最应该关注的是价值的交付，而非死死遵循 Scrum 的规则。

根据我的经验，随着时间的推移，我们对大规模框架的规则也会越来越驾轻就熟。但是，无论我们多么遵守和忠实于那些规则，我们打算处理的问题都没有得到妥善解决。

事实上，事情似乎总会变得更糟。由于官僚主义日益盛行、灵活性不断缩减，新的问题不断出现，原本的问题却一个都没解决。大规模框架承诺的是提供一种解决问题的捷径，就像是你在减肥时采用的那种流行健康食谱：你只需按步骤一步步来，就可以保证成功——真要是有那么容易就好了。

大规模框架往往承诺为懒惰和绝望的人们提供神奇的解决方案：用不着思考，照我们说的去做，一切都会变好的。

这与 Scrum 本应遵循的机制完全相反。Scrum 遵循以下格言：“我们不会告诉你该做什么，但我们会让你清楚地看到那些痛点，然后你需要自己来搞定它们”。

捷径是不存在的。你需要通过尝试、失败并坚持遵循可以产生结果的路径来弄清楚哪些东西才是有效的。你不应该盲目地遵循框架的配方，以为那些配方可以取代常识。

2 复制粘贴大规模框架会阻止人们汲取经验教训

大规模框架（如 SAFe）越规范，它与 Scrum 基于经验的核心理念的冲突就越多。在一种情况下有效的方法可能在另一种情况下毫无作用。你只能不断去尝试各种事物，并评估它们是否真的有效，才能解决这个问题。

问题是大多数大规模框架捆绑了许多不同的实践。这是一锤子买卖。当你实现整个 shebang 时，你怎么知道哪些东西才是真正有效的，哪些又是无效的呢？

想象一下，淋浴间某处开始漏水。结果你并没有花时间弄清楚漏点在哪里，而是决定更换淋浴房下方的地板和所有管道。大动干戈完之后漏水问题依旧。你到底有没有补上原来的漏点呢，还是说你又搞出来了新的漏点？你同时改变了这么多东西，谁能知道到底是怎么回事。

这正是引入大规模框架时会发生的情况。当你一次引入如此多的更改时，就很难确定哪些是有效的，哪些不起作用。当你遵循经验方法时，你会一点点尝试更改并留下那些起作用的东西。否则，这种方法就不是基于经验和证据的实证方法。使用许多大规模框架时，你只是在根据直觉而不是具体的证据来调配你的流程鸡尾酒。

应对淋浴房漏水的问题时，我们应该在动工之前先找出漏点的位置，然后实施你认为可以解决或改善问题的最简单方法。这样，你就可以定位你面临的是哪些问题，然后就能确定你的解决方案是否真的有效。这种方法的另一个好处是你只会留下最简单的方案，而且不会引入不必要的复杂性。

实现功能丰富的大规模框架时，你会很难从失败中学习经验教训。你同时实现的更改越多，就越难确定哪些进展是顺利的，哪些进展遇到了障碍。到最后你会保留许多冗余实践，这些实践中还经常会隐藏新的问题。

3 Scrum 的最大要点在于它是故意不完整的

Scrum的全部意义都在于让你自己来发明交付价值的规则。这里面包括了在组织的发展过程中你将遇到的所有扩展问题。如果你不能自己解决扩展问题，也许你就不应该使用 Scrum。这足以证明你无法处理 Scrum 背后的流程框架哲学。

SAFe 带有自己的 Scrum 变体，ScrumXP，它可能更适合你。无需多想，一条条遵循 SAFe 的理念走下去即可，一切都会好起来的——至少这是它们的承诺。

Scrum 要求你添加自己的个人风格，并通过交付价值所需的流程来丰富完善这种风格。如果你没有能力做到这一点，那么请不要使用 Scrum，它是不会给你帮助的。

是否所有大规模框架都提供了一个懒惰且破坏性的自助套餐，让你的扩展之路走向失败呢？

现在，我并不能说自己已经有了所有大规模框架的实践经验，自然也没法断言所有大规模框架都是懒惰和破坏性的，就像那些流行健康食谱一样。有一些大规模框架试图走上正路，LeSS（LargeScaleScrum）就是一个例子。正如首字母缩略词暗示的那样，它是轻量级的，并承认永远都不会有什么万能灵药。

下面这条 LeSS 原则就说明了这一点：

事半功倍——（1）在经验流程控制中：用定义较少的流程学习更多经验。（2）在精益思想中：以更少的浪费和开销获得更多的价值。（3）在扩展方面，以更少的角色、组件和特殊小组获得更多的所有权、目的和乐趣。

你可以去了解实现各个大规模框架时可能遇到的不同问题，从中选择正确的方法。如果你决定使用某个大规模框架，请在使用任何重量级方法（例如 SAFe）之前先选择一种轻量级方法，例如 LeSS。

你可以逐渐引入这种轻量级方法的各个部分，并评估它是否真的产生了你期望的改进，否则就改进或放弃它。LeSS 就是本着这种精神创建的——尽可能消除不必要的复杂性。

你可以去了解各种大规模框架，并挑选出那些可能解决你所面临问题的具体部分。每个大规模框架都有其优点和缺点。就像减肥一样，对别人有效的方法可能对你就无效。甚至有人通过赛百味节食方法就减掉了111公斤。但你可以将他人的经验为我所用，从中找到你自己的方法去适应你的独特情况和问题。

这做起来并不容易，但你从中可以期待的回报远远大于复制粘贴样板解决方案所带来的收益。根据你的独特环境和需求去定制价值交付流程，从而交付最大价值。你添加的所有复杂性都必须发挥作用。如果你一次添加太多更改，你将永远无法弄清楚每个更改到底有哪些贡献。

作为这种极简主义方法的具体示例，可以参考我多次介绍过的 Feature Teams，但不需要实现 LeSS。我确实受益于 LeSS 框架提出的，关于如何引入 Feature Teams 的最佳实践。在实现了 Feature Teams 之后，我们的很多问题都消失了，也就没有必要再引入 LeSS 的其他部分。

用统计和经济学家 Ernst F.Schumacher 的话来说：

“只会小聪明的人们都会让事情变得更大、更复杂、更暴力。这需要一点点天赋——以及朝着相反方向前进的巨大勇气。”

大多数大规模框架就像本文开头图片中的指尖陀螺一样：它们看起来漂亮而闪亮，当你看到有人在玩指尖陀螺时，你会迫不及待地想要玩一把。但是当你终于买了一个陀螺，并第一次用手指旋转它时，你就开始后悔了。你不禁想知道：“我怎么又交了一次智商税呢？”。

原文链接：https://medium.com/serious-scrum/why-most-scaling-frameworks-are-a-fad-that-will-blow-over-c05d2c24f879