许多公司都在挣扎地尝试将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