转载

与Jeff Sutherland谈敏捷领导力

在 GOTO阿姆斯特丹2015大会上，Jeff Sutherland谈了敏捷领导力。InfoQ对他进行了采访，内容涉及：大型组织在采用Scrum时面临的问题；他们该如何提高处理障碍、提升敏捷领导力的能力；Scrum大师能做些什么来帮助组织变得敏捷；对实施Scrum的组织的管理人员的建议。

InfoQ：您在实施Scrum的大型组织见过什么样的问题？

Sutherland：问题非常大，但可以归结为一个。领导者需要变得敏捷。他们需要支持团队、清除障碍以及培训组织让它变得敏捷。现如今，受过培训并擅长此道的管理者非常少，许多公司都将被他们的敏捷竞争对手排挤出市场。

InfoQ：您说“扩展框架常常用于为传统组织提供脚手架，直到他们演化成敏捷组织。您可以详细解释下这句话的意思吗？

Sutherland：可以阅读下哈弗大学Kotter教授的著作。他认为，当公司认识到他们正在实现两套完全不同的操作系统时，不同的规则，不同的管理，不同的工作方式，他们才可能会取得成功。旧的管理层级不能一次全部改变。这就好比说Windows。他们需要敏捷的工作方式完成新产品的开发。这就好比说Mac。

公司希望将当前的管理层级（Windows）运行在新的敏捷操作系统（Mac）之上。为了实现从Windows到Mac的过程调用，他们引入了一个转换层（SAFe），这会降低速度，而且看起来有些奇怪，但可以使他们熬过这个时期，直到管理层弄清楚了如何取得一些真正的敏捷领导力。

这并不是最好的方式。就像Ken和我在我们合著的《 Software in 30 Days 》中所说的那样，公司需要在“卓越中心（a center of excellence）”实现真正的Scrum，那里有真正的敏捷领导力，而不涉及意义不大的旧式瀑布模型。这会使他们的业绩更为突出。

InfoQ：由于越来越多的大型组织采用Scrum，所以扩展需求与日俱增。组织该如何扩展Scrum，您能给些建议吗？

Sutherland：按照设计，Scrum可以像生物系统一样生长。为了创造一个婴儿，你需要一个良好的细胞，然后复制。如果细胞不好，就会有大量的问题。因此，我们面临的挑战是首先让一个团队成功使用，然后其它团队复制这种模式。虽然规模在增长，但是大规模Scrum遵循同小规模Scrum一样的基本原则。如果不是那样，你就往系统里引入了浪费。你将增建器官系统，就像人体一样，每个部分都有特定的功能，并需要接受一些培训，学习如何处理跨团队协作，如何将障碍升级给高级管理层，以及如何避免引入不必要的团队，那会损害绩效，搅乱整个组织。

我们已经发表了几篇论文，证明恰当的扩展Scrum可以实现全局速率的线性增长，这在以前的软件开发中是不曾见过的。不过，你要真正的用好了Scrum才能做到这一点。

InfoQ：您提到，组织需要处理来自团队的障碍，并且确保它们会被提交到可以处理它们的组织层面。您能举个例子吗？组织如何提高他们处理障碍的能力？

Sutherland：组织需要一个“执行行动小组（Executive Action Team，EAT）”，其中包含高层领导。例如，在John Deere，EAT要求每位Scrum Master至少每三个冲刺就要向最高层报告一个障碍，否则Scrum Master将被替换。这让他们生产农用设备的效率提高了8倍。

InfoQ：您提到，在实施大规模Scrum时，敏捷领导力扮演一个非常重要的角色。您能解释下是为什么吗？组织该如何提高领导力？

Sutherland：领导者需要成为敏捷教练。令人震惊的是，他们中的大部分人都相去甚远。而且，他们中的大部分都没有采取任何措施，直到为时已晚，他们的公司像诺基亚一样倒掉。

InfoQ：在您看来，Scrum Master如何帮助团队变得敏捷？

Sutherland：实现真正的Scrum。这是因为，真正的Scrum会带来真正的效果，而不是大部分公司实现的半生不熟的Scrum。在一个冲刺结束的时候，没有可以工作的产品，那样的Scrum是失败的Scrum。在硅谷，80%的扩展Scrum都是那种类型。它们“只是名义上的敏捷”。

InfoQ：您想给实施Scrum的组织的管理层提些什么建议？

Sutherland：进行适当的培训，确保团队由专家教练组建，并在内部创立卓越的教练技术。这要在具有敏捷领导力的卓越中心里进行，而不受旧式瀑布模型条条框框所支配。其次，开发可以周期性地测量实施状态的指标。对教练而言，单个Bug修复时长（应该少于24小时）和单个故事流程效率（实际工作时间与日历时间的比值应该大于50%）是两个最重要的指标。它们中的任何一个都可以将团队速率加倍。它们两个能将团队速率提升到原来的4倍。关于详细的指标，你可以在scruminc.com免费下载我们发表在IEEE论文库里的论文。