拉近干系人距离，又不拆散团队
当团队几乎在一夜之间转为远程办公，过去发生在走廊里的那些与干系人的随意接触,就这样消失了。一些 Scrum 团队的应对方式是把所有人都请来参加所有会议；另一些则陷入沉默，指望增量自己说话。这两个极端都行不通。Scrum 依赖与干系人频繁而诚实的接触来引导产品，但它同时也保护开发者在 Sprint 内进行专注工作的能力。把这个平衡拿捏错了，是健康团队开始动摇的最常见原因之一。
《Scrum 指南》对干系人的位置有明确安排。Sprint 评审就是为他们而设的事件：这是一场非正式的工作会议，Scrum 团队与干系人在会上检视增量，并共同调整产品待办列表。它不是状态汇报，也不是签字批准仪式。大多数参与问题都可以追溯到团队忘记了这一区别。
一再出现的错误
把 Sprint 评审变成演示秀。 当评审变成一场旨在打动人的精致演讲，真正的反馈就枯竭了。干系人点点头，没人提出那个尴尬的问题，产品待办列表也从未被真正调整。让它保持为一场关于下一步该做什么的工作对话，而不是一场表演。
让干系人打断 Sprint。 一位高层赞助人在 Sprint 中途给某位开发者发来新的必备需求，Sprint 目标便悄然瓦解。产品负责人存在的意义正是为了防止这种情况。让每一项请求都经过产品负责人和产品待办列表，而不是进入某人的私信。
把忙碌当成参与。 把所有干系人都请来参加每日 Scrum，或在每个邮件线程里都抄送他们，看似包容，实则让所有人不堪重负并稀释了责任。在他们的意见能改变某项决策之处让他们参与，其余的就别打扰他们。
只听最大的声音。 声音最大的干系人很少是最有代表性的。一味迎合嗓门最大者的团队，最终做出的产品只服务于用户群的一个角落，并在发布时让其他所有人措手不及。
把坏消息藏到评审才说。 如果一个 Sprint 偏离轨道，干系人应该尽早知道，而不是在评审上才发现。意外对信任的破坏，比延期更快。
维持健康参与的习惯
解决之道不是增加会议，而是更清晰的归属与节奏。赋予产品负责人对产品待办列表的真正权威，并在他说「不」时支持他。把 Sprint 评审变成一场真正双向的工作会议，并让干系人有所准备，使他们明白自己的职责是对真实的增量作出回应，而不是欣赏幻灯片。
保持一份简短且可见的产品待办列表，让干系人看到自己的请求相对于其他一切排在哪里。
为新请求设定一个清晰的单一渠道，并以书面方式确认，使任何请求都不会通过私下交谈溜进来。
按相关性而非职级邀请干系人，并告诉他们你需要他们作出什么决定。
在两次评审之间以轻量的方式分享进展，使评审不会出现令人不快的意外。
尤其对混合团队而言，这一切都不会自然发生。时区差异、疲惫和相互竞争的优先级，都会把干系人拉出回路。一套刻意设计的参与节奏，由产品负责人主导、由 Scrum Master 守护，正是它让产品始终指向真实成果，同时让团队在 Sprint 内保持专注。
如果你希望有人帮你把这套节奏融入组织真正的交付方式中，XNM 的项目集与项目交付咨询 可以帮你把它建立起来并坚持下去。