Jeff Sutherland论文 | 完成越早，加速越快：高绩效Scrum团队的模式语言

摘要

最近的调查显示42%的敏捷项目是成功的。虽然这个成功率已经是传统项目的三倍，但49%的敏捷项目仍然延迟或超出预算，9%完全失败[1]。有一种更好的方法可以帮助敏捷团队实施Scrum。在2013年在Tisvilldeleje举行的Scrum PLoP会议上，丹麦敏捷社区的思想领袖们提出了一组Scrum模式，这些模式结合起来，可以造就一个高性能的Scrum团队。在采集汇总这些模式的过程中，可以明显地看到，将九种模式与Scrum框架结合起来可以帮助团队实现超高效能，比团队的初始速度提高400%以上。

1.介绍

在《敏捷宣言》 [2]产生的许多年前，Mike Beedle受网上Scrum文章的影响[3]，在他的公司中实施了Scrum过程，并发起了Scrum PLoP（编程设计的模式语言）会议来推动Scrum的工作。《Scrum: 超高效能软件开发的模式语言》的建立是一项开创性的工作，为这个世界上部署最广泛的敏捷流程奠定了实践基础[4]。

Jim Coplien最近的工作表明，Scrum看似简单，却整合了一组复杂的组织模式[5]。虽然Scrum包含了至少33种组织模式，但只需要花2分钟就可以把它们解释清楚。

Scrum的设计目标之一是将40年软件开发的最佳实践封装到一个流程中，该流程足够简单，普通开发人员只需不到2天的启动时间即可使用。

Coplien的分析[6]表明该目标已实现。近年来，Scrum模式社区为Scrum [7]编写了一套全面的模式，使团队可以借鉴在许多公司中已经行之有效的方法。尽管Scrum指南[8]提供了Scrum的基本规则，但这些模式为团队提供了在特定环境中实施Scrum时解决问题的工具。

2.超高效能的(Hyper-productive)软件开发

只有极少数的Scrum团队可以达到Scrum的设计目标，即将传统项目生产率提高5到10倍，并同时提高质量。其中一些超高效能团队包括Mike Beedle[3]和Jeff Sutherland的公司[9]以及来自美国[10]，俄罗斯[11]，荷兰、印度[12]的团队，还包括SPR公司所研究的一些敏捷团队。[13]。

Systematic是丹麦CMMI 5级的公司，它展示了如何通过在Sprint结束时专注于高标准的“完成”和在Sprint开始时专注于高标准的“就绪”来系统地组建一支超高效能团队[14]。他们注意到，如果在每个项目开始时更改Scrum团队的成员，就不可能实现超高生产力，这表明“稳定的团队” [5]是提高性能的前提。这与美国和欧洲对一种“休克疗法”的Scrum风格的研究发现结果一致[15]。

3.超高效能模式语言的产生

模式语言是在特定场景下，通过归纳一系列内在关联的行为，提炼出来的深层次思想。它超越了一系列流程，以寻找出能促使成功的，可重复的活动或品质。它是一个相互联系的整体，当被连贯地应用时，会产生“无名的质量”（QWAN）[18]。组合多个模式所产生的效果会大于应用单个模式的效果之和。

OpenView的风险投资者们惊讶地发现，越早完成任务的团队，加速越快。他们发现Scrum不是关于速度的，而是关于加速度的。一支加速的队伍很快就会超过平稳速度的队伍。

这种模式对投资者来说似乎是违反直觉的，因此作者和其他人在其他公司进行了实验，发现它是一直有效的。接下来的问题，是如何让它更好地运转以建立一个高效率的团队。什么样的模式会相互促进，产生意想不到的效果，使团队保持加速？

这些模式可以起到间接作用；因为他们致力于解决问题的底层结构，而不是直接解决问题本身。优秀的设计模式都是相似的：它们分析了解决方案的深层结构及相互作用，而不是只对解决方案进行分类[19]。

我们已经从Systematic公司的数据[14]中得知，稳定团队是团队能达到超高效能团队的必要条件。我们决定系统地调查阻碍团队尽早完成任务的其他所有主要问题。

4.Scrum模式

Scrum模式是针对Scrum框架中常见问题的通用且可重用的解决方案。Scrum的结构很简单，旨在帮助团队适应变化，但是Scrum并不能解决所有问题。随着时间的推移，随着Scrum的实施和改进，涌现了许多实践来解决常见的问题。

在每年的Scrum PLoP会议上，Scrum社区中一些最有影响力的人都会提出新的模式，并进行了一轮循环评审。最后，如果模式被视为具有价值，它将被批准并添加到模式列表中。

随着时间的推移，涌现了越来越多的模式，它们可以结合在一起使用。以下列出的九个模式，可以认为是构成超高效能团队的模式语言的精髓。

这些模式是：

1. 稳定的团队

2. 昨日的天气

3. 蜂拥而上：单件连续流

4. 中断缓冲：无惧打断战术

5. 每日清洁代码

6. 应急程序

7. 采用Scrum持续改进Scrum

8. 幸福指数

9. 团队完成越早，加速越快

前两个模式帮助团队为成功的Sprint做好准备，模式3-6帮助团队处理Sprint中最常见的干扰，模式7-8会将团队推向超高效能状态，并且可以促进模式9的实现。

5.帮助团队做好准备的模式

稳定的团队：保持团队的稳定，避免团队间的人员调换。稳定的团队更能了解自己的能力，使得业务具有一定的可预测性。

Scrum框架针对的是3到9名成员组成的团队。哈佛大学和其他机构的研究表明，团队的最佳规模是5个人[20,21]。小团队的沟通路径简单，沟通饱和度高，这是团队达成超高效能的关键[22]。然而，小团队并不意味着一定会成功。如果团队成员被抽调去做其他项目，或者不能定期参加团队的仪式，团队的速度将受到影响。为了解决这个问题，实践者意识到他们需要小而稳定的团队。

在2005-2007年间，PatientKeeper[23]收集的数据显示，除了一个离岸的瀑布团队外，所有的团队都达到了超高效能，驻场团队的生产率是离岸团队的10倍。驻场团队的显著特点是稳定性，在此期间团队成员几乎没有变化。另外我们也发现，大约每6-12个月给团队增加一名新人有助于带来新的想法。

6.帮助团队完成Sprint的模式

稳定的团队更易形成稳定的速度，这有助于团队预测在每次Sprint中可以完成多少点数。这让他们能够使用上一个模式来预防Sprint的失败。

昨日的天气：在大多数情况下，上一个Sprint中完成的估算点数是最可靠的预测指标，用于预测下一个Sprint中将要完成的估算点数。

“昨日的天气”允许团队建立更精确的Sprint代办列表，限制了团队雄心勃勃地引入过多估计点，从而降低了危及Sprint成功的可能性。稳定的团队知道他们的能力，这使他们能够利用“昨日的天气”这样一个模式。

稳定的团队在使用“昨日的天气”建立了切合实际的Sprint待办列表后，便开始执行Sprint内的工作。之后，他们可能会遇到许多导致Sprint失败的阻力。以下四种模式旨在解决最常见的障碍。

蜂拥而上：将团队最大的精力集中在完成一项Sprint待办项上，以尽快将其完成。谁负责这个待办项，谁就是这个团队的队长 ，每个人都必须帮助队长完成他负责的待办项。这个待办项完成后，在优先级列表上的下一个待办事项的负责人就是新的队长。

当团队无法完成Sprint中计划的工作时，通常是因为他们的在制品过多，而没有群策群力先完成Sprint待办列表中价值最高的事项。"蜂拥而上"有助于团队快速地将事项“完成”，从而提高速度。“昨日的天气“使采用"蜂拥而上"的团队能够提高速度，因为该团队正在建立切合实际的Sprint待办列表。

Scrum团队面临的下一个最常见的问题是在Sprint中被中断。团队在Sprint执行过程中，经常会有新的需求涌向团队，这些需求并不在Sprint待办列表中。卡耐基梅隆大学（Carnegie Mellon）的研究以及20年Scrum团队实践的经验同时表明， 即使团队没有遇到中断，计划了中断缓冲的团队比没有计划中断缓冲的团队效率要高得多[24]。

中断缓冲

为中断分配缓冲时间，并不允许再延长缓冲时间。设置三个简单的规则，这些规则将有助于公司进行自组织以避免干扰生产：

1. 团队根据历史数据为计划外的工作项创建缓冲区。例如，团队平均30％的工作是计划外的工作。如果团队平均速度为60个点，则将为中断缓冲预留20个点。

2. 所有请求都必须通过产品负责人进行分类。如果工作项对于当前的业务计划没有价值，产品负责人会降低它的优先级。即使具有即时价值的工作项，也可能被推到后续的Sprint中。只有几项至关重要、必须在当前的Sprint中完成的工作项，才会被产品负责人放到中断缓冲区中。

3. 如果缓冲区开始溢出，即产品负责人分配给Sprint缓冲区的点数比原计划的20个点多1个，则团队必须自动中止且必须重新计划Sprint，并通知管理层交付日期将延后。

像“蜂拥而上”一样，中断缓冲模式能帮助团队完成他们的Sprint，因为他们已经建立了处理已知工作的流程。在OpenView 风险投资旗下的公司中可以发现很多使用这些模式来解决常见问题的案例[16]。

Balihoo是一家为Wendy's，Ace Hardware和New Balance等公司提供本地营销活动自动化的公司。在一个具有18个两周Sprint的项目中，由于未能交付计划故事的一半， 导致管理层对他们的Scrum团队很不满意。

我们解决的第一个问题是，几乎每天所有故事在其Scrum板上都是处于未完成的状态。过多的在制品会延迟测试，使在Sprint中完成工作变得极为困难。我们通过“蜂拥而上”模式解决了这一问题，这使整个团队每天专注于至少完成Scrum板上的一个故事。同时，我们实施了“中断缓冲”。接下来的18个Sprint都全部成功，没有一个被中断，速度增加了两倍多。中断模式的另外一个效果是整个公司都开始进行自组织以避免Sprint中断。这意味着缓冲区永远不会被完全耗尽，团队倾向于提前完成并从下一个Sprint待办事项中拉取新的故事。这提高了“昨日的天气“，团队加速得更快了。每天至少完成一个故事，使团队可以专注于敏捷宣言中的第二个价值观——可工作而且没有缺陷的软件。这样可以在Sprint结束时最大程度地减少未完成的工作，并最大程度地提高速度。所有优秀的Scrum团队都实施“每日清洁代码”（Daily Clean Code）模式。

每日清洁代码：在不到一天的时间内修复所有错误。旨在每天结束时拥有完全干净的代码库。

如果团队不能做到每日清洁代码，则会浪费大量时间回去修复错误。可以通过在开发过程中建立质量控制来控制错误，以便在源头发现并纠正问题。2006年在硅谷的Palm公司进行的研究表明，如果未能在缺陷产生的当天修复错误，在三周后修复错误的时间可能要多达当天修复的24倍。

尽管付出了最大的努力，即使是一支出色的团队，也可能发现自己无法完成Sprint待办列表上的所有待办项，而且也没有很好的方法来成功完成Sprint。在这种情况下，他们应在Sprint的中期执行Scrum应急程序。

应急程序：如果燃尽图飘得很高（表明Sprint很有可能失败），可以尝试飞行员常规使用的技术——应急程序。发生不良情况时，需要立即执行针对该问题的应急程序，不要尝试找出错误或解决方法，否则会延迟执行。在战斗机中，不会给你足够的时间让你找出原因再采取行动的。在Sprint中期，当Sprint的失败开始变得明显时，Scrum Master有责任确保团队执行Scrum应急程序。

应急程序步骤: (仅在必要时)

1. 改变做事方法。

2. 寻求帮助，是否可以把部分待办事项交给其他人。

3. 缩小范围。

4. 中止Sprint，重新计划。通知管理层交付日期将会受到影响。

7.迈向超高效能(Hyper-productive)

“稳定的团队”和“昨日的天气”通过帮助团队进入就绪状态来为团队成功做好准备。“蜂拥而上”，“中断缓冲模式”，“每日清洁代码”和“应急程序”可帮助团队处理在Sprint期间出现的障碍。接下来的三个模式将利用先前的模式，使团队达到“超高效能”状态。

用Scrum持续改进Scrum:

在Sprint回顾会议中识别上一个Sprint中最大的障碍，并在下一个Sprint结束之前将其解决。为了解决最大的障碍，需要将其作为用户故事放入Sprint待办列表，并写清楚验收准则。然后像其他故事一样在Sprint评审中评估故事的状态。

如果团队能够利用好“用Scrum持续改进Scrum”的模式，则他们应该在每个Sprint中至少进行一个过程改进。这个过程改进模式也称为Kaizen，可以帮助团队提高速度。如果团队使用了“昨日的天气”模式，那么他们有很大的机会提前完成Sprint，因为他们又减少了一个影响速度的障碍。（Kaizen可能不是直接的过程改进，它也可能与人际关系、管理障碍或者各种棘手的人事问题有关。这些障碍也应像过程改进一样对待，并尽快解决。）

幸福指数：幸福是最好的度量指标之一，因为它是团队效率的预测指标。当人们判断现在是否幸福时，他们实际上是在展望未来。如果他们觉得公司有麻烦或方向错误，他们会感到不幸福。或者如果他们要处理的工作有重大障碍或令人沮丧，他们将感到不幸福。

掌握团队真实情况的一个有效方法是了解团队成员有多满意。

Scrum Master只需要问两个问题：

团队成员将对这些问题进行等级评分，从1分到5分。这些数字将被Scrum Master保存起来，并随着时间的推移进行跟踪。如果平均值发生显著变化，那么就需要和团队讨论一下如何提高团队的幸福感。通过监控团队的幸福指数，Scrum Master可以预测速度的下降并做出调整。

提前完成的团队，加速更快：团队通常在Sprint中拉取了太多的工作而导致无法完成。失败会阻碍团队的改进。因此，需要在Sprint中减少工作量（参见“昨日的天气”模式），然后实施有助于减少Sprint中障碍的四种模式，这将系统地处理Sprint中的所有干扰并帮助团队尽早完成。在团队提前完成时，他们会从产品待办列表中抽出新的工作项，这将提高“昨日的天气”的基线。

8.实施案例

2010年，一个新的Scrum团队成立了，他们以一周的Sprint来经营整个公司。 他们根据前三个Sprint的平均速度决定将会拖入多少待办项到下一个Sprint，并采用了中断缓冲区来处理计划外的工作。 团队尽最大的可能减少“在制品”，并专注于交付完整的故事，保持代码的整洁，而且采用了应急程序来处理棘手的问题。

该团队使用幸福指数来识别流程改进项并确定其优先级。他们让团队用1-5分为以下两个问题打分：

1） 他们认为在公司的角色怎么样？

2）他们认为公司怎么样？

然后他们分享了改进建议。该团队使用计划扑克来估算改进建议的价值，他们也估算了待办事项的价值（而不是工作量）。在早期的Sprint中，整个Sprint待办列表的价值被估算为50个价值点。

团队认为“识别更有价值的用户故事”是优先级最高的改进点。解决这一障碍估计有60多个价值点。首席产品负责人想知道，解决这个障碍是否可以使速度加倍，因为这个障碍的价值高于Sprint的整个产品待办列表的价值。

“改善用户故事”被放入产品待办事列表中，并被拉到下一个Sprint，定义了明确的“完成的定义”。“完成的定义”包括验收这个改进项的明确的验收标准，用于在下一次的Sprint评审中验收这个故事。它们包括：

9.结论

通过实施和执行以上所有九种模式，团队可以显著提升提前完成Sprint的能力。这使他们能够从产品待办列表中提取更多的待办项到Sprint中。这样团队的速度就会得到提升，为“昨日的天气”建立更高的基线，并为下一个Sprint做好准备。提前完成的团队也更能拥有更高的幸福感，因为他们对自己完成Sprint的能力充满信心。这引发了持续改进的良性循环，最终达成超高效能。

对于没有尝试过这些模式的人来说，这些模式看起来并不那么顺理成章，但是它们确实能产生意外的积极结果。因此，建议所有团队尝试这些模式，尤其是结合在一起使用以验证它们是否有助于提高团队的绩效、质量和幸福感。

10.参考资料

[1] K. Schwaber and J. V. Sutherland, Software in 30 days : how agile managers beat the odds, delight their customers, and leave competitors in the dust. Hoboken, N.J.: John Wiley & Sons, Inc., 2012.

[2] M. Fowler and J. Highsmith, "The Agile Manifesto," Dr. Dobbs, July 13 2001.

[3] M. Beedle. (2010, June 15). Mike Beedle on the Early History of Scrum. Available: http://scrum.jeffsutherland.com/2010/08/mike-beedleon-early-history-of-scrum.html

[4] M. Beedle, M. Devos, Y. Sharon, K. Schwaber, and J. Sutherland, "Scrum: A Pattern Language for Hyperproductive Software Development," in Pattern Languages of Program Design. vol. 4, N. Harrison, Ed., ed Boston: Addison-Wesley, 1999, pp. 637-651.

[5] J. O. Coplien and N. Harrison, Organizational patterns of agile software development. Upper Saddle River, NJ: Pearson Prentice Hall, 2005.

[6] G. Bjornvig, J. Coplien, and J. Ostergaard, Scrum Tuning Using Organizational Patterns: Scrum Foundation, 2010.

[7] ScrumPloP. (2013). Scrum Pattern Community. Available: http://scrumplop.org

[8] K. Schwaber and J. Sutherland, "The Scrum Guide: The Definitive Guide to Scrum, The Rules of the Game," in Software in 30 Days, ed: John Wiley & Sons, 2011.

[9] J. Sutherland and K. Schwaber, The Scrum Papers: Nuts, Bolts, and Origins of an Agile Method. Boston: Scrum, Inc., 2007.

[10] M. Cohn, User Stories Applied : For Agile Software Development: Addison-Wesley, 2004.

[11] J. Sutherland, A. Viktorov, J. Blount, and N. Puntikov, "Distributed Scrum: Agile Project Management with Outsourced Development Teams," presented at the HICSS'40, Hawaii International Conference on Software Systems, Big Island, Hawaii, 2007.

[12] J. Sutherland, G. Schoonheim, and M. Rijk, "Fully Distributed Scrum: The Secret Sauce for Hyperproductive Offshored Development Teams," in Agile 2008, Toronto, 2008.

[13] C. Jones, "Development Practices for Small Software Applications," Software Productivity Research 2007.

[14] C. R. Jakobsen and J. Sutherland, "Scrum and CMMI Going from Good to Great," in Agile Conference, 2009. AGILE '09., 2009, pp. 333-337.

[15] J. Sutherland, S. Downey, and B. Granvik, "Shock Therapy: A Bootstrap for Hyper-Productive Scrum," in Agile Conference, 2009. AGILE '09., 2009, pp. 69- 73.

[16] J. Sutherland and I. Altman, "Take No Prisoners: How a Venture Capital Group Does Scrum," in Agile 2009, Chicago, 2009.

[17] J. Sutherland. (2013). Teams that Finish Early Accelerate Faster. Available: https://sites.google.com/a/scrumplop.org/publishedpatterns/retrospective-pattern-language/teams-thatfinish-early-accelerate-faster

[18] P. L. o. G. Process. (2013). What is a Pattern Language? Available: http://grouppatternlanguage.org/What_is_a_Pattern_L anguage

[19] J. Coplien. (1995). Generative Pattern. Available: http://c2.com/cgi/wiki?GenerativePattern

[20] J. R. Hackman and D. Coutu. (2009) Why Teams Don't Work. Harvard Business Review.

[21] J. R. Hackman, Leading Teams: Setting the Stage for Great Performances. Cambridge: Harvard Business Review Press, 2002.

[22] J. O. Coplien, "Borland Software Craftsmanship: A New Look at Process, Quality and Productivity," in 5th Annual Borland International Conference, Orlando, FL, 1994.

[23] J. Sutherland, "Future of Scrum: Parallel Pipelining of Sprints in Complex Projects," presented at the AGILE 2005 Conference, Denver, CO, 2005.

[24] B. Sullivan and H. Thompson, "Gray Matter: Brain, Interrupted," in New York Times, ed. New York City: New York Times Company, 2013.