随着Scrum的应用范围的扩大，复杂的大型项目——跨部门，跨团队，甚至超越传统的极限的项目，也可以利用管理小团队的管理方式作为基础来进行管 理。Scrum的可扩展性的关键因素就在于Scrum of Scrums，传统上称为“方案管理”（program management）。
很多ScrumMaster和敏捷项目管理者都在Scrum扩大后，在沟通方式以及多团队的协作上跌倒过。更具体来说，用来管理小型敏捷团队的技巧对于管理多个团队来说不大适用。打个比方说，尽管你有个锤子，但不代表你就可以用这个锤子来伐木（“黄金锤子”反模式）。
一位APM（敏捷方案管理者Agile program manager）指的是一位管理多个小型项目（不管这些项目是不是实施Scrum，甚至不是开发类的项目）的ScrumMaster。在一个大型组织当 中，一位APM可能各种软件开发和操作团队共同协作，甚至还会有负责市场推广的团队、分布式团队和离岸外包团队的参与。APM需要清晰地知道并不是所有团 队都使用Scrum或者敏捷流程，因此要协调团队之间的期望值。APM同时也需要理解，并不是所有的敏捷团队都能够创造出同样的价值。
那么APM的职责有哪些呢？
跟踪和协调项目档案（portfolio）以及其依赖关系
保证每个项目都有一个直接负责人
管理方案的活动、处理问题和风险控制
让每个人都知道正在发生什么事
维护流程以及工作协议
现在让我们来看看怎么样才能让这个流程发挥作用。
方案档案
方案档案是一个管理各个团队的史诗的依赖关系的表格。高亮的格子代表每个史诗需要发布的时间。这份档案是需要根据项目实际情况来进行不断更新的。
组 长们需要复杂提供两项关键信息：每个史诗的开始和完成时间的初步估计和每当估算有变化，或者能够准时按照估算进行时通知APM。APM本身并不会参与估算 或者建议团队承诺哪些史诗，他要做的事情就是保证各个团队对顺利前行。APM需要对档案中的估算日期进行每周至少一次的核实。在这份档案中，颜色起着非常 重要的作用，我的习惯是，将完成的史诗对应的一行标成绿色，将错过重要里程碑或者存在风险的标成红色或者黄色。
方案档案并不是待办列表，也不是由APM来管理团的待办列表。虽然APM可以帮助ScrumMaster使用代表列表，也可以帮助Product Owner对用户故事进行优先级排序，但是产品代表列表对于APM的管理来说已经过于具体了。APM需要清楚知道他需要了解到多深入，也需要信任 ScrumMaster，团队组长和其他团队成员。这个是关键所在。
管理活动、问题和风险
不是所有障碍都一样的，也不是所有在日常出现的问题都需要提交到APM来解决。如果问题和风险会影响到史诗的交付，或者项目的发布的话，那么就是严重的问题了。所有这些严重的问题都需要记录在案。
问题和风险都会自己暴露出来，但是活动呢？那些跨团队和边界的活动需要被跟踪。另外，像“spikes”和“proofs”这类会影响整体进度的，需要被严格监视。
如果APM试图管理太多细节，他很快就会感到迷惑，沮丧和慌张。只要APM可以专注在对项目整体影响最大的点上，那么他就能够更好地避免项目失败。
对风险的了解
APM需要对每个史诗和团队有足够的了解，并且能够清晰地传达整个方案整体目标。于此同时，APM也需要用于对团队组长发问，并让他们提供详细信息。尽管APM可能是某个方面的专家，但是他应该只需要传达概要信息，而让各个团队组长来传递细节信息。
直接负责人
成功实施Scrum of Scrums的关键在于每个和你一起工作的团队都有一个拥护者，用苹果的说来讲，就是直接负责人（DRI）。对很多方案来说，容易导致失败的关键点是缺乏 集中的沟通渠道。通常APM会做大量的工作来启动一个项目，因为这个项目没有直接负责人或者这个直接负责人无法担当起责任。这是一个容易导致失败的关键因 素。
直接负责人并不是指手画脚就可以了。他作为项目和APM沟通桥梁，他必须能够对APM的真正意图作出有效明确的传达和解释。直接负责人必须为APM的方案档案提供数据，同时也需要能够提出问题和发现风险，并且能够和APM一起保证整个方案的顺利进行。
在一个实施Scrum的组织中，直接负责人应该是ScrumMaster。我认为ScrumMaster是最佳人选——因为他已经能够掌握敏捷的实践和懂得敏捷的价值。
在传统的环境中，直接负责人通常是团队组长，但是这并不是必须的。责任感和驱动力是关键的因素，而不能仅仅考虑公司架构中的角色名字。有些情况下， 团队组长有可能太忙了，或者他明显就不是合适的人选。无论如何，直接负责人是用于具体职责的全新团队角色，可以由团队中胜任的任何人来担任。
每日站会还是每周例会？
理论上来说，你应该每天都举行每日站会来了解方案的情况，就像小团队所做的一样。每个直接负责人简单介绍当前史诗的进展情况，接下来要做的事情，以及相关的问题和风险。
这个是提出修改日程表（如果需要的话可以在每日站会后讨论），讨论依赖关系，提出缓解风险的非常好的时间。除了讨论问题的粒度差别以外，其他都按照普通的每日站会形式来进行。
当然，实际情况并不是经常都那么理想。由于各种的原因都有可能导致每日站会无法进行，这个时候就需要进行每周例会了。例会通常持续15到30分钟， 会议的内容和每日站会一样，只不过是每周进行一次而已。在例会中，我们假定每次例会所有直接负责人都会参加，并且所有紧迫的问题都会被提出来。但有时候这 些假设要被重新强调，因为在整个方案的结构中很可能就被忘记了。
结论
实施Scrum of Scrums是非常简单明了的，而且具有可扩展性，只要你能够掌握原理和基本概念，也明白Scrum的价值所在。无论手册设计得如何出色，APM都无法百 分之百地按照Scrum手册来进行操作。为了能够跟好地适应大型项目，对Scrum的工具进行小幅度的修改是允许的。这样即使以后团队扩张，也能够让团队 继续保持敏捷。
