有效的软件团队对于任何组织持续不断地创造价值至关重要。但是，如何根据您的特定目标，文化和需求建立最佳的团队组织呢？
2012年，音乐流媒体服务Spotify的人们发表了一篇著名的文章，描述了他们如何组织团队使用半自治小队模型，该模型有助于强调快速的变更流程，因为每个小队都有工程师，测试人员，业务分析师，运维人员等各种技能人才，使得一个小队拥有Spotify产品的一部分，并从概念中汲取灵感通过编码到生产。
一组团队被组织成一个叫做部落的部门。每个团队都打算成为一个自主的小型初创企业，产品经理将担任功能区域的小型CEO。这些团队的设计师和软件工程师具有一系列专业知识。目的是使一个团队应该拥有一切必要的技能，而不必依赖另一个团队来获得成功。
产品经理具有传统的管理结构。团队的产品经理向其部门的产品总监（“部落负责人”）报告。设计师也一样。但是，软件工程师是在团队结构之外进行管理的。
“Chapter章节负责人”管理的软件工程师专门负责整个部门的特定类型的软件开发。例如，该部门内所有团队的所有使用后端API的软件工程师都将拥有一名经理，而该部门中的所有Android移动工程师将拥有一名不同的经理。目的是允许工程师在部门内的团队之间移动，以最好地满足业务需求，而无需更换经理。
许多组织都试图复制Spotify模型，但结果往往好坏参半。
团队拓扑是一种实用的，逐步的，自适应的模型，用于组织设计和团队交互，它基于四种基本的团队类型和三种团队交互模式。该模型将团队视为交付的基本手段，团队结构和沟通途径可以随着技术和组织的成熟而发展。
Spotify尝试了一个长期存在的矩阵团队结构，只是选择了一个不同的单词”Spotify模型“。“全栈式”敏捷团队运作良好，但是软件工程师的矩阵管理引入的问题多于解决的问题。
- Spotify的团队寿命很长。转移到另一个团队时不必更换经理的好处是有限的。
- 在这种模式下，工程经理除了所管理人员的职业发展外，几乎没有其他责任。即使那样，他们帮助人际交往能力发展的能力仍然是有限的。工程经理不会在团队中管理足够多的其他人，也不会在日常工作中投入足够的精力来独立评估团队内部的冲突。
由于没有一个工程经理负责团队中的工程师，因此产品经理缺乏同等的同事，没有一个人对工程团队的交付负责，也没有人可以以同等的责任级别商议工作的优先级。
当工程团队内部出现分歧时，产品经理需要与团队中的所有工程师进行谈判。如果工程师无法达成共识，则产品经理需要升级为与团队中具有工程专业知识的工程师一样多的工程经理。一个由后端，Web应用程序和移动应用程序工程师组成的团队将至少拥有3名工程经理，他们可能需要参与其中。如果这些工程经理无法达成共识，那么一个团队的问题就必须升级到部门的工程主管。
Spotify模型的合著者和在Spotify工作的许多敏捷教练一直在告诉人们多年来不要复制它。不幸的是，真理并没有像人们想要相信的想法那样迅速或广泛地传播。 |
“当人们看到我们所做的事情并认为这是他们可以复制和实施的框架时，这让我感到担忧。……我们现在真的在努力强调我们也有问题。并不是所有的东西都“闪闪发光，一切都运转良好，我们所有的小队都很棒”。” |