2017年7月16日 星期日

OKR 要怎麼跟Scrum 搭配進行呢? (1)


第一次聽到OKR 的完整範例是從吳軍的硅谷來信中聽到的 Google 的目標管理法,聽完的感想是,哇~原來OKR 可以這樣使用,不管是目標和關鍵成果都很明確,是個簡單易懂的工具。對於個人是這樣,但是對於公司組織制訂OKR似乎就沒那麼簡單了...


對於許多組織來說,都會有訂立年度目標的習慣,也會根據年度目標來當作績效考核的參考,不過這對我們跑敏捷的組織來說是不太適用的,如同這篇文章有提到 : Agile Goal Setting: Using OKR to link Agile and Lean to company goals
But if your teams are working on 1–4 week iterations, getting out of the building to talk to customers, testing hypothesis and learning what works and what doesn't work, how can you use a static set of goals?    -  The answer is, you can't.

像我們以Sprint 為基礎在運行,本來就等於週週在規劃,週週都在Review,而且Scrum Team 本來就應該是以整個團隊成果來考核,所以績效考核這套跟我們有點格格步入,經過內部討論後,我們想乾脆就趁機開始試試看OKR。而本著敏捷學習試錯的精神,反正就先讓大家試試看,過一季後在來檢討一下,看看實行上有什麼困難和不順的地方,再當作修改的依據。

而團隊成員和我運行一季後遇到最大的問題就是:
個人Object 跟Sprint Goal 無法 Match 的狀況下,根本無法達成任何Key Result

這顯然有什麼地方出錯了?理論上 OKR 的制訂必須跟組織和團隊的目標一致,而團隊成員就依據討論出來的組織目標去思考到底我們可以對組織有什麼貢獻?並且訂出一些覺得可以對組織有貢獻的改善方案當作我們的 OKR,但這個問題就來了,我們個人的OKR 如果沒有排入 Backlog 那有什麼時間可以做呢?

(這邊就有個怪味道,是不是個人OKR 跟組織或  Team 沒有 alignment 呢?)

你真的了解OKR吗? 這篇文章也有提到,所有的OKR 都必須排入Backlog 才能被有效追蹤和執行,但是Backlog 不都是PO 在管理的商業需求嗎? 那個人建議的改善方案要怎麼排進去呢?


後來發現網路有不少人有跟我一樣的問題:
有人提到在Scrum team 跑OKR 對工程師來說會有些疑惑:
"company-level OKRs work fine, when it comes to group-level and individual OKRs, often developers get the feeling that the two systems are overlapping or even competing."

其中有一個人講的我覺得蠻有道理的,也比較像我覺得OKR與Scrum 用起來有點不順的地方:

Personally, I think OKRs fit better with pull based systems (e.g. kanban/lean) over push based systems (e.g. Scrum iterations).  Autonomy is key. Once OKRs are set, it's great to see the team define their own work to help achieve their own OKRs.


然後我看到說有成功結合Sprint 和 OKR 的就是直接把Sprint Goal 要做的User story 當作是RD的Object,那RD產出的KRs就是如何設計和開發這些功能.......這超奇怪的....XD

For example, let's say we want to release our recognition version 2.0 this quarter. This will be our OKRs. The key results will consist of the team member's sprints to achieve the goal. E.g. Redesigning the "Recognize" button, x amount of code reviews before push etc.

透過OKR 幫助團隊對齊


Agile Goal Setting with OKR - Objectives and Key Results 這篇文章中提到,透過團隊共享OKR可以達到 Reinforcing Alignment,這個觀點我認同,同一個team 對於同一個產品應該要有相同的目標和檢驗標準,不過這邊指 team 似乎不只是RD team還包含 BD sales  吧?

Objective: Successfully Launch Acme Product
Key Results:
  • 500.000 Daily Active Users of the free version.     
  • 8% conversion rate from free to paid customers.     
  • Net Promoter Score of 75%.     
  • Less than 5 critical or blocker bugs reported by users.     
  • Achieve at least 40% revenue share with 5 of the target content partners.

此外許多篇文章最後都會看到這個結論:
  • OKR gives autonomy to the team
  • OKR helps prioritize the product backlog

讓我開始重新思考我真正的問題是什麼,到底Scrum Team要交出的OKR是什麼? Scrum 會需要個人的OKR嗎?

首先 OKR 的確適合用在Lean 的環境,甚至可以用來補強,因為Lean 的重點就是驗證假設與學習,而OKR 正好用來定義 Success Criteria 的量化指標,在過去 Agile & Scrum 其實是沒有著重在Goal 與 Business Success 這塊的,它重視的比較是交付,要知道Product Deliver  與 Product Success 是有差距的,而且很多地方是RD無法着力的? 有個 OKR 教練 Christina Wodtke 提到:

Success is not checking a box.
Success is having an impact.
If you complete all tasks and nothing ever gets better, that's not success.

而參考自Riachard的文章 Scrum Master 的職責 - 引領團隊的流程,進而得以交付成功的產品,原始的Scrum 定義分工是:
  • Product Owner: Makes Product Success (讓產品得以成功)
  • Scrum Master: Makes Process Success (讓流程得以成功)
  • Scrum Team: Makes Deliverables Success (讓交付得以成功)
Team 的 OKR 只需要專注在 交付嗎?  此外 A Key Result is NOT something you do, it IS something that happened because of what you did,所以我們要造成什麼Happen?


假使單獨談 OKR 和 Scrum 應該都沒什麼疑問,但是合在一起看我就迷糊了~XD 而且看了越多文章問號越多~

講了那麼多到最後不但沒結論,反而造成更多疑問這樣好像不道德,浪費大家的時間...Orz...


Well 至少我可以分享給各位我看過的幾篇好文章,然後我會繼續研究思考這個議題~

Reference:

[1] What is the difference between MBO and OKR
[2] oreilly - Introduction to OKRs
[3] How OKRs Complement Scrum – and Why You Should Use Them Together
[4] Monday Commitments and Friday Wins
[5] OKR Mistakes (and how to fix them)
[6] OKR for Agile Teams
[7] Lean Performance’s Beginner’s Guide to OKR:




2017年7月15日 星期六

[萬維鋼的精英日課] 端粒效應 - 用科學法驗證古人名言



本週萬維鋼精英日課都在講這本書,端粒效應(The Telomere Effect: A Revolutionary Approach to Living Younger, Healthier, Longer )[Amazon 上火熱熱的新書],這本書的脈絡是研究人類衰老的原因,衰老主因是細胞不再分裂,而控制的因素是端粒體題的長短,端粒體每分裂一次就會變短,而是否能維持端粒體的長度取決於端粒體酶的分泌程度。

上面的部分都是純粹生化科學的研究,但是接下來的研究就扣回到許多宗教和心靈書籍所解釋的內容,比如說你怎麼面對你的壓力?

科學研究壓力會抑制端粒體酶的分泌,進而影響端粒體的長度(也就是影響衰老程度),但是人每天都會面對壓力阿!?那不就沒救了?根據這本書的研究其實面對多少壓力不是主因,而是你怎麼看待壓力,面對壓力有兩種詮釋方法:
1. 威脅,危機
2. 挑戰,機會

以第一種心態面對壓力,的確就會抑制端粒體酶進而減短端粒體(加速衰老),如果是第二種心態則不會,所以如何面對壓力和我們的心態原來有這麼大的關係,而且還是有科學生理依據的。
如果每天只會抱怨,面對壓力唉聲嘆氣,動不動說自己年紀大了,老了,那衰老則是無法避免的,這也映證了心理學大腦會接受自我暗示的😂
更有趣的點來了,怎樣可以幫助面對壓力,把壓力視為挑戰和機會,就是用第三人稱的角度對自己說話和激勵。

寶寶苦寶寶當吃補造句法

今天系統炸裂了,老貝不要害怕,就當作是定期演練,給老貝機會把系統弄得更強壯...(噁)

我想熟讀聖經的話語,並且放在心裡是比較實在的做法🤣
所以我們不喪膽,反而我們外面的人雖然在毀壞,我們裏面的人卻日日在更新。因為我們這短暫輕微的苦楚,要極盡超越的為我們成就永遠重大的榮耀。
-哥林多後書4:16-17

2017年7月2日 星期日

關於技術債的why what how


敏捷其實是面照妖鏡,能提早暴露出組織和團隊的問題,好讓團隊能及早進行討論,和思考改善方案(當然前提是有想要改善,有能力改善)。隨著專案越來越大,系統越來越複雜,技術債這個議題已經越來越不能忽視,因此最近團隊時常討論的題目便是"該如何償還技術債",但是如果直接基於這個命題來討論,我們很容易就直接跳到了how 的議題,於是各式各樣的爭論就出現了:

2017年7月1日 星期六

[得到]薛兆丰的北大經濟學 - 利息理論



得到的專欄越訂閱多,有時候比較忙略過了幾天,追起來就會有點吃力...XDrz..
與其聽過就忘了,應該要強制自己整理一下感想和筆記,這樣才會有真正的收穫,所以每個專欄的老師都會鼓勵留言討論。