在 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 论文库里的论文。
评论