众所周知，Scrum Team里只有三种角色：Product Owner，Scrum Master，Team Members。因此谈到多个Scrum Team之间的协作时，CounterPart之间的协作问题就会顺理成章地浮现出来。本文先谈谈Product Owner之间的协作。
如果在一个产品团队，不同Scrum Team的PO连对方最近的Sprint做了什么功能都不知道，那他们显然缺乏最基本的沟通，协作就更谈不上了。这个看上去很匪夷所思的现象，却真实的存在过。尤其是在一个分布式的团队里，也许更加常见。
探寻解决的办法：Scrum是以Product backlog来驱动的，而PO就是这个backlog的拥有者。PO是一个站在客户及所有干系人（StakeHolder）的立场上做决策的人：要开发什么（What），什么时候开发（When，Prioritization）。一份backlog如果有多个“Owner”，而这些Owner又是平等关系时，往往不是个好主意，做决策时容易扯皮。那怎么办呢？两种做法：
一，把产品按子产品、或者模块划分，自然而然Team也如此划分，然后各个PO各自拥有一份子产品的backlog，各自维护各自的，这样就容易出现上面提及的现象。除非子产品之间确实没有交集，那这种做法倒也不失为高效之举。
二，对于一个各功能模块间互相有关联的大型产品，也许就需要另一个思路：一个产品只维护一个backlog，所有PO共享，但是通过成立一个“委员会”的方式，就是Product Owner Coucil。
PO Coucil由一个核心PO作为Lead（委员长！），把其它PO，Customer，Stakeholder……都包含进来（也许还需要一个核心开发人员）。这个委员会完全可以使用轻量级的Scrum方法来运作：
借鉴Scrum里的Plan meeting：审视Release Planning里要完成的Story。
借鉴Scrum里的Sprint：超前于Developer的Sprint周期，维护一个Product backlog。比如把史诗拆分成Story；重新排序；决定下个Sprint中要开发的Story……
借鉴Scrum里的Daily meeting：定期召开meeting来协调backlog。比如协调和同步Story开发情况、依赖情况；把Story从Team A转移到Team B……
借鉴Scrum里的Retrospective meeting: 一个Release之后，举行回顾会议，看看在上个发布里，有什么是值得继续发扬的，有哪些失误，需要做哪些改进（包括backlog的维护；这个Coucil运作流程本身）……
总结：多Scrum Team之间PO的协作方法，1，按子产品划分，一个子产品对于一个Team，一个PO，一份Product Backlog；2，如果子产品不够独立，则整个产品使用一份Product Backlog，所有PO紧紧围绕在以“委员长”为最高决策人的委员会周围，建设有XX特色的river crab社会……