被全球过度炒作的Spotify敏捷部落制，连Spotify公司自己都不用 | IDCF

内容来源：Agile2046

作者：Jeremiah Lee

本文译自：https://www.jeremiahlee.com/posts/failed-squad-goals/

原文文章题目：《Failed Squad Goals--Spotify doesn’t use “the Spotify model” and neither should you》

编者推荐阅读原因

业界对于各个规模化敏捷框架的争议声音从来没有停止过，而Spotify的敏捷部落制一直保持着独有的、人们对其的普遍向往和憧憬。直到看到今年4月份的一篇Spotify离职员工Jee Jeremiah写的博文，让我们冷静地思考：Spotify敏捷部落制在Spotify公司真的有传说的那么神么？毕竟我们所获得的信息都是从网络而来，并没有亲赴瑞典参观过Spotify公司。

本文的目的不是批评Spotify敏捷部落制本身。Spotify有其优势，我们Agile2046团队也有应用Spotify部落制的经验。本文的目的是希望让大家听到来自Spotify员工的声音，兼听则明。

背景

Spotify公司是瑞典知名的数字音乐服务提供商，截止到2015年1月，Spotify已经拥有超过6000万的用户，其中1500万为付费用户。2017年12月8日，Spotify与腾讯控股有限公司及腾讯旗下的腾讯音乐娱乐集团联合宣布股权投资；2018年4月3日，Spotify登录纽交所，成为首家“直接上市”的公司；2019年10月，Interbrand发布的全球品牌百强榜排名92 。

Spotify公司在敏捷界知名的是其敏捷工作方式，员工在“跨职能、自我组织、自我学习的协作团队” 中工作。团队端到端负责不同设备平台上Spotify产品体验的某一特定部分。

下图是Spotify敏捷部落制框架：

“Spotify模型的合著者和多名在Spotify工作的敏捷教练多年来一直在告诉人们不要抄袭Spotify。不幸的是，人们愿意让其相信的东西迅速和广泛传播，尽管传播的东西并不是事实。即使在我们写Spotify模型的时候，我们也没有完全按照写的那样做。模型里的内容，部分是雄心壮志，部分是近似于事实。人们一直在努力复制那些并不存在的东西。”

---2011年至2017年之间在Spotify做敏捷教练的Joakim Sundén 

“当人们认为我们在Spotify所做的实践是一个可以复制和实施的框架时，我很担心……我们现在真的在努力强调我们当时做的也有问题。不是所有的东西都很闪亮、一切都很好、更不是我们所有的团队都非常出色。” 

----Anders Ivarsson, co-author of the Spotify whitepaper

Spotify的敏捷部落制在Spotify真的很成功么？

在创业文化的魅力中，很少有比一个小团队的速度和敏捷更令人向往的了。随着公司的发展，保持这种感觉是一个挑战。2012年，Spotify分享了自己的工作方式，并表示自己已经解决了这个问题。

2017年，当我在斯德哥尔摩总部面试产品管理职位时，我很高兴看到Spotify模式的实际应用。然而，在第一次面试前，招聘人员让我大吃一惊。她告诫我不要指望Spotify是一个敏捷的乌托邦。我加入了这家公司，在过去18个月里，公司规模扩大了两倍，达到3000人。我认识到，著名的Squad（小分队）模式只是一种理想，从来没有完全实施过。我目睹了公司领导逐渐过渡到更传统的管理结构后而产生的组织混乱。

当我问Spotify同事为什么不删除或更新Spotify模型的内容以反映现实时，我从来没有得到一个好的答案。许多人讽刺地说这样对公司招聘很有帮助。我不再在Spotify工作，所以我分享我的经验来澄清事实。Spotify 的Squad（小分队）模式让Spotify失败了，它也会让你的公司失败。

回顾：Spotify的敏捷部落制

关于Spotify敏捷部落制的介绍，你可以在不到30分钟内阅读和观看原始参考文献。下面是一个简短的总结： 

• Spotify的团队之所以称之为Squad小分队，是因为它听起来更酷（不是开玩笑）。一队人组成了一个叫部落的部落。每个团队的目的是都成为一个自主的小型初创公司，由一名产品经理担任某个功能领域的“mini-CEO”。这些团队拥有一系列专业的设计师和软件工程师。其目的是一个团队应该拥有所有必要的技能，而不需要依赖另一个团队来获得成功。 
• 产品经理有一个传统的组织结构。每个团队的产品经理向他们部门的产品总监（称为“部落领导”）汇报。设计师也是如此。然而，软件工程师在团队以为的范围管理。

• “Chapter leads”（分会领导者）管理软件工程师，专门从事部门内特定类型的软件开发。例如，部门内所有团队中从事后端API工作的所有软件工程师将有一名经理，部门中所有Android移动工程师将有一名不同的经理。其目的是允许工程师在部门内的团队之间流动，以最好地满足业务需求，而不必更换经理。Spotify用一个特殊的名字“分会”来代表长期存在的矩阵结构，但是并不奏效。

部落制为什么不奏效

以下几个原因：

• 1）矩阵管理解决了错误的问题
• 2）对团队自治过度迷恋
• 3）团队协作的能力是需要建设的，不能假定默认具备
• 4）创造的Spotify部落制神话让其难以改变

下面逐一详解。

3.1 矩阵管理解决了错误的问题

“全栈”敏捷团队运作良好，但软件工程师的矩阵管理带来的问题比本来要解决的问题还要多。

Spotify的团队存在时间非常长久。原来设想的，工程师调到另一个团队时不必更换经理，但实际证明这并没有体现出多大收益。在这种模式下，除了管理员工的职业发展之外，工程经理几乎不肩负什么责任，他们帮助人际交往技能发展的能力也是有限的。一个工程经理也不能充分参与日常事务，因此无法客观地评估团队内部的冲突。

由于没有一个单独的工程经理负责团队中的工程师，产品经理缺少一个与他们自己所承担的“mini-CEO”角色相当的对等者，即“mini-CTO”。没有一个人对工程团队的交付负责，也没有人能够在同等的责任水平上协商工作的优先次序。

当工程团队内部出现分歧时，产品经理需要与团队中的所有工程师协商。如果工程师们不能达成一致意见，由于团队中有各种工程专业的人员，产品经理需要升级到尽可能多的工程经理那里。一个拥有后端、Web应用和移动应用工程师的团队至少需要3名工程经理参与进来决策。如果这些工程经理不能达成共识，那么一个团队的问题将不得不上报给部门的工程总监。 

“Charpter（分会)领导者是帮助个人成长的仆人领袖。他们并不真正与任何团队合作。所有团队都直接报告给他们。他们并没有真正的责任。他们没有承担责任。很容易将产品所有者视为团队的经理。”

---Joakim Sundén, agile coach at Spotify 

从Spotify的错误中吸取教训：

• 一个包括产品、设计、工程师的团队通常包含的工程师数量比设计师或产品经理更多。为团队中的工程师设置一个单一的工程经理，可以为团队内部的冲突创建一个责任制的升级路径。
• 产品经理应该有一个对等的类似于工程经理负责工程部分。产品经理应该对工作的优先次序负责。工程经理应对工程师的执行负责，包括能够与产品经理协商交付速度和产品质量的之间权衡。

3.2 对团队自治过度迷恋

当一个公司很小的时候，团队必须做大量的工作来交付，并且必须频繁地轮岗。随着公司从初创企业规模扩大，跨团队的重复职能转移到旨在通过减少重复来提高组织效率的部门。随着团队的增多，团队主动轮岗的机会减少。这两个变化都允许团队更深入、更长远地思考他们的工作范围。在这种情况下，不能保证更快的迭代交付，因为，一个团队放弃的每一项职责都会成为一种新的跨团队依赖。

Spotify没有为跨团队协作定义通用的流程。允许每个团队都用自己独特的工作方式，意味着每个团队在合作时都采用自己独特的参与方式。整个组织的生产力因而受到损伤。

Spotify模型是在Spotify还是一家小得多的公司时被记录下来的。据co-author of the Spotify whitepaper Anders Ivarsson说，Spotify模型本应该是一部多部连续剧。自治是第一个切入点，但关于协调和责任的部分从未完成。

从Spotify的错误中吸取教训：

• 自治需要一定的一致性。公司的优先事项必须由领导层来确定。自主并不意味着团队可以随心所欲。必须为团队协作定义跨流程。自治并不意味着让团队自行组织每个问题。
• 如何衡量成功必须由领导层来定义，这样人们才能有效地协商跨团队的依赖性优先级。
• 自治需要问责制。产品经理对价值负责。团队负责交付“完成”增量。成熟的团队可以用他们表达业务价值、风险、学习和下一步最佳行动的能力来证明他们的独立性。

“如果要我改变一件事，我会说我们当时不应该把太多精力放在自主性上。每次都有一个新的团队的时候，他们必须重新造轮子来设计他们应该如何工作。也许我们应该有一个“最小可行的敏捷方法”。团队从这个最小方法开始。可以自由选择退出，但团队不应该总是选择加入。” 

-----Joakim Sundén，Spotify敏捷教练

“Henrik Kniberg曾经谈到过我们在大型项目上不太擅长，但现在我们对于大型项目上仍然不擅长。如果每个团队的工作方式不一致，人们到其他团队工作会感觉更加困难。如果员工内部流动比较困难，各个团队的工作方式就更有可能不一致。直到突然之间，员工感觉到不再为一家公司工作了。而是在各种怪异的亚文化环境中工作。” 

-------Jason Yip, agile coach at Spotify 2015年。

3.3 团队协作的能力是需要建设的，不能假定默认具备

虽然Spotify给团队控制自己工作方式的自由，但许多员工对敏捷实践没有基本的了解。这导致团队在迭代过程盲目地探索能够帮助他们改进交付的工作方式。人们缺乏一种共同的语言来有效地讨论流程问题、如何解决问题、以及和评估工作的绩效成果。Spotify不是很敏捷。只是它不是瀑布。

“敏捷教练”是Spotify的内部顾问，负责为团队教授和建议流程改进。虽然出发点很好，但没有足够的教练来帮助每个团队。教练在团队中的参与时间很短，不足以跨越项目整个生命周期以帮助团队评估绩效成果。更何况，教练并不对结果负责。

从Spotify的错误中吸取教训：

• 协作是一种需要知识和实践的技能。管理者不应该假设人们已经对敏捷实践有了理解。
• 当一个公司发展到足够大的时候，团队需要专门的支持角色来指导团队内部的计划和组织团队之间的协作。大项目经理（Program Manager）可以对计划过程负责。专职的大项目经理（Program Manager)对团队的支持方式，类似于专职的产品经理和专职的工程经理如何发挥各自能力来支持团队的方式。

3.4 创造的Spotify部落制神话让其难以改变

当敏捷和scrum引入了燃尽图、sprint等一堆新概念时，它之所以这样做是因为它需要名称的新概念。Spotify引入了使命、部落（Tribe)、小分队（Squad)、公会（Guild）和行会(Charter）等概念来描述其工作方式。它给人一种错觉，它创造了一些值得学习不寻常的概念。然而，如果我们从这些概念中去掉不必要的酷炫的同义词，Spotify模型的本质就浮出水面：一个跨职能团队的集合，这些团队具有太多的自主权和糟糕的管理结构。别上当了。如果Spotify用这些术语的原名来定义这些想法，或许当Spotify模型失败时，它可以更公平地评估。

从Spotify的错误中吸取教训：

• 大多数企业只能维持少数几个领域的创新。内部流程很少是使公司在市场上与众不同的主要创新领域。研究过去可以让企业选择更好的创新领域。 
• 优化理解。为了提高组织的生产力，每个人必须学习的新理念应该根据其价值进行评估。与Spotify模型里那些炫酷的同义词概念相比，业务单位、部门、团队和经理更有效地沟通组织结构的角色和职责。

参考资料

Spotify模型介绍：https://blog.crisp.se/wp-ontent/uploads/2012/11/SpotifyScaling.pdf

IDCF第5期DevOps案例深度研究回放视频已上线，识别下图二维码即可进入视频合集。

【福利】原价199元 2人成团可享拼团优惠~