谁应该促成与外部传统团队的会议?
我在一个遵循自组织原则的团队中担任SM。
不幸的是，我们并不是生活在一个理想的世界里，有一个由传统团队维护的系统，为我们提供我们所依赖的数据。
也就是说，我们的Scrum团队和传统团队不时需要召开协调会议，不仅是从业务角度，而且是从技术角度。
问题是，谁应该组织这些会议?我倾向于说应该是scrum团队成员，因为他们是自组织的，但是，其他团队真的遵循传统的指导方针，所以如果开发人员自己促进和参与，或者如果PO或SM应该领导这些案例，他们就没有真正的权力。
你为什么要再开一次联盟会议?看起来维护外部系统的“传统团队”是Scrum团队所做工作的关键涉众。正因为如此，他们应该被邀请参加Scrum团队的Sprint评审。这将是一个很好的机会，让团队在接下来的步骤中同步和对齐。
如果你确实需要额外的机会让两个团队的成员聚在一起，你希望从调解人那里得到什么?其他沟通的例子可能只是Scrum团队中合适的人与其他团队的成员交谈，但参与的人会根据所讨论的内容而有所不同。临时和及时的沟通是有帮助的，可能不需要太多的促进。
如果开发人员自己进行促进和参与，他们就没有真正的权力
让我们暂时把对齐会议放在一边。你的团队能进行冲刺吗承诺，并保持自己负责任的因为这需要“传统”团队所做的工作?
@Thomas，谢谢你的建议。我会尽力的。
我不会“试着让它工作”。我会从一些小的改变开始。您有一个事件用于Scrum团队和团队外部的关键涉众之间的同步。好好利用这一点，然后重新审视。使用未来的Sprint评审和Sprint回顾来重新评估，如果您继续遇到问题，可能会做出额外的更改。
我同意@Thomas的观点。您已经有了允许两个团队在每个Sprint结束时进行交流的Scrum Event。产品负责人应该将它们包括在Sprint评审中。如果我是Scrum Master，我会接触其他团队，询问他们是否愿意尝试其他替代方案。教育他们Sprint评审的目的，并说服他们在2-3个Sprint中尝试。
@Ian给了你一个非常不同的视角，这是一种极好的讨论情况的方式。与你的Scrum团队讨论，与其他团队讨论。然后促成双方团队的讨论。让其他团队看到自我组织的力量。它还将帮助他们理解如何有效地与Scrum团队进行交互。
在你的描述中，你似乎是一些数据的接收方(1)，或者你的团队是另一方的交付方(2)，和/或你们都负责向另一方或多方交付相同的数据集(3)?
在前两种情况下，应该有某种类型的SLA，其中应该有关于定期会议的正式描述。PS: mores也可以是某种SLA(!)。
如果没有SLA，或者有理由打破SLA:与其他团队的负责人讨论，并就谁在哪种情况下做什么达成一致。
在所有情况下(1、2和3)，都应该明确谁在什么时候负责什么，包括定期会面/协调。
谁实际负责安排定期会议，更多的是达成一致的结果(最好在SLA中明确)，而不是SCRUM中的规则。
实际上，当有人有机会带头，并以这种方式对结果产生更大的影响时，对我来说，这将是一个倾向于牵头安排和主持这样一个会议的理由。但前提是它能支持我们必须交付的东西。
如果你对结果负责，并且允许你分配FTEs给它，那么就带头吧!
如果另一方要对结果负责，那么就让他们去做，或者让他们付钱给你的团队来促成会议。
PS:如果情况3适用(你们双方都有责任)，而另一个团队不准备投入时间，那么可能是时候解除合同了，或者重新考虑你的团队是否想要完全负责某件事，而只有部分(你的团队)能够以预期的质量交付产品。顺便说一下，我们也可以降低质量保证，但大多数客户不会允许这样做。