okr與敏捷開發的原理有著相似之處，但已經使用敏捷的團隊再用okr感覺會顯得多餘。這種誤解的根源就在於對這兩種模式不夠了解，運用得當的情況下，okr和敏捷可以形成強強聯合的效果，他們可以創造出以價值為驅動的團隊，改變團隊的工作方式。
回顧第一部分請點這裡：系列文章｜okr與敏捷（一）：瀑布式目標與敏捷的衝突
回顧第二部分請點這裡：系列文章｜okr與敏捷（二）：實現全棧敏捷
與其他工具一樣，okr也可能會被濫用並淪為待辦事項列表。但如果你想要專注於價值實現，那麼你的目標就必須要體現這一點。因此你需要設定價值導向的關鍵結果：
價值就像講笑話：你沒法告訴對方它到底好不好。
價值導向的okr不僅僅衡量結果。你還需要明白對你的客戶和公司來說，什麼樣的結果才是有價值的。
下面的例子展示了兩種關鍵結果的差別：
在敏捷中使用行為導向的關鍵結果會產生摩擦。既然敏捷團隊已經有了明確的路線圖，為什麼他們還需要okr呢？我遇到的所有嘗試將okr與敏捷相結合的團隊，都在專注於開發活動本身。
使用價值導向的okr能夠帶來變革，它可以成為連線敏捷和精益的橋梁，彌補產品和開發之間的空白。
儘管敏捷使用的命名法專注於交付。我們也需要拋開一些概念，比如「完工、燃盡圖、速度」。
與之相反的，我們應該專注於價值。我們不需要驗收標準，需要利用okr來定義成功的標準。
敏捷並不是獨立的資料驅動，而是hippo（highestpaid person』s opinion）模式，即聽從薪酬最高者的意見。
《谷歌的經營之道》一書生動形象地描述了這個模式：
這種敏捷模式下隱藏著乙個巨大缺陷。即公司的利益相關者告訴團隊應該去做什麼工作，並對工作進行審查。
「每週你可以告訴我們你最看重什麼，然後我們會告訴你哪些要求是我們可以實現的。一周之後，你就可以拿到我們的成果。如果你樂意，你就可以交付出去。」
按照泰勒管理模式，由利益相關者來決定團隊應該做什麼，以及交付的成果是否可以**。這種做法預設利益相關者知道什麼具有價值，且他們的意見可以作為實際價值的衡量指標。
但資料表明實際上正相反。例如，羅恩·卡哈維發表了一篇**，對微軟的一系列創意和結果進行了分析。結果，僅有 1/3的創意對期望指標在統計層面產生了積極效應。
如果敏捷開發摒棄了資料統計和成果衡量，轉而選擇hippo（聽從薪酬最高者的意見）來決定應該開發什麼功能，那麼其誤差將超過66%。
很多公司還在使用「客戶意見至上」的管理模式。這種模式中，個別人的意見代表了終端客戶。在過去這個做法尚且行得通，因為在資料採集上很困難。但到了數位化的現代社會，這已經成為了瀑布模型的又乙個遺留問題。
事實上，開發團隊不需要個別人來代表客戶的意見。因為團隊可以自己採訪客戶以判斷開發行為是否得當。okr可以取代hippo，通過實驗讓團隊學習和覆盤。
okr可以幫助團隊採用假設驅動開發模式，巴里•歐萊禮將其描述為：
我們認為……在這個模型中，覆盤不再是為了展示可交付成果。團隊在覆盤中通過討論主題和主要假設來不斷完善交付成果。可得到……
當……我們有信心繼續進行……
命令與控制依然存在。
命令與控制心理依然貫穿敏捷交付的全過程。利益相關者有權決定開發什麼功能。因此，團隊的工作模式依然是「因為這是山姆說要做的」，直到「山姆覺得不錯」之後才算完工。
公司發展需要團隊全身心的奉獻，所以他們需要理解公司的業務問題並能夠就構建內容發表意見。
馬蒂·卡根曾寫道：「如果你只讓你的工程師寫**，那你只得到他們一半的價值。」
為了賦予團隊自主權，你要給予他們自主決定如何實現預期成果的自由。因此團隊的目標也需要改變：
瑪麗·帕彭迪克（mary poppendieck）曾寫道：
「或許敏捷開發實踐最大的缺陷是哪個來團隊決定做什麼的方式。在很長時間以來，人們認為團隊本身並沒有責任來回答應該做什麼這個問題。」
團隊不需要執行由利益相關者提出的瀑布式計畫，他們可以利用雙軌敏捷和設計衝刺等方法來發現有價值的產品。
end原文作者｜felipe castro
內容編譯｜worktile
敏捷開發與專案管理實戰系列文章
敏捷專案管理實戰之質量管理 本文以作者黃文海的專案管理實踐為基礎，介紹基於經驗過程控制 empirical process control 模型 缺陷預防以及敏捷價值觀的敏捷質量管理思想及其實踐。希望通過本文為廣大專案管理人員提供質量管理的一些思路和經驗分享。敏捷專案管理實戰之在敏捷開發中引入 st...
敏捷開發團隊管理系列之四 程式與測試團隊III
這是敏捷開發團隊管理系列的第四篇。之一，之二，之三，之四 整體上有兩種測試團隊的模型，既然都有存在，自然是各有各的道理。城裡城外的人倒不必互相羨慕，只是要觀察對面的優點，分析自己的缺點，嘗試做點事情補償一下。所以，下面多說一點各自的壞處。這個就是著名的與程式團隊打架的測試團隊。好處 獨立團隊，還是能...
敏捷開發團隊管理系列之四 程式與測試團隊III
這是敏捷開發團隊管理系列的第四篇。之一，之二，之三，之四 整體上有兩種測試團隊的模型，既然都有存在，自然是各有各的道理。城裡城外的人倒不必互相羨慕，只是要觀察對面的優點，分析自己的缺點，嘗試做點事情補償一下。所以，下面多說一點各自的壞處。這個就是著名的與程式團隊打架的測試團隊。好處 獨立團隊，還是能...