Spotify把每个团队称为小组，类似于一个Scrum团队（敏捷团队）。小组类似一个微型的初创公司，包含设计、研发、测试和配置管理服务全部所需的技能和工具。2012年10月，科内博和爱瓦森发表了论文，《扩展性敏捷@ Spotify，部落、小组、章节和公会》（Scaling Agile@ Spotify with Tribes, Squads, Chapters and Guilds）。“不论什么事都有不好的一面，完全自主不好的一面是亏损的规模经济。A小组负责测试的工程师正在想办法解决B小组的测试人员上周刚解决了的问题。如果所有的测试人员可以跨越小组和部落的边界聚集在一起，那么他们可以互相分享知识和研发对所有人都有益的工具。”他们继续探讨这个问题，“如果每个团队都是完全独立的，不与其他队员沟通，那么为什么要成立公司？”
正是这些原因，Spotify开始用章节和公会的办法。
一个章节就是一小部分人，他们有相似的技能。每个章节都会定期开会讨论其专业知识和遇到的挑战。章节的领导作为一个业务线经理以及一个小组的成员，参与到日常工作中。一个公会是一个更加有机的和更加广泛的兴趣社区，一组想要分享知识、工具、代码和实践的人。章节存在于当地的部落中（小组在部落中工作），而公会通常跨越整个组织。利用章节和公会，Spotify可以保证在整个机构共享架构标准、开发标准、图书馆、甚至是技术。章节和公会负责任协调和促进讨论、实验、并最终做出决策，所制定的标准被所有的团队所遵守。章节和公会成员参与这些过程，负责把知识和决定返回自己的团队，确保团队的同事遵守决定。这种方法在专制的自上而下的方法和民主的自下而上的方法之间取得了很好的平衡。即使如此，对大型组织中的小型和独立的敏捷团队而言，在设计服务和产品的过程中，这也并不是唯一的方式。
在李希特的文章，《用独立的团队来扩展小的公司：游戏公司Wooga是如何运作的》，2013年9月8日发表在在“下一代网络”（http://thenextweb.com/）上，作者概述了他培养独立团队的方法，以及向Spotify挑战的想法。李希特是成立于2009年的社交游戏公司Wooga的工程负责人。Wooga已经从第一年的大约20名员工，成长到2013年超过250名员工。李希特说道，“在公司的早期，大家紧密地结合在一起，不必因为等待审批而放缓。通常随着公司的增长，管理层增加，工作就变得不那么有效率了。我们是怎么坚持这种文化的？我的答案是：一切围绕着独立的游戏团队。”
类似于Spotify和我们的模型敏捷团队，李希特组织了小型的自治、跨部门团队负责独立的游戏。这些团队自己编写和运维游戏本身，不依赖于集中的技术运维团队或框架。“工程师不是被迫共享或复用代码”是李希特对每个团队运作的独立水平的描述。关于社团以外个人的影响，包括公司的创始人，“这完全取决于团队是否想听或无视外界的意见。
然而在Wooga，要利用知识并取得一定的规模经济，团队要积极地分享知识。他们通过每周的工作状态更新、闪电会谈、便餐会和其他的互动来完成这个任务。这种知识共享的优势帮助团队避免重复同样的教训。正如李希特所描述的，“这样我们可以在游戏中尝试新东西，当新东西奏效时，再把知识传播到其他的团队，这个机制很有效。”应当指出的是，团队有共享的结果，如关键绩效指标（KPI），但这些不构成团队间的竞争。
Wooga的方法与Spotify的方法有很大的不同，章节和公会领导人的任务是确保整个团队共享知识和标准。那么哪一个是最好的？这两种方法都是必要的，公司需要评估整个团队需要建立哪些标准，各团队可以自行建立哪些标准。这取决于组织的文化、成熟度和过程。作为一个领导，你觉得哪个方法更好？你是否有一种企业文化的组合，包括有经验的个人为了公司的最佳利益可以独立行事，或者需要更大的监督？对这些问题的回答将引导你在一个特定的时间，为组织找到最佳答案。随着组织的成熟和发展，这种方法也可能需要改变。
敏捷组织中的ARB
如前所述，敏捷团队提供JAD试图实现的跨团队设计。因此，当员工被组织成真正的自治、跨部门团队时，JAD就显得没有必要。下一个问题是，“敏捷组织是否需要ARB？”答案还是“不一定”。许多我们曾经提供过咨询服务的公司尽管有跨部门的团队，但仍然还有ARB。ARB的主要好处是它为团队提供了第三方的观点，因此不会被容易传染的自治团体思维左右。然而，如果我们把ARB放在产品的生命周期中，那么就会影响自主性和敏捷团队产生的市场效益。在迭代后进行ARB审查是一个增加优点和减少缺点的潜在方法。另一个选择是召开ARB每日例会（也许在午餐），讨论需要审查的任何项目。这样，团队就不必花相当长的时间来等待ARB的召开。
在敏捷组织里使用ARB时，主要的目标是确保制订的架构原则得到尊重。这有助于确保团队在技术标准和架构原则上保持一致。ARB的第二个目标就是通过互动来教导工程师和架构师。随着团队规模的快速增长，或收购具有不同标准的新公司的时候，ARB变得越来越重要。最后，ARB有助于评估每个团队成员如何理解和执行标准。评估团队如何实现共同设计，并帮助纠正缺陷。
结论
敏捷团队作为一种小型和自治的组织，可以独立负责服务和产品的架构和设计。在设计方面，如果团队要尽可能灵活，这种自主权就至关重要。JAD可以有效地确保完成跨部门的设计，跨部门的敏捷团队依靠其本身的组成确保这个结果发生。
有时组织面临有限的资源，比如DevOps工程师的人数比其他团队要少。我们建议将每个DevOps工程师分给几个团队共用。理想情况下，团队应该知道和他们配合的人的名字，而不是必须提交请求到队列上。这有助于打破组织架构的壁垒。
当我们与客户讨论敏捷团队的时候，经常有人会提出的问题是，如果团队是完全自主的，如何确保标准可以跨团队共享。一种方法（Spotify采用）涉及跨越敏捷团队的章节和公会来确定并实施这些标准。另一种不同的方法（Wooga采用）是团队很独立而且积极通过各种论坛分享知识。最后，你可以考虑使用ARB来验证架构原则的采用和合规情况，通过定期召开会议来回顾最近发布的设计。
关键点
▲敏捷团队应该自主行动，这意味着他们应该拥有自己的服务和产品设计。
▲ARB和JAD确保跨团队的服务设计。敏捷团队通过自身的构成确保这个结果。
▲当运维资源如DevOps工程师或架构师有限的时候，把他们分配给多个团队。不要恢复取票排队等候DevOps资源池。
▲跨团队共享标准和知识，以实现规模经济仍然可以通过敏捷团队来完成。在这种情况下，可以使用各种方法。为组织选择正确的方法取决于多种因素，包括团队的成熟度、产品的复杂性以及对分布式命令和控制的舒适度。
本文选自架构即未来：现代企业可扩展的Web架构、流程和组织(原书第2版)一书，由马丁·阿伯特、迈克尔·费舍尔著，陈斌翻译。
任何一个持续成长的公司最终都需要解决系统、组织和流程的扩展性问题。本书汇聚了作者从eBay、VISA、Salesforce.com到Apple超过30年的丰富经验， 全面阐释了经过验证的信息技术扩展方法，对所需要掌握的产品和服务的平滑扩展做了详尽的论述，并在第1版的基础上更新了扩展的策略、技术和案例。
针对技术和非技术的决策者，马丁阿伯特和迈克尔费舍尔详尽地介绍了影响扩展性的各个方面，包括架构、过程、组织和技术。通过阅读本书，你可以学习到以*化敏捷性和扩展性来优化组织机构的新策略，以及对云计算（IaaS/PaaS）、NoSQL、DevOps和业务指标等的新见解。而且利用其中的工具和建议，你可以系统化地清除扩展性道路上的障碍，在技术和业务上取得前所未有的成功。
第二版的更新
用现实世界中成功和失败的真实故事，取代第一版中的AllScale虚拟案例
新增了关键话题：敏捷组织的新型结构，把数据中心转移到云端的决策根据，业务指标对系统整体健康的重要性，云计算技术，以及关于NoSQL解决方案的讨论等。
