虽然我在 Spotify 工作了大约 8 年，但我并不熟悉每个领域的运作方式，而且我有自己的偏见、偏好等。而且情况会发生变化
敏捷 > Scrum
Spotify 早期主要采用 Scrum（在我的时间之前，所以我无法证实这一点）但转向了更通用的敏捷方法。据我所知，不再需要标准的 Scrum 实践，也不再有任何 Scrum Master。
这一原则反映了对自治团队责任的普遍期望。这仍然成立，我同意。
话虽如此，我有时会发现 Squads 为自己选择的东西不是最理想的，而且比我自己实际在 Squad 时所希望的要慢。
我认为最初，有一个有效的假设，即小队有足够的敏捷背景来做出很好的决定。随着 Spotify 以及整个行业的发展，越来越多的人对敏捷的理解肤浅或扭曲。
敏捷 > Scrum？是的，但不要假设每个人都对“敏捷”的含义有相同的理解。
自主小队
Spotify 的“Squads”不是“团队”的同义词，而是一个跨学科、自治的产品开发团队。Marty Cagan 将其称为授权产品团队。
每个小队都有一个任务，但负责决定建造什么、如何建造以及如何共同完成任务。
我在一些小队中看到的常见错误：
- 将自主权视为一种好处“我们可以做任何我们想做的事！” 而不是作为一种责任，“我们既被授权也被期望去做完成任务所必需的事情”；
- 缺少小队责任包括在必要时与其他小队协调或协作；
- 小队之间的交叉授粉不足导致不必要的变化和重新学习；
- 缺少小队任务如何适应更广泛战略的背景——这可能导致小队持续时间超过适当时间
面对这些问题时，新聘用的领导者可能会建议“自主权过多”，而实际的正确答案是“一致的自主权”（见下文）。
我还想说，团队可以根据任务的不同而明显不同。团队拓扑结构涵盖了其中的一些内容（流线型、使能型、复杂的子系统、平台型），并根据产品的生命周期阶段（创新与差异化与商品）有一些额外的变化。
自主的小队？是的，但自主权应该被视为一种责任，而不是一种好处，而且应该有意识地进行交叉授粉，并且一致的自主权仍然很重要。
为自主小队优化的办公室
Spotify现在提倡 "随时随地工作 "和 "分布式优先"。因此，尽管办公室在名义上仍然是为自主小队而优化的，但很多人都不在办公室工作了。
为自主小队优化的办公室？当然，但它可能正在转向分布式优先。
对齐调整使自主性得以实现
我们的目标是 "松散的耦合，但紧密结合的小队"。
"我们的一致性越强，我们就能负担得起更多的自主权"。
这个概念来自于《行动的艺术》，它将 "任务指令 "应用于商业环境。
对齐本身并不足以促成自主权。在《扭转乾坤》（Turn the Ship Around）一书中，L. David Marquet指出了允许 "给予控制权"（又称实现自主权）的两个支柱：能力和明确性（又称一致性）。
一致性使自主性成为可能？是的，至少从19世纪的克劳塞维茨开始，能力也是需要的。
交叉授粉 > 标准化
我认为随着Spotify的发展，交叉授粉变得更加困难。
虽然我认为交叉授粉仍然很有价值，但现在可能更强调Spotify版本的 "铺路 "模式，称为黄金之路。黄金之路 "有培训、支持、工具等，但如果有意义并愿意自己承担开销，你就可以做出不同的决定。如果这个决定没有意义，可能会有人来检查。
还有一个全公司的技术雷达，提供更广泛的指导。
交叉授粉>标准化？更多的是交叉授粉和黄金路径以及技术雷达>强加标准化。
内部开源模式
虽然服务应该有明确的小队所有者，但如果拥有的小队太忙，请求的小队可以自己进行修改并提交审查。
随着系统和领域数量的增加，Squad有不同的风格，等等，这变得更加困难。
分享>拥有 "和 "做>等待 "的一般想法仍然是好的，但这再次强调了交叉感染的重要性。也可能有一些新的团队，典型的是来自收购的团队，他们的地域性更强，这需要解决。
内部开放源码模式？是的，但更多的跨领域的交叉授粉是必要的，以有效地扩展。
人 > *
人 > *是指一种相互尊重的文化。我们都在一起，等等。这一点一般都能保持，但随着公司的发展，新的收购等，已经变得更难维持。甄选、入职、深思熟虑的文化期望，对于维持相互尊重的文化是必要的。
人 > *？是的，但随着公司的发展，它变得越来越难，而且不能只是假设是真实的，而没有刻意的行动来维持它。
最近的裁员也会使这种文化假设受到威胁。
注重激励
这里使用的例子是人员运营主管对91%的员工满意度不满意。
"人员运营 "已经不存在了，它只是 "人力资源"。
对改进的关注仍然很重要，但我不确定我是否会称其为 "关注激励 "本身。
注重激励？我建议用 "专注于改进 "来代替。
结构。小队、分会、部落、公会
轻量级的矩阵结构，每个人都在一个小队（交付轴）和一个分会（学科轴）中，向一个分会领导（以学科为重点的经理）报告。章节领导的报告模式旨在允许人们在不更换经理的情况下更换小队。小队被分组为部落。也有称为公会的实践社区。有些公会是以纪律为导向的，有些则是以爱好为导向的公会。现实比这个描述更混乱。
章节领导已经消失了。头衔已经变成了 "工程经理"（EM），EM大多与一个小队有关。现实还是比这个描述要混乱。
矩阵结构的主要目标是在相互竞争的目标之间产生必要的冲突（在这种情况下，交付与发展学科能力）。这种必要的冲突并没有因为某个角色被重新命名，报告关系被调整就变得不必要。
曾经有人努力停止使用 "部落 "一词，因为美国人将 "部落 "与北美的土著人口联系在一起。我在那里时，没有找到明确的替代方案。
随着Spotify的壮大，其他结构也出现了。任务是部落的集合。业务单位包括任务和业务团队。产品领域是原始部落，但当一个更大的部落有一个连贯的战略而不是分成多个部落更有意义时，也会出现。
小队、分会、部落、公会？章节可能会也可能不会再明确存在。有些人不喜欢 "部落 "这个词。部落之外还有其他结构。产品领域、任务、业务单位。
社区 > 结构
组织结构图是一种幻觉。强大的社区可以弥补非正式的、不稳定的结构。
这是真的，而且随着组织规模的扩大，维持强大的社区也更加困难。
社区>结构？是的，但随着组织的发展，这一点更难做到。精心设计的（和不断重新设计的）结构会有帮助。
让发布变得容易
痛苦的发布导致更少的、更大的发布，而更少的、更大的发布则更加痛苦，等等，这种恶性循环不是你想要的，而是更容易的发布的良性循环，使更多的、更小的发布成为可能，而更小的发布随着实践和工具的使用变得更加容易，从而导致更多的、更小的发布，等等。
尽可能地解耦
设计技术架构以实现解耦发布。
随着事情的扩大，"尽可能地解耦 "会导致重复的能力和相同数据的重复存储。当然，有时解耦值得重复的开销，但并非总是如此。
自助服务模式
有不同风味的Squads（如功能、客户应用容器、基础设施等）以自我服务的方式行事，以避免交接。
这类似于团队拓扑中描述的内容。
尽管随着规模的扩大，自助服务模式的驱动力总体上是正确的，但它要复杂得多。有时，我发现团队会过早地假装成自助服务，而没有花费必要的初始合作努力来设计真正有效的自助服务界面（又称征服和分化）。
自助服务模式？是的，但首先需要协作来有效地设计自助服务。
信任 > 控制
"大规模的敏捷需要大规模的信任。这意味着没有政治。它也意味着没有恐惧"。
我同意大规模的敏捷需要大规模的信任。这本质上是一种能力，既要有相互尊重（如《人>中提到的），又要有适当的能力水平。我不同意这意味着没有政治。事实上，我认为假装没有政治通常会导致更少的信任。