Spotify模式不等于扩展敏捷

There Is No Spotify Model for Scaling Agile

 

Source: https://vitalitychicago.com/blog/there-is-no-spotify-model-for-scaling-agile/

扩展敏捷中没有Spotify模式

最近一客户告诉我他们将采用Spotify模式。一开始听上去很不错。Spotify发表了很多有关于他们组成如何成长和转变为敏捷的优秀文章和视频。这时我突然意识到这完全是个错误。

Spotify模式不是一种敏捷方法

因此，大伙儿都爱上了Spotify的模式，以及魅力超凡的Henrik Kniberg，他是Spotify早期的敏捷教练之一，为了解Spotify如何使用敏捷提供了一扇窗口。然后他们开始把Spotify模式看作是一种敏捷方法或框架。

这真是大错特错。

在Kniberg自已的描述中，Spotify并不是一种框架或模型。

Spotify（以及Kniberg）发布了大量有关怎么组织小队（squads）和部落（tribes）的资料信息，以及他们使用各种各样的技术实践和组织文化。如果你不太了解，可以查目的地Kniberg发布在Crisp上的博客，以及很多人提到的Spotify工程文化第1部和第2部分的热门视频。

尽管博客和视频提供了大量关于Spotify如何组织和完成工作的信息，但这并不能使Spotify成为一个敏捷方法的人。（公平地说，我是Kniberg在Spotify所做的工作的超级粉丝，你可以在我的相关文章中读到我最喜欢的来自Kniberg和Spotify的敏捷插图。）

Spotify也不是扩展模式

更糟糕的是，人们开始将Spotify视为一种扩大规模的途径。尽管Spotify确实扩大了数百个敏捷团队的规模，但这并不能使他们的方法成为一个规模模型。

但是其他人会不同意我的观点。下面的图表来自最新的CollabNet VersionOne敏捷年度状态报告。由图表显示来看，有5%的使用扩展敏捷的人声称在使用“Spotify”模式。那已经不算少了啊！与前几年相比，这是一个巨大的增长，而前几年没有人提到Spotify模式是一种规模化的方法。

Spotify的模式并不是一个敏捷扩展模式。甚至与此无关。Henrik Kniberg甚至说过，与其扩展敏捷，不如缩减你的组织结构。

为什么会有那么多人把Spotify看成是一种规模化的方法呢?仅仅是小队和部落的可爱图表吗?

模仿Spotify敏捷模式可以偷懒

许多组织只是简单地使用下面组织结构图来重新标记或重命名他们现有的团队。从不改变任何东西。这是一种相当偷懒的行为，也不太可能带来变革。

你看，模仿别人与采用或敏捷转换不一样。听说过“货物崇拜敏捷（Cargo Cult Agile）”吗?人们在不知道别人在做什么或为什么的情况下模仿别人的行为。

问题是这样的：这个组织结构图距离现在有近10年的时间了，谁知道Spotify现在实际上在做什么呢？

一个更大的问题是：随着时间的推移，Spotify的模式也在不断发展，这是Spotify不断尝试的结果。你不能把Spotify所做的部分或部分提升，然后指望它在你的公司发挥作用。你需要运行自己的实验，了解哪些是有效的，并不断尝试，直到优化你的组织。

一个更更大的问题：团队标签或名称并不是最重要的，取什么名字都无关紧要。不可能因为重新命名了团队名字，就能获得“Spotify 模式”。如果这样也行， 我们都可以命名小队或部落。

Spotify之所以成为一个鼓舞人心且经常被模仿的公司，是因为它的行为和原则支持着这个组织。你可以通过建立一种与敏捷原则一致的文化来获得Spotify的模式，这种文化支持安全、实验、学习、信任和工作的乐趣。

Kniberg自己说敏捷原则比具体的实践更重要。大多数实施所谓的Spotify模型的人要么不知道，不理解，要么不关心12条敏捷原则。

Spotify热并不是一种新概念

我绝不是第一个注意到这种对Spotify的迷恋或对任何一种模式的误用的人。Kniberg自己在2015年的一篇博客中提到了这一点。我觉得人们只把它当作是耳旁风。

这种想法让我想起了费德里克•赫茨伯格(Federick Herzberg) 1968年发表的一篇文章的标题:“再问一次你如何激励员工”（One More Time How Do You Motivate Employees）。从文章的标题可以清楚地看出，赫茨伯格以前已经给出了答案;如果你想激励员工，就给他们富有挑战性的工作和更多的责任。这是如何激励员工的正确答案，但是很难，所以人们不断地问这个问题，希望找到一个更容易的答案。

因此，那些想“采用Spotify模式”的公司，其实只是在寻找一种快速解决方案或灵丹妙药。他们并不想做太多改变，他们只是想调整一些东西。

我们能在Spotify模式中学到什么？

我认为如果你没有亲身体验过Spotify，你是无法真正理解它的。你看，我们大多数人都在按照自己的模式和信念体系工作，我们很难想象它在Spotify是如何工作的。我们可能会掩盖所有让Spotify文化值得效仿的东西。或者我们在Spotify上发布我们相信的东西，尽管我们没有看到它们存在的证据。像小队和部落这样看得见的东西，并不像最看不见的文化元素那么重要。而这种文化正是“Spotify模式”的精髓所在。

因此，让我们花点时间来对基于公开信息的文化进行反向工程和解码。为了做到这一点，我使用了各种视频和文章，并重点参考了Henrik Kniberg 2014年的视频。请注意，这是至少5年的历史，可能描述的方法是Spotify现在已经不再使用的。

通过阅读文章和视频，你可以了解到Spotify文化的以下关键元素。当你回顾这个列表的时候，做一个内部检查。你今天要这么做吗?这些方法会在你的公司奏效吗?实现这些目标需要什么?这可能是对你是否接近“Spotify模式”的最好检验。

关于敏捷性的“Spotify模式”，你可以推测出25个文化元素

1. “不要夸大敏捷，贬低你的组织。” Henrik以这句话开头，这句话与5%声称使用Spotify实现敏捷扩展的人产生了直接的冲突。这不是要改变敏捷来适应您的公司，而是要改变您的组织来实现业务敏捷性。一个问题：在你扩展敏捷之前，你有没有考虑过对你的组织进行“除垢”?
2. 你的公司不是Spotify。Spotify诞生敏捷是在2006年，还不到20年。Spotify规模还很小，大概只有1500人。问：你的公司是新成立的公司吗？你有成千上万的员工和以某种方式做事的丰富成功案例吗？你们公司是否有一层又一层的规则和管理机构来确保正确的做事方式，以及大量的检查和制衡？
3. Spotify有自已的使命。Spotify宣称的使命是颠覆音乐行业。问:你的公司有一个令人信服的目标来团结和激励员工吗?
4. 小队（Squad）相当于一个混合的团队（Scrum Team）。就像Scrum Team一样，Squad是一个跨部门的自我组织，并且负责完整项目的端到端交付。问：你的“小队”是自组织的吗?他们有能力进行端到端交付吗?或者你有移交给其他团队或部门的任务吗?
5. 各小队都是自发组织。自主权是公司的关键。它不仅包括下一步要做什么或如何完成他们的工作。自治有助于扩展，因为它们不需要那么多的核心功能。自主是有趣和激励的。问:你创建的小队是自主的吗?
6. 积极性是生产力的本质。Kniberg谈到了员工积极性对于解决不可避免的环境问题有多么重要(参见Richard Sheridan的《工作的快乐》)。积极性对生产力的影响比其他任何因素都要大。Kniberg有一个简单的公式表明生产力=努力X能力X环境X动机^2。问：贵公司是否注重提高每位员工的积极性?
7. 平衡团队结盟和自治。Spotify努力在团队结盟(中心方向)和自治(团队自组织)之间取得平衡。管理者描绘出一幅蓝图，却不告诉人们如何解决。这可能是大多数组织最大的症结之一 - 管理者直接参与告诉人们如何解决问题。问：谁在组织中做决策?团队成员和管理者之间的权力平衡是什么?
8. 塑造环境。物理空间支持非正式的协作和协调。在Spotify各个小队坐在一起工作。部落之间坐得很近，而且有足够的空间进行非正式会议，而不必安排会议室。问：你的公司是否努力让人们在同一个团队或部落工作?您的物理空间是否支持非正式会议，而无需安排会议室?
9. 小队和部落没有特别意义。Henrik说，他不确定为什么他们会使用像小队和部落这样奇怪的词。标签本身没有任何意义。每个部落都是一个跨职能的团队，垂直支持以便交付。问：你有没有在没有做任何改变的情况下把你现在的团队（team）变成小队(squad)
10. 行会（Guilds）是交叉的专业领域。行会相当于实践的社区。他们不是职能部门，而是基于特定专业知识的志愿者领导的社区。问：您的行会社区是基于专业知识的，还是围绕着关键经理或现有的职能部门组织的?
11. 强调面对面的交流。这就是部落、小队和行会结构的目的。它们是基于协调和协作的需要而形成的。部落和小队被组织起来，这样他们就可以坐在一起。问：你的组织是否优先考虑面对面的交流?
12. 令人厌烦的发布。过长的发布周期是可怕且有风险的。频繁发布不会那么恐怖、减少风险并且更容易。它会变成例行公事，并且会很无聊。问：你多久发布一次产品?你的发布是可怕的还是无聊的?
13. 解耦各个发布版和持续集成（CI）/持继交付（CD）的周期。Spotify专注于改变架构，以解耦依赖关系，使发布更容易。减少了依赖关系，团队可以彼此独立地发布到产品中。Spotify还在持续交付上投入了大量资金，以便在几分钟内自动生成代码，而不是几天或几周。问：从更改后的代码行到实际生产中的代码平均需要多长时间?你测量和跟踪它吗?
14. 信任和自助服务模型。Spotify赋予和信任人们权力，因此在可能的情况下，团队会做出包含风险的决策。Kniberg举例说明了环形交叉口和典型的红绿灯在控制上的不同。在可能的情况下，Spotify信任和支持每个人，而不是试图控制他们，因为他们相信大多数人都在做对组织最有利的事情。问：你对员工和团队的信任程度如何? 他们是否被赋予了进行自助服务的机会(例如，设置新环境)，或者由于等待决策/批准而导致的检查和平衡以及延迟会减慢他们的速度?
15. 透明度和短反馈循环。透明度是混合团队（Scrum）的支柱之一，也是所有敏捷的基本要素。透明度也是自组织的推动者。类似地，短反馈循环为检查和调整提供了机会，并确保团队正在构建最有价值的特性。问：你的迭代周期（sprints）时间是多长？团队构建某个特性与真正的客户使用或提供反馈之间的时间间隔是什么?
16. 管理者是仆人型领导者。Spotify认为管理者是服务型领导者，专注于满足团队的最高需求。他们认为，管理者最好问团队如何才能提供帮助，而不是问他们在做什么或什么时候会完成。问：你的经理对你的团队的态度是什么? 他们是为团队服务，还是认为团队为他们服务?
17. 精益创业。Spotify的口头禅似乎是基于Eric Ries和精益创业的方法（the Lean Startup approach）去思考、构建、调整、发布。团队建立一个假设，然后进行实验和A /B测试，并测量结果。他们努力获得大量的反馈，调整他们的执行，并使价值最大化。他们知道最大化价值和不只是输出的区别(例如，完成更多的用户层)。问：你准备进行小的实验了吗?或者你的产品/项目是一长串需求的结果吗?
18. Spotify黑客周。Spotify每年举办两次“黑客周”(hack week)活动，让每个人工作一周，做自己想做的事情。这种方法释放了创造力，提高了跨组织合作，他们在周五举办了一个聚会来庆祝。问：你的公司会允许职员花一周的时间在黑客马拉松做任何他们想做的任何事情吗?你认为你的领导在那一周会要求哪些控制措施(例如分配的工作，时间报告，必须显示结果，等等)。
19. 尝试-友好文化。更多由数据驱动的决策，而不是由收入最高的人做出的决策。鼓励团队提出假设并进行实验。团队建立“保留列表”，其中可能包括:项目回顾（Retros）, 每日站立会，谷歌驱动器，GIT和协会非正式会议（Guild UnConferences）。他们还有一个“转储列表”:时间报告、交接、单独的测试团队或测试阶段、任务评估、无用的会议。问：你是否允许团队自由地改变他们的工作方式? 在上面的转储列表中，你要求你的团队做什么?为什么?
20. 健康的文化延续中断的过程。过程会左右中断，但是一个健康的文化会让人们解决这些问题。问：你的过程有多重?是否允许团队更改流程，或者流程是否由敏捷确认中心（Central Agile CoE）或标准组指定?
21. 在混乱和官僚中寻找平衡。就像平衡自主和结盟，Spotify正在混乱和官僚主义之间寻求平衡。在这两者中，Kniberg认为解决混乱比解决官僚主义更容易。类似于Alistair Cockburn的“勉强足够”过程指导，Spotify提出了“最小可行官僚主义”（minimum viable bureaucracy）的概念，即MVB。这是一个组织所能拥有的、没有混乱的最小数量的官僚机构。问：贵公司的官僚主义程度如何? 你的经理是否积极地减少或消除开销，以便团队能够专注于提高效率?
22. 很棒的团队定义。Spotify鼓励团队讨论并决定什么能让他们变得很棒。毕竟，如果没有卓越的愿景，你可能无法实现目标。Spotify团队使用定期的团队健康检查，并随着时间的推移跟踪改进情况。问：你的团队有很棒的定义吗?你是追寻团队健康，并不断追求进步?
23. 文化敲动进程。正如我们在这篇文章中所概述的，你所拥有的明显和可观察到的过程远没有文化那么重要，文化可能是几乎不可见的。文化是被奖励的行为或者成功的行为。文化不是由管理者和领导者授权。领导者需要模仿他们希望在组织中看到的行为。问：在你的组织中，哪些行为会得到奖励?哪些行为会成为标榜？
24. 员工满意度。在Spotify的工程文化视频中，Kniberg讲了一个有趣的故事，是关于一封来自人事运营主管的电子邮件的最近员工满意度调查结果。这位主管声称91%的员工喜欢在Spotify工作，他说这“当然不令人满意”。问：你的领导会问人们是否喜欢在你的公司工作吗? 您认为贵公司的领导层和人力资源部门可接受的满意度是多少?
25. 失败是成功之母。如何对待错误可能是反映你的文化的最佳指标之一。当你推动创新时，错误是意料之中的。惩罚错误导致人们隐藏他们的错误。Daniel EK(Spotify创始人)说:“ 我们的目标是比任何人都更快地犯错误”。Spotify专注于从失败中恢复而不是避免失败。学习就是犯错误并从中学习。以下Kniberg画的图很好地说明了这一点: 

Kniberg还提到了一些与故障恢复相关的先进概念，这些概念在DevOps手册中也有详细的解释，包括：

1. 笑谈失败文化（Failure friendly culture）
2. 失败墙（Fail Wall）
3. 事后检验，持续改进
4. 巧妙的回顾vs.责备
5. 有限的半径-限制任何一次故障对整个系统的影响。

问：你的组织如何对待错误? 人们会受到惩罚吗?还是会把错误视为学习和提高的机会? 你会允许犯小错误吗?

Spotify不是敏捷的天堂

我希望你现在已经看到Spotify的敏捷不仅仅是小队和部落。事实上，Spotify的模式就是文化，你不需要团队和部落就可以做到。但是你不能仅仅依靠小队和部落来获得所谓的Spotify模式。

“在这样的文章或谈话中，你可能会觉得Spotify是某种敏捷的天堂，一切都很正常，但这不是真的。” – Henrik Kniberg

采取行动

您可以使用上面提到的25个元素作为一个快速清单。如果你相信自己已经在使用Spotify的模式，这一点尤为重要。

在你的组织中，25种文化元素你已经实现了多少? 需要做哪些改变来增加你可以断言的“是”的数量?