倾听敏捷转型的专家建议

敏捷转型建议

敏捷建议

使用OKR修复Scrum的“局部敏捷”

许多公司都在挣扎地尝试将OKR和敏捷开发适配在一起,尽管两者似乎有着相同的理念。使用敏捷开发的团队通常拒绝采用OKR,因为OKR对他们来说是多余的。

 

这种艰难的根源是对OKR和敏捷开发本身的误解。如果使用得当,OKR和敏捷开发是一个强大的组合。他们可以创建价值驱动的团队,并改变组织的工作方式。

 

我一直在一些世界领先的出版物和会议上谈论OKR和敏捷开发。这篇文章总结了我的经验。

 

 

功能工厂

 

敏捷开发是为交付软件而创建的。它是用于管理软件项目的,替代传统的瀑布式开发方法。它专注于管理可交付成果(故事或功能),而不是价值(业务结果)。

 

事实上,敏捷开发中没有一个跟踪结果的仪式。

 

“敏捷宣言”本身具有误导性,因为它告诉人们衡量可交付成果。第7条原则指出:“可以工作的软件是进度的主要衡量标准”。

 

所有可工作的软件都有价值的假设显然是错误的。有些项目会带来价值,而另一些则不会。用户将采用某些功能,而其他功能将失败。

 

大多数组织都停留在“功能工厂”模式中。团队不关注交付价值。正如约翰.卡特勒所描述的那样,开发人员“只是坐在工厂里,开发功能,然后将它们从生产线发货出去”。

 

马蒂·卡根强调了功能工厂的可怕后果:

 

“团队只是在那里充实细节、编写代码和测试。他们对更大的背景知之甚少,更不相信这些实际上是正确的解决方案。”

 

“他们很少考虑这些功能是否真的解决了潜在的业务问题。他们用产出而不是结果来衡量进展。”

 

在敏捷宣言发表15年后,大多数公司仍然只将敏捷开发用于软件交付。“大规模敏捷”框架通常通常没有帮助。他们走阻力最小的道路,专注于改进软件开发。因此,很少有组织能够实现业务敏捷性。

 

 

交付敏捷

 

我喜欢把组织想象成一个有五层的堆栈。它们是文化、战略、战术、运营和目标。

 

 

目标弥漫到所有其他层,因为它们反映了公司的工作方式和行为。

 

传统公司的组织堆栈如下:

 

 

在传统的组织堆栈中,各层分别是:

1. 文化是自上而下,命令和控制。

2. 战略使用年度静态计划。

3. 目标遵循瀑布方法。

4. 战术采用大赌注和较长的反馈周期。

5. 运营使用瀑布式开发和项目管理。

 

通常,当公司采用“敏捷开发”模型时,他们实现的是“交付敏捷”(仅在软件交付/任务交付层/运营层 实现敏捷)。它们只是替换了堆栈的底层:

 

 

“交付敏捷”仅在运营层使用精益和敏捷。“敏捷开发”取代了瀑布开发,而团队则进行散乱的实验。实验文化不存在。虽然会进行一些A/B测试,但许多高风险假设仍未经过测试。

 

由于“交付敏捷”中的其他层保持不变,其整体收益较小。其他层遗留的瀑布与组织的敏捷性之间有直接的冲突。

 

 

瀑布式的目标

 

说到设定目标时,瀑布思维模式仍然是常态。组织使用每年一次的、自上而下的过程来创建一组静态目标。这与敏捷是直接冲突的。

 

瀑布式目标遵循静态规划模型。通常,它从高管们制定公司年度目标的务虚会开始。然后,目标在组织中级联(层层分解),为这一年创建一个固定的计划。

 

你能想出一个比级联(层层分解)更像自上而下的瀑布的事物吗?

 

静态规划模型有几个假设:

1. 我们可以提前详细定义计划的所有步骤;

2. 该计划的绝大部份是正确的;

3. 市场条件将基本保持不变;

4. 变化会很小。我们将在年中评审时处理它们。然后,我们将创建一个更新后的详细静态计划。

 

 

瀑布式目标是基于项目的

 

更糟糕的是,瀑布式目标不关注价值。它们围绕管理层批准的一组项目展开。

 

弗雷德里克·泰勒会很高兴看到他的教义今天仍在使用。他写道:“管理层至少提前一天全面计划每个工人的工作。”

 

在泰勒主义的敏捷方法中,团队的存在是为了交付项目。高管们以真正的功能工厂方式规划工作。这种模式减缓了公司的速度,使它们更难适应,并增加了风险和浪费。

 

大多数(如果不是全部的话)大规模敏捷框架也是用于“交付敏捷”。它们是专注于使用敏捷开发来交付瀑布式计划的复杂方法。

 

 

从静态规划到动态规划

 

静态规划模型的追随者就像100年前的工业公司的高管,他们制定了自上而下的长期计划,相信他们可以预测未来。

 

相比之下,动态规划拥抱变化。它在迭代模型中以较小的规划周期工作。动态规划假设市场条件和计划本身将发生变化。更重要的是,我们对问题的理解将随着我们的学习而发展,我们的计划必须反映这一点。

 

正如肯特·贝克所写的那样:“按照计划进行这一切的唯一方法是你什么都不学。”

 

您希望团队在短周期的迭代中工作并测试假设。那么,您怎么能使用瀑布流程定义的一组静态目标呢?

 

你不能。因此,尽管我们使用“敏捷开发”模型进行交付,但我们正在使用瀑布模型进行其他一切。这需要改变。

 

 

全栈敏捷

 

为了实现业务的敏捷性,公司必须是全栈敏捷的。必须用敏捷替换传统组织堆栈的所有层:

 

 

在全栈敏捷中,各层发生了变化:

- 文化的基础是建立与团队对齐的自主权。代替管控详细计划的是,遵循使命原则。领导者“设定最终状态、目的和最少的约束。”

- 战略是数据驱动的、迭代的、专注于验证假设。

- 目标遵循敏捷模型,使用OKR(目标和关键结果)。

- 战术以短的反馈周期进行可以“安全失败”的实验。

- 运营使用敏捷开发。

 

 

重组组织债务

 

技术债务是大多数工程师理解的问题。团队因为走了捷径而获得技术债务。这使得代码更难更改,也无法伸缩。技术债务以后要偿还,而且有利息。

 

要修复技术债务,您必须重构代码。在不添加新功能的情况下改善内部结构。

 

弥漫到交付敏捷的“遗存的瀑布”造成了组织债务。就像它的兄弟技术债务一样,它使公司更难改变,改变时需要支付利息。

 

要成为全栈敏捷公司,公司必须修复组织债务。他们必须重构堆栈的所有层。但这说起来容易做起来难,因为许多人都尝试过,但失败了。最好的方法是什么?

 

 

从“观念”到“管道系统”

 

敏捷社区的许多人认为,唯一的解决方案是专注于观念转变。似乎我们可以只是改变组织的观念,所有问题都会消失。比如,几位名人在一次会议上穿着一件写着“敏捷就是观念”的T恤。

 

仅仅关注转变观念可能是有害的,因为它不可操作。戴夫•斯诺登写道:“‘观念’似乎正在取代‘价值观’和‘使命’,成为避免陈词滥调的最新行动。”

 

另一种选择是专注于改变公司行为方式的实际行动。

 

正如斯坦福大学的詹姆斯·马奇提醒我们的那样,“领导力既包括管道,也包括诗歌。”虽然“诗歌”很重要,但大多数组织忘记了管道:他们的系统和流程。更换管道通常很麻烦,需要时间,但这本身是有回报的。

 

有一个业务敏捷工具可以改变“组织管道”。该工具是OKR(目标和关键结果),这是谷歌和Spotify等公司使用的目标框架。

 

与传统规划方法有很大区别?OKR要经常设置和评估——通常是每季度一次。此外,OKR不是自上而下组织的,而是双向的。团队根据公司目标创建OKR,然后与经理一起为OKR工作。

 

这种方法为团队提供了一个更吸引人的环境。他们现在对自己帮助设定的目标感到有责任,并在以周为单位的快速周期中跟踪这些目标。

 

如果使用正确,OKR可以使组织成为全栈敏捷。(嗨马OKR软件就是将OKR与敏捷开发方法Scrum组合在一起了,实现全栈敏捷。)

 

 

创造价值驱动的团队

 

 

成为全栈敏捷的关键是专注于价值。面临的挑战是,公司系统是为交付高管计划的任务而优化的。不幸的是,敏捷开发也针对软件交付进行了优化,创建了功能工厂模型。

 

这种对软件交付的痴迷根深蒂固。它从使用“可以工作的软件是进度的主要衡量标准”这一敏捷原则开始,一直持续到今天。正如杰夫.萨瑟兰的书《敏捷革命》的标题所言,Scrum毕竟是“在一半时间内完成两倍工作的艺术”。

 

看板缺少了一栏:“它有用吗?”正如约翰·卡特勒的插图所示:

 

 

“完成”只有在增加价值时才重要。

 

事实上,不能改善指标的软件功能可能会产生负收益。新代码可能存在缺陷,需要维护,产品也会更加复杂。

 

尽管敏捷宣言具有误导性,但其中一位作者写道:

 

“[击败]瀑布的关键是认识到,敏捷人员重视结果而不是功能。功能列表是一个有价值的工具,但它是一种手段,而不是目的。真正重要的是整体结果,我认为这是对客户的价值。”马丁·福勒

 

 

你为什么要这么做?

 

Henrik Kniberg有一张很棒的幻灯片,说明了是什么驱动着每个团队:

 

 

第一个选项代表功能工厂。其假设是,团队没有能力决定要构建什么。他们做某事是因为有人(“山姆”)告诉他们去做。它遵循计划和行动分离的泰勒主义原则。这既令人沮丧,又无法推动创新。

 

第二个选项是另一个极端,团队只出于“他们感觉喜欢”而做某件事。

 

第三个选项是价值驱动的团队。一个专注于交付价值并了解他们如何产生影响的团队。他们有明确的目的,在他们的工作和公司战略之间有清晰的视线。

 

 

使用OKR的正确方法

 

像任何其他工具一样,OKR可能会被滥用,成为待办事项列表。但是,如果你想专注于价值,你的目标必须反映这一点。您必须使用基于价值的关键结果:

 

基于价值的OKR不仅仅是衡量结果。你必须了解什么对你的客户和组织有价值。

 

以下示例显示了两种关键结果(基于活动的和基于价值的)之间的区别:

 

 

当您将“敏捷开发”与“基于活动型”的关键结果一起使用时,它会产生冲突。敏捷开发团队已经有了路线图,那么他们为什么需要OKR?每次我遇到挣扎于将OKR和敏捷开发连接起来的团队时,他们都在使用“基于活动型”关键结果。

 

使用基于价值的OKR可以带来变革。这可能是敏捷开发和精益之间缺失的一环。可以填补产品和工程之间的鸿沟。

 

 

改变语言

 

甚至敏捷开发使用的术语也专注于交付。我们需要放弃“完成的定义”、“燃尽图”和“速度”等概念。相反,我们需要专注于价值。我们需要“衡量成功”的标准,而不是“衡量工作成果可接受”的标准,我们需要使用“OKR”。

 

 

从意见到数据

 

单独使用敏捷开发方法时,驱动业务的不是数据,而是薪酬最高的人的意见。《重新定义公司-谷歌时如何运营的》一书很好地说明了这一概念:

 

 

 

敏捷开发背后有一个有缺陷的假设。该模型基于:利益相关者告诉团队需要做什么,然后审查团队的工作。

 

罗恩·杰弗里斯描述了与利益相关者的假想的对话:

 

“每周你都会告诉我们什么对你来说最重要,我们会告诉你我们认为我们可以实现什么。一周后,你拿到了它。[...]如果你想的话,你可以把它发布出去。”

 

按照泰勒主义模式,利益相关者决定该做什么以及工作成果是否会交付给客户。假设是,利益相关者知道什么是有价值的,利益相关者的意见是衡量实际价值的尺度。

 

但数据显示,情况并非如此。例如,Ron Kohavi发表的一篇论文分析了微软一系列想法的结果。只有三分之一的想法在统计学上产生了显著的积极变化。

 

敏捷开发没有收集数据和衡量什么有效,而是询问薪酬最高的人要构建什么。他们的误差幅度为66%或以上。

 

许多公司仍在使用“客户之声”模式。在这个模型中,有人代表最终客户。过去,当收集数据很困难时,这是有道理的。但现在这只是另一个瀑布残留。

 

 

用实验代替薪酬最高的人的意见

 

事实是,团队不需要有人作为客户的声音。他们可以与客户互动并衡量客户的行为。OKR可以用“允许团队学习和迭代的实验”取代“薪酬最高的人的意见”

 

它使团队能够采用假设驱动的开发,如Barry O’Reilly所述:

 

我们相信……

这将导致……

我们有信心在……情况下继续进行

 

在这个模型中,评审会的内容不再是展示可交付的工作成果。团队使用评审会来讨论指标和改进它们的主要假设。

 

 

赋能自主

 

命令和控制仍然在这里。

 

命令和控制心态仍然渗透到交付敏捷中。利益相关者决定建造什么。因此,团队忙于做一件事“因为这是Sam说的”,并在“当Sam同意工作成果时”停止做这件事。

 

你需要你团队的充分贡献。因此,他们需要了解业务问题,并对构建什么有发言权。正如Marty Cagan所写的那样:

 

“如果你只是使用工程师编写代码,你只能得到他们价值的一半。”

 

为了能让团队实现自主,您需要让他们自由决定如何实现预期的结果。团队的目的必须改变:

 

功能工厂的目的:交付利益相关者想要的功能

价值驱动团队的目的:实现商定的基于价值的OKR。

 

 

正如Mary Poppendieck所写的那样:

 

“也许敏捷开发实践的最大缺点是团队决定做什么的方式。很长一段时间以来,回答这些问题都不是团队的责任。”

 

团队不必实施利益相关者构想的瀑布计划。他们可以使用双轨敏捷和设计冲刺发现有价值的产品。

 

本文翻译自felipecastro.com,转载请注明译文来自于hmokr.com

 

logo2x6.png
嗨马OKR软件是摩卡软件的自主版权产品。本网站中部分摄影照片版权属于Unsplash
© 2022, 摩卡软件

Search