去年10月，我开始引导项目实施Scrum of Scrum，当时项目正面临外场重要局点上线的挑战，冗长的功能列表与有限的交付时间激烈地发生着碰撞，就在这种情况下项目开始了Scrum of Scrum的运作。
为何要选择SoS作为项目层面的敏捷解决方案呢？因为它够轻且够用，首先它不存在太多的职能，既能保持组织的灵活性又可以在必要时进行扩充；同时对于已经熟悉Scrum运作的项目成员来说它容易理解和操作；最后也是最重要的是它能够解决以往项目交付过程中出现的问题，这些问题的最大症结就是浪费，包括时间浪费、人力浪费等。那么浪费从何而来呢？丰田汽车的大野耐一将浪费描述为三种类型：
在SoS中我们做的最重要和最有价值的事就是努力减少交付过程中的上述浪费，而Scrum的特质有助于我们达成这个目标。
实施SoS的第一步是组建一个SoS的Scrum Team，项目层面通常包含很多干系人但从交付角度出发，需求、测试和研发依旧是基本构成，包括需求代表（PM）、方案总工（BA）、研发代表（Team Leader）、测试经理（TSE）。这个团队的作用在于 关注交付流动 、 解决当下障碍 以及 看到更远的价值 ，因此交付的阶段目标、交付的进度以及需要协调移除的障碍都在SoS会议（晨会，20～30分钟）上传递、反馈、跟踪并得到解决；而SoS的回顾会（跟随迭代节奏）帮助所有人思考“如何在下一个周期做的更好”。
接下来的一步是制订清晰明确的交付目标，这里的目标不仅是最终交付目标也需要 阶段交付目标 并且是 项目的 、 跨团队的 目标。为何这样要求？很多人表示我们清楚最终交付目标而且每个团队都有按优先级排序的PB，在目标管理上这些已经足够了。
上述观点有一定的合理性，如果考虑到系统产品的交付周期较长、包含的功能较多，事实上最终交付目标完全可以视作马拉松终点，一个距离意义上的模糊的点，只有当你看见它并靠近它才是有意义的，另外在这段很长的赛程上到达终点的策略可以是不同的，阶段性的目标方便及时检查与最终目标的偏差有利于调整策略；项目根据交付价值排定交付优先级，但当一个时间较长且模糊的交付目标分解后，指派到不同团队会由于领域差别产生不一致的优先级，这种烟囱式按照团队领域来排定优先级的方法特别容易造成交付过程中的等待，因为大家对优先级的认识是不一样的，而当所有人都使用同一个PB的时候看到的就是项目追求的价值，这个优先级自然而然地指导团队并与项目保持一致，也让团队与团队间的协同变得容易起来。
风险管理是SoS的另一个关注重点，由于项目以往的经验对于风险的管理往往会强于目标管理，因此SoS把风险管理的重点放在了反馈机制上（责任人、干系方、时间盒），更快地闭环跟踪，力求降低风险反馈的周期，这是Scrum的强项。
在有了目标和风险管理后，还有一步十分重要也是Scrum真正价值的体现，那就是透明。以往我们总是一遍遍地宣贯，宣贯的是一个相对模糊的交付目标，一个有些做到哪算哪的PB和各个团队迥异的优先级，因而容易出现开发团队随时间推移对本就模糊目标的迷失，研发人员由于优先级不一产生的交付价值的困惑，以及团队间、产品间各种各样的浪费；现在我们需要的是项目中的所有人都能够随时地了解项目的交付目标是什么，价值如何，障碍有哪些以及目标的完成情况（进展、质量），在关键价值上形成同步和聚焦。
借助工具我们将目标、关键路径（交付物）、障碍、进度以及风险数据可视化，每天我们都在审视这些数据任何人都能从中获得想要的数据：开发团队负责人获得清晰的目标以及优先级等；项目负责人获得交付进度和质量报告、团队协作情况评估、风险搜集等。所有人在获取数据的同时也在提供数据，信息透明化使得各个节点的关键角色能够搜集到足够的数据来做出合适的决策，例如：SoS会上测试基于交付情况提出有必要增加一套自动化测试来作为与外部产品相关功能的检验，这样的一套自动化环境比较特殊，因为涉及多个外部产品资源且形态各不相同。SoS认为这是一个影响交付的障碍需要立即解决，很快在工具上就看到该障碍的跟踪条目、预期时间点与负责人，因为所有人（包括产品负责人）都能看到这个条目，所以搭建这套环境需要的设备、技术和人力从团队、项目和产品很快汇聚到一起，只用了一周不到的时间这套自动化环境就上线运行并且直到现在仍在持续发挥作用。
目标清晰、风险可控、信息透明这是我们实践SoS的魅力所在。拥有这些对SoS而言是不是已经足够了？显然不是。虽然我们加强了沟通协作减少了浪费，但这种成果给予所有人的还只是主观上的感受，个更需要落在纸面上的数据，它能帮忙我们更快地评估我们的改进是否真正发挥作用，因此对于我们而言下一步的重点是度量，建立适用于项目的数据采集、处理、分析体系，更快速和精准地帮助我们把握研发改进过程中的每个环节，让SoS的Scrum特质发挥地更充分。