今天的组织正在采用各种新的方法论，希望为他们的业务找到最佳的竞争优势。一些人期待着主流的敏捷方法论，而另一些人则从Spotify这样的组织中寻找灵感。
敏捷领域有如此多的框架、模型、术语和观点，对于企业领导者和敏捷专业人士来说，决定哪种方法最适合他们的组织，甚至从哪里开始，都是一个挑战。
在本文中，我们将探讨这两种方法之间的关系： Scrum@Scale®以及所谓的 "Spotify 模式"。
一些[i] 目前将 Spotify 模式和 Scrum@Scale 作为两个独立的敏捷扩展框架。然而，在 2019 年，注册 Scrum@Scale Trainer™ 和 Spotify 的前 Agile Coach Henrik Kniberg 发布了一份 Scrum@Scale 案例研究，题为"Spotify - a Scrum@Scale 案例研究在这篇文章中，他解释说，"Spotify 模式 "实际上只是 "Spotify 模式 "的早期实现。 Scrum@Scale.[二]
什么是Spotify模式？
Spotify 模式于 2012 年首次推出，当时 Henrik Kniberg 和 Anders Ivarsson 发布了题为 "Spotify 模式 "的白皮书。敏捷的扩展@Spotify."在这篇论文中，Kniberg 和 Ivarsson 详细介绍了 Spotify 实现敏捷性的方法。自该论文发表以来、 亨利克-克尼伯格 他曾多次表示，Spotify 模式并不是一个框架，而是代表了 Spotify 从技术和文化角度对扩展的看法。
2012 年，Kniberg & Ivarsson 的 "Spotify 的敏捷扩展 "一文详细介绍了 Spotify 如何利用小队、部落、分会和行会将规模扩大到 30 多个团队。
正如亨里克所说，"我花了几年时间与 焦点网 并发表了一些东西....这在敏捷领域被称为 "Spotify 模型"，尽管它实际上根本不是一个通用框架或 "模型"。这只是一家公司如何工作的一个例子"。[四]
什么是 Scrum@Scale Framework？
"(《世界人权宣言》) Scrum@Scale 框架则是一个实际的框架。 Scrum@Scale 自然扩展了核心 Scrum 该框架可为任何组织提供更好的结果。它为系统和流程的有机发展提供了脚手架，使组织能够实现业务灵活性并产生更大的影响。而不是试图采用 "一刀切 "的交钥匙解决方案、 Scrum@Scale 提供了一个轻量级、适应性强的框架，能够根据具体情况进行调整，因此可以跨行业定制。杰夫-萨瑟兰（Jeff Sutherland）博士是 Scrum萨瑟兰大学的研究人员花了数年时间编纂缩放的领先实践，该框架最早的实验始于 1983 年。2018 年初，萨瑟兰正式推出了 的 Scrum@ 比例指南[v] 敏捷社区将其称为 "组织迭代开发最佳方法的框架"。 Scrum "。
"(《世界人权宣言》) Scrum@Scale 指南》详细介绍了 Scrum@Scale 框架，使组织能够安装 "敏捷操作系统"。该 Product Owner 周期和 Scrum Master 周期对于产品增量、发布和反馈至关重要。
从源头开始采访杰夫-萨瑟兰博士和阿维-施奈尔
Spotify 模式和 Scrum@Scale 是一致的，但模型和框架之间的差异也很重要。为了提供更多的背景和历史，我们请到了 @Scale 的共同创建者杰夫-萨瑟兰博士。 Scrum 的发明者 Scrum@Scale的首席顾问 Avi Schneier。 Scrum 公司和 Scrum@Scale 导读，回答一些最热门的问题，如 "与......之间的关系"。 Scrum@Scale 和 Spotify 模式。
问：什么时候 Scrum@Scale 发明的，什么时候首次 "发布 "的？
萨瑟兰: "我的第一个想法雏形是围绕着缩放，最终合成了 Scrum@Scale 于 1983 年在 Mid-Continent Computer Services 实施。随后又在多家公司实施了多个增强版本，直到第一代 @Scale 诞生。 Scrum 小组 于 1993 年成立。1995 年，我和肯-施瓦伯（Ken Schwaber）撰写了第一份正式论文，内容涉及 Scrum.1996 年，我们在这篇正式论文的基础上实施了第一套团队计划。 Scrum.它包含了我们今天所知的 Scrum@Scale，包括基于组件的架构。这种基于组件的架构允许公司像构建产品一样构建自己的组织。原型 Scrum@Scale 在市场上，在数百家公司中不断发展和适应，直到英特尔敏捷领导力要求我创建一个正式的 Scrum@Scale Guide。早期迭代的 Scrum@Scale Guide》于 2014 年根据真实的市场反馈精心编纂，1.0 版于 2018 年正式发布。"
早期的 Scrum@Scale 框架在市场中不断发展和适应。2010 年代，Jeff Sutherland 和 Scrum 公司的 ™ 开始迭代 Scrum@Scale 文档。
Q: "像建造产品一样建造你的组织."这意味着什么？是否每个 Scrum@Scale unique?
萨瑟兰:"如今，产品需要有一个可扩展的组件模型，这样系统的任何部分都可以每天升级，而不会破坏系统的其他部分。萨博技术公司（Saab Technologies）制造战斗机、特斯拉公司（Tesla）制造汽车、苹果公司（Apple）制造 iPad，都采用了这种策略。
企业要想成功打造此类产品并扩大规模，其组织模式必须与技术实施同步，否则就无法像亚马逊那样，每天都对新功能进行改进，而这些新功能在市场上的部署速度超过每秒一次。这种速度可以在数周内颠覆整个行业。例如，几年前，亚马逊迅速占领了德国大部分消费贷款市场。
施奈尔: "这实际上是我所看到的组织在采用以下技术时面临的最大挑战 Scrum@Scale.常见的错误是利用现有的层次结构，试图映射出 Scrum@Scale 以及团队需要在此基础上进行组织的方式。这是有问题的。正确的方法是，首先绘制出价值流，然后再将人员绘制到价值流上。我们说，为了实现大规模敏捷，你必须愿意重构组织以优化生产。抵制这种做法只会造成浪费。
问：一目了然：什么是Spotify模式？
萨瑟兰:"当亨里克接任 Spotify 敏捷/精益 Coach 负责人一职时，他们正在进行以下工作 Scrum.然而、 Scrum 大师们没有领先，团队也没有表现，于是亨利克做出了一些改变。他将团队更名为 "Squad"，将团队分组称为 "Tribes"，并让拥有 Agile Coaches 的团队提高绩效。经理们负责 "分会"，包括招聘和培训各团队具备特定技能的开发人员。亨里克和我正在教授 Scrum@Scale 一起在斯德哥尔摩，所以这时候会有相互交叉的反馈。我在斯德哥尔摩时访问了 Spotify，亨利克和我会在那里与 Agile Coaches 会面，解决关键问题。
例如，Spotify 首席执行官告诉亨里克，团队必须以两倍的速度交付，才能与谷歌和亚马逊竞争。在 Spotify 召开的 Agile Coaches 会议上，我们注意到所有团队都在以每秒 1,000 次的速度交付产品。 短跑 但将产量翻番的最佳方法是指导开发人员每天交付，就像谷歌和亚马逊一样。在大约六个月的时间里，我们让大约 ⅓ 的团队每天都能交付成果。
施奈尔: "今天所谓的 "Spotify 模式 "实际上与 Spotify 或他们的工作方式并无多大关系。在大多数情况下，公司和顾问在采用这些术语的同时，却放弃了当初让 Spotify 取得成功的关键结构、做法和思维方式。"
问：什么问题 Scrum@Scale solve?
萨瑟兰: "Scrum@Scale 是一款适用于所有组织的操作系统，它能以一半的成本提供两倍的价值，使组织实现真正的业务敏捷性。它是在与世界上一些最大、最有价值的公司合作的基础上开发出来的。IEEE 数字图书馆的一篇新论文 "Scale @Scale "展示了在一半时间内实现两倍价值的方法。火箭抵押贷款以一半的时间提供两倍的价值的规模."[vi] 本文将逐步说明，即使是一个成功的大型 SAFe 实施项目，也可以通过实施以下方法将周期时间减少 400% Scrum@Scale"
问：Spotify 模式是早期实施的 Scrum@Scale?
萨瑟兰:"Scrum@Scale 明确了执行行动小组和 MetaScrum 对公司实现更高价值至关重要的论坛。如果是私营企业，这通常会反映在股票价格或公司估值上。它还更严格地执行 Scrum 并期望 Scrum 大师们要成为'服务的领导者'。
Henrik Kniberg 在 Spotify 实施的项目对当时的公司来说非常有价值。 该项目将Spotify带入了上市阶段，并激励了许多敏捷开发人员。亨里克经常邀请我访问Spotify，与Agile Coaches一起解决他们最棘手的问题。正如 Henrik 在他的 Scrum@Scale 案例研究，它是 Scrum@Scale 适合其时代和地点。Spotify 管理层表示，他们已不再使用该模型，而且该模型的创建者目前都与 Spotify 无关。
正如 Spotify 工程总监 Marcin Floryan 所说："这种模式不是我们发明的。Spotify 正在（像所有优秀的敏捷公司一样）快速发展。这篇文章只是我们当前工作方式的一个缩影，是一个进行中的旅程，而不是一个完整的旅程。当您读到这篇文章时，情况已经发生了变化。[vii]
问：当一家公司 "复制 "另一家公司的做法时，会出现什么问题？如果只是 "照搬 "Spotify 模式，企业会承担什么风险？
施奈尔:"当我们开始与一批新的企业领导人合作时，经常会被要求实施 "最佳实践"。这往往是一种愚蠢的尝试。首先，我们无法保证采用不同组织的工作方式（包括敏捷工作方式）就一定适合你的情况。虽然公司面临的大多数问题都很常见，但每家公司的产品、生态系统和文化都是独一无二的。这就是为什么 "一刀切 "的方法注定是行不通的。当我们从研究特定实践或框架取得成功的根本 "原因 "开始，然后尝试并不断改进它如何在你的环境和文化中发挥作用时，就能取得最好的结果。这就是为什么 Scrum@Scale 已在众多组织和领域证明了自己的能力。
其次，"最佳实践 "的概念意味着没有更好的方法，它阻止了采用组织进行有机搜索，以找到最适合他们的方法。我更喜欢用 "领先实践 "或 "更好的实践 "来鼓励采用并继续搜索。企业采用 Spotify 模式的主要风险在于，他们不是 Spotify，因此不仅会失败，还会阻碍他们真正找到更好的运营方式。
问：Spotify 出现了哪些扩展模式？其中有哪些最终在 Scrum@Scale 框架？
萨瑟兰:"创造了 Scrum@Scale 在模式手册 (Scrum:游戏精神[viii])，而这些模式是从Spotify之前几十年存在的公司发展而来的。
我从 Spotify 得到的主要启示是，仅有 Agile Coaches 是不够的，我们还需要 Scrum 大师将是 Agile Coaches，这也是我们在 Scrum 公司。亨里克制定了一项正式标准，即 Agile Coaches 的总重量必须达到 100 公斤。 关注 改善团队。
在我看来，Spotify 的第二个宝贵之处在于作为 "分会领导 "的经理们。经理们负责招聘、解雇、培训和激励各组织特定技能领域的员工。此外，他们还制定整个组织的工具、质量和绩效标准。他们不对员工进行任何直接的日常管理。
施奈尔:"这种模式虽然不是 S@S 的正式组成部分，但却是我们通过实践社区和质量圈概念推广的一种有益做法"。
问：还有哪些早期的 Scrum@Scale 影响了 Scrum@Scale 框架？
萨瑟兰:"1983年，中洲计算机服务公司的第一个原型拥有Sprints、Backlogs、Product Owners、自组织团队、Burndown Charts等，并在六个月内使ATM业务部门成为最赚钱的业务部门。这正是我们希望在所有 Scrum@Scale 实现。
首次实施 Scrum@ 正式的规模 Scrum 肯和我发布的模型是在 1996 年上市的一家互联网公司（Individual Inc.）当时，我们还与富达（Fidelity）等公司的大型团队合作。
正式的基础知识 Scrum@Scale 在 1996-2000 年期间在 IDX（现为通用电气医疗集团）得到了进一步充实。在《@Scale》一书中描述的扩展模式反复提到了 IDX。 Scrum:游戏精神.
Scrum 随着 2001 年《敏捷宣言》的发布，敏捷技术迅速发展。[ix]. 到了2005年，Ken要求我培训硅谷的所有主要公司。雅虎、谷歌、Adobe和其他许多公司在那个时候都开始了Scrumming的大组团队。
2000 年至 2008 年，我担任 PatientKeeper 公司的首席技术官，该公司是业绩最高的公司之一。 Scrum@ 有史以来规模最大的一组团队记录。[x] "(《世界人权宣言》) MetaScrum 在 PatientKeeper 进一步完善。
到2009年，我在Pegasystems等公司实施S@S，取得了类似1983年在Mid-Continent Computer Services实施的戏剧性结果。
正式文件 Scrum@Scale 对英特尔和 SAP 的敏捷领导力至关重要，自 2005 年以来，微软和亚马逊的数千个团队所做的工作也很有影响力。SAP 的敏捷领导层拥有超过 2000 Scrum 团队的帮助下，首次发布了 Scrum规模指南》，并坚持认为有必要制定有效的 MetaScrum."
问："与 Scrum@Scale 就是交付"：S@S 如何帮助团队交付？
萨瑟兰: "正如前面提到的论文中详细说明的那样，"火箭抵押贷款以一半的成本提供了两倍的价值", Scrum@Scale 系统地分析业务和技术操作，并实施具有最大成本/效益影响的改进措施。
Rocket Mortgage 的第一步是获得一致的 Scrum 已执行。他们取消了 15 个 SAFe 作用 并将其切成三段 作用 在 Scrum 指南。所有其他 作用 他们被重新培训为团队成员，或被调到公司的其他部门。第二步是实施交付 关注 在所有 作用 和所有会议。
Product Owners 需要提高每个点的价值交付。 Scrum 大师们必须提高团队绩效。那些不能有效完成这项工作的人则被调到其他岗位。 作用 在公司里。会议改为完全 关注 交付。他们改变了时间安排、议程和参与者，以便在越来越短的时间内交付功能齐全的产品，直至实现每日实时产品升级。
论文中还有许多其他细节，向企业展示了如何逐步使用 Scrum利用任何已有的敏捷实施或扩展框架，@Scale 提升性能，影响市场份额"。
施奈尔:"如果你看看 Kniberg 最早在 Spotify 上发布的视频和论文，你会发现很多都在强调以 DevOps 的方式发布。这就是它们之间的联系。正如 Scrum 与传输方式无关，所以 Scrum@Scale.尽管如此，如果 Scrum 小组 - 因此是一个 Scrum 团队，或 Scrum 我们称之为 Scrums--是一条独立的生产路径，那么你就能理解为什么我们会支持 DevOps 或 DevSecOps 类型的交付方法。这是向客户提供工作产品的最快方式。
结论：
如果您和许多企业领导者一样，正在寻找如何组建团队或扩大规模的答案 Scrum 为了实现更好的业务成果和敏捷性，不要满足于采用别人尝试过的方法，并期待获得同样的结果。没有神奇的万能解决方案。每个组织都应定期检查其做法，并随着环境、市场和文化的不可避免的变化而不断发展和调整。
或者，正如 耶利米-李前Spotify的产品经理雄辩地说道、 "您发现 Spotify 模式的原因可能是您正在尝试如何组建团队。不要就此止步。继续研究......事实证明，2012 年的 Spotify 还没有想出如何在大型组织中保持小团队的速度和灵活性。公司的发展超越了其同名模式，而是跳出自身寻找更好的答案。你也应该这样做"。[十一]
这就是 Scrum@Scale 的教学内容和 Spotify 的实例化内容。作为一个框架、 Scrum@Scale 通过一个 最基本的官僚机构 (MVB），它不会以特定的方式限制增长。取而代之的是 Scrum@Scale 允许团队网络根据网络的独特需求，以可持续的变革速度有机地发展，从而更好地为相关个人和整个组织所接受。
参考文献