【本文翻译自felipecastro.com】
尽管看起来似乎有相同的理念，但许多公司都在努力适应OKR和Agile。使用敏捷的团队经常抵制采用OKR，因为OKR对他们而言似乎是多余的。
这场斗争的根源是对OKR和敏捷本身的误解。如果使用正确，OKR和敏捷会是强大的组合。他们可以创建价值驱动的团队，并改变组织的工作方式。
我在一些世界领先的出版物和会议中一直在谈论OKR和敏捷。本文总结了我所学到的知识。
功能工厂（The Feature Factory）
敏捷的创建是为了交付软件。它是用于管理软件项目的瀑布式开发的替代方法，它专注于管理可交付成果（故事或功能）[deliverables (stories or features)]而不是价值（业务成果）[value (business outcomes)]。
实际上，敏捷中没有一个单一的仪式（ceremony）可以跟踪结果。
敏捷宣言本身具有误导性，因为它告诉人们度量可交付成果。第七项原则指出：“可工作的软件是进度的主要衡量标准（Working software is the primary measure of progress）。
所有可工作的软件都是有价值的假设显然是错误的。有些项目会带来价值，而另一些则不会。用户会使用一些功能，但其他功能可能无人问津。
大多数组织都陷入“功能工厂”模式。团队没有专注于创造价值。正如约翰·卡特勒（John Cutler）所说，开发人员“ 只是坐在工厂里，制定功能，然后将其发送出去”。
Marty Cagan强调了功能工厂的可怕后果：
团队只是在那里充实细节、代码和测试。他们对外部的环境几乎一无所知，甚至不相信这些实际上是正确的解决方案。
[他们]很少考虑这些功能是否真正解决了潜在的业务问题。他们根据产出（output）而不是成果（outcome）来衡量进度。”
声明发布15年后，大多数公司仍将敏捷仅用于交付。扩展框架通常无济于事。他们选择了阻力最小的方法，并专注于改善软件开发。因此，很少有组织能够实现业务敏捷性（business agility）。
敏捷交付（Delivery Agile）
我喜欢将组织视为五层架构。它们是文化（Culture），战略（Strategy），战术（Tactics），运营（Operations）和目标（Goals）。
目标渗透到所有其他层面，因为它们反映了公司的运作方式和行为方式。
传统公司的组织架构如下：
在传统架构中，各层的情况是：
1.文化是自上而下、命令与控制式的。
2.战略使用年度静态计划。
3.目标遵循瀑布式方法。
4.战术需要很大的赌注和较长的反馈周期。
5.运营使用瀑布式的开发和项目管理。
当公司采用敏捷时，通常会使用敏捷交付。它们仅替换架构的最底层：
敏捷交付仅在运营层使用精益和敏捷。当团队进行分散的实验时，敏捷取代了瀑布开发。瀑布开发不存在实验文化，尽管多少采用了一些A/B测试，但许多高风险的假设仍然未经测试。
由于其他层在敏捷交付中保持不变，因此其收益较小。瀑布式的遗留问题与组织敏捷性直接冲突。
瀑布目标（Waterfall Goals）
在设定目标时，瀑布式思维仍然是常态。组织使用年度自上而下的过程来创建一组静态目标。这与敏捷直接冲突。
瀑布式目标遵循静态规划模型。通常，这是从管理人员制定年度公司目标的务虚会开始的。然后目标在整个组织中级联，从而制定了年度固定计划。
您能想到比层叠瀑布（top-down waterfall）更自上而下的瀑布类比吗？
静态模型有几个假设：
1.我们可以预先详细定义计划的所有步骤；
2.该计划的绝大多数将是正确的；
3.市场状况将基本保持不变；
4.变化将很小。我们将在今年年中进行审核。然后，我们将创建更新的详细静态计划。
瀑布式目标是基于项目的（WATERFALL GOALS ARE PROJECT-BASED）
更糟的是，瀑布式目标并不注重价值（value）。他们围绕着管理层批准的一系列项目（projects）展开工作。
弗雷德里克·泰勒（Frederick Taylor）高兴地看到他的教义至今仍在使用。他写道：“每个工人的工作都至少提前一天由管理层全面计划，”。
在泰勒主义的敏捷方法中，团队存在的目的是为了交付项目。高管以真正的功能工厂的方式计划工作。这种模式拖慢了公司的发展速度，让他们更难适应，并增加了风险和浪费。
大多数(如果不是全部的话)扩展框架都在敏捷交付中工作。它们是精心设计的方法，专注于使用敏捷来交付瀑布式计划。
从静态到动态计划（FROM STATIC TO DYNAMIC PLANNING）
静态模型的追随者就像克里姆林宫的中央计划者，他们创建了自上而下的5年计划，相信自己可以预测未来。
相反，动态计划包含变化。它在迭代模型中以较小的计划周期工作。动态计划假设市场条件和计划本身将发生变化。不仅如此，我们对问题的理解将随着我们的学习而发展，我们的计划必须反映这一点。
正如肯特·贝克（Kent Beck）所说：“如果你什么都没学到，那就只能按计划进行了。”
您希望团队在短迭代中工作并检验假设。那么，你怎么能使用克里姆林宫设计的瀑布式流程中定义的一组静态目标呢?
你不能。因此，尽管我们在交付时使用敏捷，但在其他任何事情上我们都使用瀑布。这种情况需要改变。
全栈敏捷（Full-Stack Agile）
为了实现业务敏捷性（business agility），公司必须采用全栈敏捷（Full-Stack Agile）。他们必须替换传统组织架构的所有层：
在全栈敏捷中，各层变化为：
- 文化的基础是创建与团队一致的自治。它不控制详细的计划，而是遵循使命的原则。领导者“指定最终状态、目的和尽可能少的约束。”
- 战略是数据驱动的，迭代的，并专注于验证假设。
- 目标使用OKR（目标和关键结果）遵循敏捷模型。
- 战术是在短反馈周期内进行安全失败的实验。
- 运营使用敏捷开发。
重构组织债务（REFACTORING THE ORGANIZATIONAL DEBT）
技术债务是大多数工程师都能理解的问题。团队通过走捷径获得技术债务，这使得代码更难修改，并且无法扩展。技术债务将在以后支付，并附带利息。
要解决技术债务，您必须重构代码。这在不添加新功能的情况下改进了内部结构。
渗透到敏捷交付中的瀑布式遗留产生了组织债务。而且就像它的同胞一样，它让公司更难改变，而且还要支付利息。
要成为全栈敏捷，公司必须解决组织债务。他们必须重构架构的所有层。但这说起来容易做起来难，因为许多人都尝试过，但都失败了。最好的方法是什么？
从“思维模式”到“管道”（FROM “MINDSET” TO “PLUMBING”）
敏捷社区中的许多人都认为，唯一的解决方案是专注于思维方式的转变。似乎我们可以改变组织的思维方式，所有的问题都会消失。事实上，一些名人在一次会议上穿着一件T恤，上面写着“敏捷就是思维模式（Agile is Mindset）”。
仅关注思维模式的改变可能是有害的，因为这是不可行的。戴夫·斯诺登（Dave Snowden）写道：“思维模式似乎正在取代'价值观'和'使命'，成为避免陈词滥调的最新行动”。
另一种选择是专注于改变公司行为的实际行动。
正如斯坦福大学的James March提醒我们的那样：“领导力不仅包含优雅的气质（poetry），还包括管道（plumbing）。” 尽管“优雅的气质”很重要，但大多数组织却忘记了管道：它们的系统和过程。更换水管通常很麻烦并且需要时间，但这是值得的。
有一种用于业务敏捷的工具可以更改“组织管道（organizational plumbing）”。该工具叫做OKR（目标和关键结果），是Google和Spotify等公司使用的目标框架。
与传统的规划方法的最大区别是什么？OKR 经常被设置和评估——通常每季度一次。此外，OKR是双向的，而不是将组织级联下来。团队根据公司目标创建自己的OKR，然后与经理一起评估他们。
这种方法为团队提供了一个更吸引人的环境。他们觉得应该要对自己给自己设定的目标负责，并每周快速跟踪一次。
如果使用正确，OKR可以使组织成为全栈敏捷。
建立价值驱动的团队（CREATING VALUE-DRIVEN TEAMS）
成为全栈敏捷的关键是专注于价值。挑战在于，该系统已经被优化过，能够交付高管计划的任务。不幸的是，敏捷还针对交付进行了优化，创建了功能工厂模型。
这种对交付的痴迷由来已久。它从使用工作软件来衡量进度开始，并一直持续到今天。毕竟，正如Jeff Sutherland（Scrum创始人）的书名所说，Scrum是“在一半时间内完成两倍工作的艺术”。
看板中缺少一列：“行得通吗？”，如John Cutler的插图所示：
“完成”只有在增加价值时才重要。
实际上，不能改进指标的功能可能会产生负回报。新代码可能会有bug，需要维护，产品也会更加复杂。
尽管《宣言》具有误导性，但其中一位作者写道：
“ [击败]瀑布的关键是要认识到敏捷专家重视
成果（Outomes）胜于功能（Features）。功能列表（feature list）是一个有价值的工具，但这不是目的。真正重要的是整体结果（overall outcome），我认为这是对客户的价值。”
——Martin Fowler（重构一书作者）
你为什么要做这个？（WHY ARE YOU WORKING ON THAT?）
Henrik Kniberg关于推动每个团队的因素有很好的幻灯片：
第一个选项表示功能工厂。假设团队没有能力决定要构建什么。他们做某件事是因为有人告诉他们这样做。它遵循泰勒主义的计划与行动分离的原则。它既让人失去动力，又无法推动创新。
第二种方法是另一种极端，在这种情况下，团队只为了“他们喜欢”而工作。
第三种选择是价值驱动团队。一个专注于交付价值并了解如何产生影响的团队，他们有一个明确的目标，并且在工作与公司战略之间有着清晰的视野。
正确使用OKR的方法（THE PROPER WAY TO USE OKR）
像其他工具一样，OKR可能会被滥用，变成一个待办事项列表。但是，如果你想要关注于价值，你的目标必须反映这一点。你必须使用基于价值的关键结果：
价值就像开玩笑：你不需要告诉对方它是好是坏。
基于价值的OKR并非只是衡量结果。您必须了解什么对您的客户和组织是有价值的。
以下示例显示了两种关键结果（Key Results）之间的区别：
当您将敏捷与基于活动的关键结果（Activity-based Key Results）一起使用时，会产生摩擦。敏捷团队已经有了路线图，那为什么他们需要OKR？每次我遇到努力将OKR和敏捷联系起来的团队时，他们都专注于活动。
使用基于价值的OKR（Value-based OKRs）可以带来变革。它可能是敏捷与精益之间缺少的环节。可以弥合产品（product）与工程（engineering）之间的差距。
改变语言（CHANGING THE LANGUAGE）
甚至敏捷使用的术语也关注交付。我们需要放弃一些概念，比如“完成定义（definition of done）”、“烧尽图（burn-down charts）”和“速率（velocity）”。相反，我们需要关注于价值。我们需要的不是验收标准（acceptance criteria），而是成功标准（success criteria）——OKR。
从意见到数据（From Opinions to Data）
驱动独立敏捷的不是数据。这是HiPPO：最高薪人士的意见（Highest Paid Person’s Opinion）。《How Google Works》一书中很好地说明了这一概念：
敏捷背后存在一个错误的假设。该模型基于利益相关者告诉团队需要完成的工作，然后审查工作。
Ron Jeffries描述了与利益相关者（重点是我的）的假设对话：
“每周您都会告诉我们[……]对你来说什么是最重要的，我们会告诉你我们觉得可以完成什么。”一周后，你就有了[……]，如果你想[……]，你可以把它交付出去。”
利益相关者按照泰勒主义的模型来决定做什么以及是否可以交付。假定他们知道什么是有价值的，他们的意见是对实际价值的衡量。
但数据显示并非如此。例如，Ron Kohavi发表的一篇论文分析了微软一系列想法的结果。只有1/3的人在期望的指标上产生了统计上显著的积极变化。
敏捷不是收集数据并衡量什么是有效的，而是询问HiPPO构建什么。他们有66%或更多的误差。
许多公司仍在使用“客户的声音（voice of the customer）”模型。在此模型中，有人代表最终客户。在过去很难收集数据的情况下，这是有道理的。但现在，它只是瀑布的又一个残留物。
用实验代替HIPPO（REPLACING HIPPOS WITH EXPERIMENTS）
事实上，团队并不需要有人来代表客户。他们可以采访客户，衡量他们的行为。OKR可以通过允许团队以学习和迭代的实验来代替HIPPO。
如Barry O'Reilly所述，它使团队能够采用假设驱动开发（Hypothesis-Driven Development）：
- 我们认为 < 这项能力 >，
- 将导致 < 这个结果 >，
- 当 <我们看到一个可度量的信号> 时，我们将有信心继续前进。
在这个模型中，评审不再是关于显示可交付成果的。团队使用评审来讨论度量标准和主要假设，以改进它们。
启用自治（Enabling Autonomy）
命令与控制仍在这里。
指挥和控制的思想仍然渗透在敏捷交付中。利益相关者决定要构建什么。结果，“因为Sam说……”团队就开始做某件事，“当Sam觉得可以的时候”就会停止。
你需要整个团队的贡献。因此，他们需要了解业务问题，并对构建什么有发言权。正如Marty Cagan所写，“如果你只是用你的工程师来编码，你只能得到他们一半的价值。”
为了使团队能够自治，您需要给他们自由来决定如何实现期望的结果。团队的宗旨必须改变:
| 功能工厂的宗旨 | 价值驱动团队的宗旨 |
|---|---|
| 提供利益相关者想要的功能 | 实现商定的基于价值的OKR。 |
正如Mary Poppendieck写道：
也许敏捷开发实践的最大缺点是团队决定做什么的方式。很长一段时间以来，回答这些问题都不被认为是团队的责任。
团队不必执行由利益相关者构想的瀑布计划。他们可以使用双轨敏捷（dual track Agile）和设计冲刺（design sprints）发现有价值的产品。
OKR的其他材料
- 使用OKR（目标和关键结果）制定敏捷的目标
- 使用现代敏捷和OKR超越“功能工厂”的思维定势