我对 Scrum 的概念和好处有些熟悉。考虑到这一点，我正在努力改善我现在工作的一家公司失败的 Scrum 产品管理结构，该公司拥有三个独立的 B2C 产品，满足相同的人群并在同一个网站上访问。每个产品背后都有一个产品所有者和一个独特的开发团队。
鉴于目标受众相似（不确定是否重要）并且 3 个 Web 产品在性质上相似，合并团队和只有一个产品所有者和一个开发团队相关的潜在好处/风险是什么？想到的一些问题是：如果您的网站有三个不同的产品，那么拥有 3 个产品所有者和三个不同的 backlog 是否有意义？此外，如果您只有一个产品负责人，那么选择谁的最佳指标是什么？
在查看如何处理团队之前，请尝试确定导致失败的原因。
你在进行回顾吗？团队是否就如何改进提出了任何解决方案/建议（scrum 强调团队和个人责任——团队应该是解决方案的参与者）
多个 PO 几乎肯定会导致团队环境更加混乱。PO 的部分优雅之处在于为团队提供了一个负责人，以最终批准“什么”问题。
但我已经超前了——首先，要非常了解这些问题。
你需要合并团队吗？我不知道，但 7 +- 2 规则是一个非常好的经验法则。如果你在做类似的事情，也许你需要一个架构团队。也许您的团队配置很好，但您的工作流程中还有其他问题。
强烈考虑引进一位优秀的 Scrum 教练。那里有许多培训和指导咨询公司，这些人在全国各地旅行，帮助像我们这样的人实施。
我现在已经实施了两次 scrum，老实说，如果不是因为引入培训，它就不会像现在这样顺利。（你还必须有管理层的赞助——如果我的实施，我什至可以让 CIO 参加培训——这是变革性的）
一些额外的上下文会很有用。
团队有多大？（记住 7 +/- 2 团队规模指南。）它们是跨职能的吗？
是什么赋予了每个产品独特的个性？相反，将每个产品的“生物和技术独特性”添加到产品集合中会得到什么？
您多久部署一次网络？
这不是团队问题，而是管理问题。作为 Scrum Master，您的职责是指导功能障碍，在这种情况下，您强调了一些值得关注的问题；因为产品之间存在不一致，并且可能不是最佳的团队绩效。
与现有产品所有者一起感受你的观察，并确定他们是否认为这是一个问题。每个产品所有者都有选择他们将如何管理它的特权。由于这些不同的网站可能会不一致并影响公司品牌，因此由 PO 选择做/不做，因为这是他们的风险。
如果他们确实觉得品牌处于危险之中，那么接下来就是将三个团队放在一起（开会），并向他们提出相同的问题。然后让他们解决它，看看他们想出了什么。
您说“公司的 Scrum 产品管理结构失败”，我建议您首先尝试准确了解公司当前的 Scrum 流程 失败的原因。
对于简单地尝试合并这三个团队，我会非常谨慎，这样做可能会对公司文化造成很大的破坏，伴随着阻力，但仍然无法获得你想要的结果。
了解当前失败的一种好方法是找到一种方法来可视化您的工作流程。这应该有助于暴露开发生命周期中的任何瓶颈和/或错过的期望。
看板是一种很好的技术，不需要任何新的流程或更改就位！只需在白板上通过泳道绘制您当前的工作流程，尝试限制白板上的 WIP，并围绕看板执行您的日常站立式 Scrum 会议。这应该使您能够非常快速地了解并确定当前流程中的失败之处。
我还推荐 Henrik Kniberg 的“Lean from the Trenches”作为另一个很好的资源。
简单地想，如果您要将所有三种产品合并为一个，那么您将不得不对 PO 做同样的事情，但如果您的产品将继续单独存在，您将不得不为每个产品保留 PO。
我认为“性质相似”会导致诸如“两种产品具有相同功能”或“三种产品的总体方向是什么以及它们如何干扰”之类的问题。要解决这类问题，您可以使用“scrum of scrums”，通常是每周一次的会议，其中包括所有团队成员，每个团队都在分享他们即将到来的 sprint 的目标。这种协作可以更好地了解谁在做什么以及它如何影响整个系统。
“相似的目标受众”并不是合并团队的好理由。
在团队规模的限制下，三个产品是三个团队的良好基础。团队需要足够大以包含所有必要的技能，同时又要足够小以消除冗余的通信路径。
除此之外，如果没有更多您似乎不愿意提供的上下文，就不可能帮助您确定他们“失败的 Scrum”的原因。
因此，唯一的建议是；聘请高质量的 Scrum 教练，或者如果不可行，请识别气味并应用说明性解决方案。