我们知道经验、技能和关系的多样性，有助于更好地解决问题—架构功能、场景、解决方案、错误修复或提供产品。最好的解决方案来自于包括多个领域代表的团队，他们利用各自不同的观点和经验来解决这个问题。
如果请软件工程师设计一个门，他或她会马上开始思考门的工作原理，铰链如何运作，门把手如何转动，等等。如果请产品经理设计门，他或她可能开始考虑门应达到的效益，其他竞争对手的门都有什么功能，最后一轮用户测试的结果。如果请系统管理员设计门，他或她会开始思考如何确保安全，如果插销或锁出现常见的故障应该如何恢复。当我们把这些不同的观点都集中起来，就可以设计出一个更强大、更具可扩展性以及更高可用性的产品。
关系的多样性用来衡量团队成员的个人或专业关系网络。这对创新很重要，因为几乎所有的项目都会遇到不同的阻碍。关系广泛的团队能够在项目早期更好地识别潜在的障碍或可能遇到的问题，因为他们可以咨询各种各样团队以外的人。当团队确实遇到了障碍，这种多样化的关系使他们的易于发现和取得资源并绕过障碍。
有限的资源
当一个灵活的团队有多样化的技能、广泛的人脉关系以及各种各样的经验借鉴后，团队成员设计、研发、部署和支持高度可靠和可扩展的产品的能力会更强。如果公司不能为每个团队配备一位架构师，或者六个敏捷团队只有两个DevOps工程师会怎么样？
这个问题的不仅出现在资金有限的初创公司，也同样存在于现金充沛的高增长型公司。在第一种情况下，公司无法雇用很多架构师、DevOps工程师和其他想要的专业技术人员。在第二种情况下，公司可能无法如愿吸引和留住许多架构师或DevOps工程师。团队的成长常常是非同步的，先招聘软件开发人员、然后是产品经理、再后是质量保证工程师、DevOps工程师，最后是架构师。填补团队的周期可能花费一年到18个月的时间。没有一家公司会让软件开发人员闲下来等待架构师的加入。但是在这种情况下，团队该怎么做呢？
当面对有限的人员和资源时，团队通常会试图以现有的有限资源来对付。这种方法可能会为公司带来相当大的风险。试想一下没有足够的产品经理的情景。结果可能是仓促编写的用户场景描述和调度很差的项目优先级，结果导致严重的错误。
敏捷团队的第一步是确保他们有必要的资源来完成项目。
一旦关键资源缺失，这个团队就会处于危险之中。争取必要资源的办法是使用看板来直观地显示研发过程中的资源瓶颈，说明需要资源的业务理由。另一种方法是跨团队共享资源。有限的资源，如DevOps工程师，可以在整个团队共享。这些人应该被分配给多个团队，但不是所有的团队。就像有多个房客但不是所有的房客。例如，如果你有两个DevOps工程师和六个敏捷团队，把DevOps工程师1分配给敏捷团队A、B和C，把DevOps工程师2分配给敏捷团队D、E、F。这样，团队会感到与DevOps工程师有某种程度的关联性。他们开始思考“DevOps工程师1是和我一起配合的人”而不是“我们有两个DevOps工程师的资源池，要找他们帮忙就要提交请求来排队”。看到区别了吗？一方面我们打破了壁垒，另一方面可以确保他们和团队一起成长。
标准
在多个团队情况下，如何保持标准，是一个不变的主题。如果我们允许每个敏捷团队自主决定哪种模式、基础库、框架甚至技术，公司如何受益于规模的扩展？工程师如何在团队之间调动的过程中共享知识？在很多情况下，这些问题的答案是“那要看情况”。
这取决于组织、领导和团队成员。让我们看一些不同的方法。
“规模经济”一词是指企业因其经营的规模而实现的成本优势。基本的概念是，因为固定成本分散在更多的输出单位，每单位的输出成本随规模的增加而减少。这种思想可以追溯到亚当·斯密（1723～1790）和通过分工获取更大的生产效益的概念。
对于工程团队，规模经济来自于诸如有关技术或经营方式的知识共享。如果从项目的角度把软件研发服务的成本分解成固定成本的和可变成本两个部分，我们可以得到如下的结果。固定成本包括软件开发人员的知识和技能。我们在每个迭代为此付出，无论是为一个场景写代码还是为50个场景写代码，成本都一样。每个迭代的代码完成量越多，固定成本的分摊就越小。如果只完成一个场景的代码，这个场景就消耗固定成本的100%，如果我们的写20个场景的代码，每个场景就只负担5%的固定成本。如果每个软件开发团队（敏捷团队）必须是不同的语言、技术或过程的专家，这个知识的固定成本只由负责那些场景的单一代码团队负担。如果所有的团队都可以利用彼此的知识，那么成本就可以由所有的团队来分担。
一些组织认为应该允许团队对所有的事情独立做决定，最好的想法就会渗透到整个团队。其他组织采取不同的方法，把团队成员集中在一起制订出大家要共同遵守的标准。我们先来看看Spotify的数字音乐服务是如何解决敏捷团队的架构设计问题的。然后我们将以此方法与Wooga作对比，Wooga是一个社交游戏公司，其采用的方法稍有不同。
