扫码阅读
手机扫码阅读

Scrum of Scrums:如何高效协调多个团队进行线性敏捷规模化

76 2024-01-16

什么是 Scrum of Scrums?

Scrum of Scrums 是主流的敏捷规模化方法之一,被用于在复杂敏捷项目组织中协调多个项目团队,并能够直观地进行线性规模化。

Scrum框架的作者Jeff Southerland和Ken Schwaber于1996年在IDX Systems工作时首次使用了Scrum of Scrums。当时他们需要一种方法来协调八个事业部,每个事业部有多个产品线,而Scrum of Scrums 使他们能够有效地做到这一点。2001年,他们发表了一篇文章:《敏捷可以扩展:发明和重塑SCRUM1》,根据他们的经验,提出如何用Scrum of Scrums的方法将Scrum应用于大型组织之中。2011年,他们发表了Scrum@Scale指南2,这是一个更全面、规模更大的敏捷框架,用于在大型组织中实现Scrum,Scrum of Scrums 被整合于其中,成为规模化的技术之一。

从此以后,Scrum of Scrums 成为管理多个Scrum团队和线性规模化最流行的敏捷规模化框架之一。根据Digital.ai的一项调查,截至2020年,Scrum of Scrums 是第二大最受欢迎的规模化框架。

从核心来说,Scrum of Scrums 是一个会议,来自每个团队的代表将在这个会议里会面和讨论,各个代表可以协调项目、共享信息和解决依赖工作的关系。代表的数量和会议的频率取决于组织自身,只要它能够实现了Scrum of Scrums 的目的。

一个团队的最佳人数是多少?

Scrum of Scrums 的一个关键点是将一个大团队拆分为多个小团队。大型团队通常会降低团队的生产力和绩效,因为信息的交流和沟通是一项挑战,很难及时让每个人都了解最新的变化,也很难确保每个人都在同一个页面上。这可能会导致误解、错过最后期限,甚至导致代码中的错误。

这个Scrum@Scale根据1970年哈佛大学的研究,该指南建议团队中有4到5人,建议最佳团队规模为4.6人。然而,关于最佳团队人数的研究还有很多。例如,SCRUM:《保持团队规模在7以下!3》。根据SCRUM的研究:《保持团队规模在7以下!3》- Scrum Inc. 解释了Scrum团队中少于10人的证据,这在Scrum指南中有所建议。报告还说,规模较小的球队表现还要更好一点,但是差异很小。根据这些研究,5到10人似乎是团队的最佳规模,我们应该根据业务环境进行调整。

  • Scrum of Scrums 的关键点是将大团队拆分为多个小团队,因为大团队的生产力和绩效会下降。

  • 有几项研究显示了团队的最佳规模,这些研究显示的数字略有不同。

  • 5到10之间似乎是最佳数字。但需要根据业务环境进行调整。

那么如何进行 Scrum of Scrums?

在Scrum of Scrums 期间,来自各个Scrum团队的代表们同样地在Scrum Master的引导下讨论了几个与通常的Scrum相似的主题。然而,这些主题可以根据您的项目环境来进行调整,因为没有事实上的标准。比如,我们可以提问来帮助我们:

  • 自上次Scrum of Scrums 会议以来,团队完成了什么?

  • 在下一次Scrum of Scrums 会议之前,团队将做什么?

  • 是否存在阻碍团队完成工作的挑战?

  • 您的团队正在进行的任何任务是否可能阻碍另一个团队的进度?

Scrum of Scrums 的频率取决于项目,尽管Scrum@Scale指南建议,在每个团队的每日站会之后,来自各团队的代表又用15分钟来进行规模化敏捷的每日站会(Scaled Daily Scrum,SDS)。下表描述了如何根据我的研究进行Scrum of Scrums 。然而,您必须自定义它,因为似乎没有Scrum of Scrums 官方文档来进行指导。

代表

代表可以是任何人,只要它实现的目的。通常,产品负责人和scrum管理者都会参加。如果有必要,一些开发人员也参加。

频率

每天

持续时间

15分钟

主题

自从上次Scrum of Scrums 会议以来,团队完成了什么?在下一次Scrum of Scrums 会议之前,团队会做什么?是否存在阻碍团队完成工作的挑战?你的团队有没有什么任务可能会阻碍另一个团队的进展?

首席产品负责人(Chief Product Owner)

首席产品负责人(CPO)是代表跨团队的总产品负责人的角色。CPO负责监督产品整体,确定优先级,并解决团队之间的依赖关系。这个角色不需要由一个专职的人来担任,而且这个角色应该与产品负责人具有相同的责任。CPO通常在产品管理方面更有经验,并对业务领域有深入的了解。此外,如果其他产品负责人不熟悉产品管理和业务知识,CPO可以对他们进行指导。

Scrum of Scrums Master(SoS Master)

SoS Master的团队是由每个Scrum团队中的Scrum Master所组建而成,对于这个SoS Master团队可以有一个SoS Master的角色(SoSM)。SoSM负责引导Scrum of Scrums,解决依赖关系,协助CPT决策,并消除障碍。SoSM尽可能地提高Scrum的绩效,在效能提升方面发挥着关键作用,因为会议的有效性是核心。SoSM通常在Scrum方面更有经验,并且需要强大的领导技能。这个角色不需要由一个专职的人来执行,和CPO类似,这个角色应该和Scrum Master有同样的责任。

其他的通用问题?

问1:Scrum of Scrums是否只是为了管理一个产品而设计的?

答1:它可以用于多种产品。当Jeff和Ken第一次尝试Scrum of Scrums时,他们正在努力协调八个事业部,每个事业部有多个产品线。根据经验,他们得出结论,Scrum可以与Scrum of Scrums进行规模化的扩展。

问2:我需要制作一个通用的产品待办列表吗?

答2:不一定,这是因为Scrum of Scrums只是一个协调会议。然而,如果有必要,你可以建立一个列表。但是,如果你在运作更全面的敏捷框架,Scrum@Scale,那么就需要一个共同的的产品待办事项列表。

问3:因为我们没有足够的Scrum Master,一个Scrum Master能管理多个团队吗?

答3:可以的。只要能实现SoS Master的目的,一个Scrum Master就可以管理多个团队。例如,当我在一个预算不足的项目上工作时,肯定需要一个Scrum Master管理多个项目。

结论

  • Scrum of Scrums 是规模化项目的最佳实践之一。它是由Scrum的作者根据他们的实践经验发明的。

  • 一个Scrum团队应该很小,在5到10之间,因为在一个大团队中,团队的绩效和生产力会下降。

  • 建议在每个团队的每日Scrum结束后的15分钟内进行SoS的每日站会。

  • CPT负责跨团队监督产品,确定优先级并解决依赖关系。这个角色不需要由一个专职的人来执行,而且这个角色应该与产品所有者具有相同的责任。

  • SoS Master是代表每个团队的Scrum Masters的角色。SoSM负责引导Scrum of Scrums,解决依赖关系,协助CPT决策,并消除障碍。

注解:

  1. 《敏捷可以扩展:发明和重塑SCRUM*》:Agile Can Scale: Inventing and Reinventing SCRUM

  2. Scrum@Scale指南:the Scrum@Scale guide

  3. 《保持团队规模在7以下!3》:SCRUM: Keep Team Size Under 7!

原文链接: http://mp.weixin.qq.com/s?__biz=MzAwNDY3NzQ1MA==&mid=2650163208&idx=1&sn=6c6747ea4f4c3a570b446aaa5bf1b1ec&chksm=832aa22db45d2b3b406a9fdde150cd278ca52dd2327f8716d6411948a63a0fb877d3f55aaa46#rd