拥有许多敏捷Scrum团队的组织也只有一小部分人被任命为“企业架构师”。EA小组充当质量和对决策的坚持和控制者。这导致团队决策和EA决策之间出现重叠。
例如，团队可能要使用库X或要使用REST而不是SOAP，但是EA对此不赞成。
现在，当团队决策被否决时，这可能会导致挫败感。言归正传，它有可能导致EA人员“抢夺”所有权力，并且团队最终感到动力不足，甚至一点也不敏捷。
在Scrum的导游有这样一段话吧：
自组织：没有人（甚至不是Scrum Master）告诉开发团队如何将产品待办事项转换为潜在可发布功能的增量。
那合理吗？EA团队应该解散吗？车队应该拒绝还是仅仅遵守？
Answers:
一个开发团队由3–9名具有跨职能技能的人组成，他们会进行实际工作
Scrum Master应该邀请“ Enterprise Architect”成为项目团队的一部分。这样，架构师和程序员之间的交流就会非常好。
选择使用的技术是软件要求的一部分，这意味着功能请求的一部分，无论出于何种原因，您都不使用某些技术。
架构师为系统和代码库说话，因为系统和代码库无法为自己说话。通常，拥有架构师符合公司的长期最佳利益，特别是依赖于内部构建的软件的公司。
架构师没有告诉开发人员如何将积压的订单转换为增量（冲刺），而是在说哪些技术可以使用，哪些不能使用。您正在混淆两个不同的问题。
解决方案是什么都不要改变。如果您的团队因架构师过于严格或过分负担而感到沮丧，那就是与SCRUM无关的人事问题，应与业务利益相关方一起解决员工满意度以及（如果可能）底线问题（“ x%开发功能花了我们更长的时间，y因为架构师z不会让我们使用Turbo Pascal。”）
这种事情对于在需要庞大的团队来完成项目与保持敏捷的团队规模之间保持平衡之间是必要的。
通常，“团队领导者混乱”由从每个较小的团队中选出的一名成员组成。这提供了一些自组织的性质，并提供了某种表示方式，以便高层团队做出的决定被敏捷团队接受。
对于您的特定情况，应该采取一些措施来阻止敏捷团队的动力不足，但可能不能叛逆或简单接受。团队需要意识到，您在这里是要制作好的软件，而不是ko强于理想。拥有许多不同的团队，每个团队使用不同的技术在同一项目中完成相似的工作，将会导致软件质量下降。在同一项目中拥有许多不同的团队使用不同的编码标准将导致软件质量下降。
因此，您将需要某种方式就该项目的运作方式达成共识。团队主管Scrum在其他地方得到有效利用。您可能需要做一些不同的事情，或者调查为什么您的团队没有有效地做到这一点。
问题是：这个架构师团队存在的原因是什么？我能想到的唯一原因就是要加强各个团队之间的互操作性。或者，团队正在研究单个产品的各个部分，而这个架构师团队的存在是为了使每个部分都协同工作。
出于您所说的确切原因，我真的认为该方案无法在敏捷环境中很好地工作。各个团队应该是独立的，他们的投入和产出也应该是独立的。因此，限制其输出仅应作为对输入的要求的一部分。但是这些限制应该是合理的。诸如“不得使用库X”之类的要求不是很好，但要说“必须将已使用的第三方库的数量限制为最低”或“应添加其他团队中未使用的新库”。应该没事。
然后，我将解散所有团队中的架构师团队，并将他们的专业知识用于架构问题。通过成为团队的一员，他们将能够更好地了解团队所遇到的问题，并且在更改体系结构的核心部分时可能会有更好的想法或受过更好教育的观点。还应该鼓励跨团队的架构师进行交流，以确保跨团队的架构保持一致。
Scaled Agile Framework的小组对此说得很好。我们大多数人都是在团队级别进行交易，但在扩大规模时，我们需要认识到在计划和项目组合级别也要扮演角色。需要在整个组织范围内制定体系结构决策，这应该影响到组织较低层级正在发生的事情。进行架构决策没有错！
与此相关的是，Dean Leffingwell最近写的《敏捷软件需求》一书在这个主题上很不错，我一直在自己阅读。
我们也有多个敏捷团队（有些是看板，有些是Scrum）和架构师。架构师负责涵盖我们所有产品的基础架构（帮助程序库，身份验证，构建基础架构）等。他们不仅要制定技术决策，而且还要实施事物，主要是基础架构组件。
这很好用，通常没有冲突。我认为关键一点是：
建筑师对团队没有正式的权力，不能仅仅推翻他们。通常，架构师会做出适用于所有产品的决策，而团队会针对其产品做出决策。如果存在冲突，则架构师和团队只需达成协议或升级为管理层（尽管这种情况很少发生）。
我认为让架构师和开发人员成为同行非常重要。两者都朝着一个共同的目标努力，只是在不同领域。如果没有人能够“推翻”对方，合作将会更好。
我在这里看不到任何冲突。据我了解，所有EA（我认为是冠冕堂皇的标题）都是要进行质量检查。每个人都应该意识到这一点。
您应该考虑，在任何开发方法中（值得考虑的一种方法），需求收集都是至关重要的一步，无论是迭代的还是预先的。
其中一些要求是由公司政策设置的。这些设定了基本规则：
但是无论采用哪种方式，都无法满足要求。如果难以确定，那么就没有要求，您需要重申它成为真正可测试的（广义上）。您应按要求重复进行处理。
您的架构师不应推翻您的敏捷团队做出的决定。您的架构师应将这些包括在传递给团队的需求/故事中。当引入项目前景变化和新的互操作性要求时，他们应该使团队保持更新。
建筑师发出命令并审查技术决策是一种文化缺陷。他们将自己视为“老板”，而不是简单地保持共同的目标/愿景并在同一页面上保持独立的团队。敏捷方法基于沟通和联系。如果您的建筑师直到做出决定后才参与进来，那么他们就会失败。