OKR與敏捷開發的原理有着類似之處,但已經使用敏捷的團隊再用OKR感受會顯得多餘。這種誤解的根源就在於對這兩種模式不夠了解,運用得當的狀況下,OKR和敏捷能夠造成強強聯合的效果,他們能夠創造出以價值爲驅動的團隊,改變團隊的工做方式。架構
本文第一部分介紹了瀑布式目標與敏捷之間的衝突。
功能工廠框架
敏捷的誕生是爲了確保軟件的交付,能夠替代瀑布式開發來管理軟件項目。敏捷模式注重的是可交付成果(開發需求或軟件功能)而非項目價值(業務成果)的管理。學習
事實上,敏捷中並無單獨跟蹤結果的規範。測試
《敏捷宣言》自己具備必定的誤導性,由於它告訴人們要衡量可交付成果,它的第七條原則規定:「可工做的軟件是進度的首要度量標準」。spa
該原則默認全部可以使用的軟件都有價值,這顯然是錯誤的。由於有些項目可以產生價值,有些不能;用戶可能會採用軟件的某些功能但卻會摒棄其餘的功能。3d
大多數公司陷入了「功能工廠」模式,其團隊壓根不關注交付產品的價值。正如約翰·卡特勒(John Cutler)所描述的那樣,開發人員就像流水線的工人那樣「坐在工廠裏,批量製造各類功能,而後傳送出去」。blog
馬蒂·卡根(Marty Cagan)強調過這種模式可能致使的可怕後果:圖片
「開發團隊忙着具化細節、寫代碼和測試。他們對更大背景知之甚少,甚至不太相信本身的產品真的能成爲解決方案。他們不在意這些功能是否真正解決了潛在的業務問題。由於他們衡量進度的標準是輸出而非成果。」ip
距《敏捷宣言》發表已通過去15年了,大多數公司使用敏捷只是爲了交付,而在縮放框架上幾乎沒有什麼幫助。由於他們選擇這條阻力最小的路而且專一於改善軟件開發過程。也正所以,幾乎不多有公司可以真正實現公司業務的敏捷性。項目管理
敏捷交付
我喜歡把公司當作是一個包含了五個層級的架構,即文化、戰略、策略、運營和目標。
公司目標反映公司的工做和運營方式,所以它也會滲透到其餘四個層級。
傳統公司的組織架構圖示以下:
在傳統的公司架構中,各個層級的特色分別是:
一般,公司採用的敏捷,是指敏捷交付功能。僅僅只是用來替換公司最底層的架構:
敏捷交付僅在運營層面實踐精益和敏捷性。當團隊進行分散的實驗時,敏捷取代了瀑布式開發,這也就致使團隊沒法造成實驗文化。儘管各處都開展了一些A/B測試,但許多高風險假設未能獲得驗證。
鑑於敏捷交付不涉及其餘層級的架構,所以其優點變得愈來愈小, 瀑布模型的缺陷與公司敏捷性的實現之間存在直接衝突。
瀑布式目標
在設定目標時,瀑布模型的思惟模式仍然十分常見。公司一般會以年度爲單位,自上而下地規定一系列靜態的目標,而這與公司保持敏捷性之間存在直接衝突。
瀑布式目標遵循了靜態的規劃模式。一般由一羣高層管理人員集體制定公司的年度目標,而後逐級向下傳達,並最終造成公司該年度的固定計劃。
沒什麼能比瀑布更形象地描述這種自上而下逐級傳遞目標的設定模式了!
這種靜態的模式包括下列幾種假設:
以項目爲基礎的瀑布式目標
更糟糕的是,瀑布式目標不關注價值,由於它們反覆圍繞着管理層批准的一系列項目而設定。
弗雷德裏克•泰勒(FrederickTaylor)曾寫道: 「每一個員工的工做都應該至少提早一天由管理層詳細規定出來。」 若是他得知當今的公司依然遵循着他的教導,想必會異常欣慰。
在泰勒的敏捷管理理論中,團隊存在的意義就是爲了完成項目的交付。管理人員將嚴格按照流水線工廠的模式來規劃工做。這種管理模式將致使公司反應遲緩、難以適應變化,同時還會增長風險和浪費。
在敏捷交付中,大多數的縮放框架都是可以取得必定成效的,由於他們着重經過敏捷的思惟方法來推進瀑布式計劃的實現。
由靜變更的計劃
信奉靜態計劃模型的人就像是蘇聯時期的中央領導人,他們制定5年計劃方案,認定本身能夠預測將來。
相較之下,動態計劃則擁抱變化。他們在一個較小的計劃週期內運轉。動態計劃假設市場條件和計劃自己都會發生變化。更重要的是,咱們對問題的理解將伴隨着瞭解的深刻而變化,而計劃也會作出相應調整。
正如肯特·貝克(KentBeck)所寫的: 「一成不變地按照既定計劃行事的惟一方法就是拒絕學習、固步自封。」
你但願團隊能夠在更短的週期內更新迭代並檢驗假設,那你怎麼能效仿蘇聯經過瀑布式流程來設定一系列的靜態目標呢?
這樣確定行不通,儘管咱們在交付層面實現了敏捷,但在其餘方面依然使用瀑布模型。
咱們須要改變。
TBC......
原文做者|Felipe Castro
內容整理|Worktile
文章來源:Worktile官方博客文章轉載請註明出處。