OKR与敏捷开发的原理有着相似之处，但已经使用敏捷的团队再用OKR感觉会显得多余。这种误解的根源就在于对这两种模式不够了解，运用得当的情况下，OKR和敏捷可以形成强强联合的效果，他们可以创造出以价值为驱动的团队，改变团队的工作方式。
本文最后一部分分析了OKR的正确使用方法，以及如何赋予团队更多自主权。
回顾第一部分请点这里：系列文章｜OKR与敏捷（一）：瀑布式目标与敏捷的冲突
回顾第二部分请点这里：系列文章｜OKR与敏捷（二）：实现全栈敏捷
使用OKR的正确方式
与其他工具一样，OKR也可能会被滥用并沦为待办事项列表。但如果你想要专注于价值实现，那么你的目标就必须要体现这一点。因此你需要设定价值导向的关键结果：
价值就像讲笑话：你没法告诉对方它到底好不好。
价值导向的OKR不仅仅衡量结果。你还需要明白对你的客户和公司来说，什么样的结果才是有价值的。
下面的例子展示了两种关键结果的差别：
在敏捷中使用行为导向的关键结果会产生摩擦。既然敏捷团队已经有了明确的路线图，为什么他们还需要OKR呢？我遇到的所有尝试将OKR与敏捷相结合的团队，都在专注于开发活动本身。
使用价值导向的OKR能够带来变革，它可以成为连接敏捷和精益的桥梁，弥补产品和开发之间的空白。
改变侧重点
尽管敏捷使用的命名法专注于交付。我们也需要抛开一些概念，比如“完工、燃尽图、速度”。
与之相反的，我们应该专注于价值。我们不需要验收标准，需要利用OKR来定义成功的标准。
从意见转变为数据
敏捷并不是独立的数据驱动，而是HiPPO（HighestPaid Person’s Opinion）模式，即听从薪酬最高者的意见。
《谷歌的经营之道》一书生动形象地描述了这个模式：
这种敏捷模式下隐藏着一个巨大缺陷。即公司的利益相关者告诉团队应该去做什么工作，并对工作进行审查。
罗恩·杰弗里斯（Ron Jeffries）描述了一场与利益相关者的虚拟对话：
“每周你可以告诉我们你最看重什么，然后我们会告诉你哪些要求是我们可以实现的。一周之后，你就可以拿到我们的成果。如果你乐意，你就可以交付出去。”
按照泰勒管理模式，由利益相关者来决定团队应该做什么，以及交付的成果是否可以出售。这种做法默认利益相关者知道什么具有价值，且他们的意见可以作为实际价值的衡量指标。
但数据表明实际上正相反。例如，罗恩·卡哈维发表了一篇论文，对微软的一系列创意和结果进行了分析。结果，仅有 1/3的创意对期望指标在统计层面产生了积极效应。
如果敏捷开发摒弃了数据统计和成果衡量，转而选择HiPPO（听从薪酬最高者的意见）来决定应该开发什么功能，那么其误差将超过66%。
很多公司还在使用“客户意见至上”的管理模式。这种模式中，个别人的意见代表了终端客户。在过去这个做法尚且行得通，因为在数据采集上很困难。但到了数字化的现代社会，这已经成为了瀑布模型的又一个遗留问题。
用实验取代HiPPO模式
事实上，开发团队不需要个别人来代表客户的意见。因为团队可以自己采访客户以判断开发行为是否得当。OKR可以取代HiPPO，通过实验让团队学习和复盘。
OKR可以帮助团队采用假设驱动开发模式，巴里•欧莱礼将其描述为：
我们认为……
可得到……
当……我们有信心继续进行……
在这个模型中，复盘不再是为了展示可交付成果。团队在复盘中通过讨论主题和主要假设来不断完善交付成果。
赋予团队自主权
命令与控制依然存在。
命令与控制心理依然贯穿敏捷交付的全过程。利益相关者有权决定开发什么功能。因此，团队的工作模式依然是“因为这是山姆说要做的”，直到“山姆觉得不错”之后才算完工。
公司发展需要团队全身心的奉献，所以他们需要理解公司的业务问题并能够就构建内容发表意见。
马蒂·卡根曾写道：“如果你只让你的工程师写代码，那你只得到他们一半的价值。”
为了赋予团队自主权，你要给予他们自主决定如何实现预期成果的自由。因此团队的目标也需要改变：
玛丽·帕彭迪克（Mary Poppendieck）曾写道：
“或许敏捷开发实践最大的缺陷是哪个来团队决定做什么的方式。在很长时间以来，人们认为团队本身并没有责任来回答应该做什么这个问题。”
团队不需要执行由利益相关者提出的瀑布式计划，他们可以利用双轨敏捷和设计冲刺等方法来发现有价值的产品。
END
Worktile官网：www.worktile.com
原文作者｜Felipe Castro
内容编译｜Worktile
文章首发于「Worktile官方博客」，转载请注明来源。