Ruddy Lee 分享空間

敏捷從來就不是單一的方法

2018 年 11 月 09 日2018 年 11 月 09 日 ruddyllee發表留言

0000

0002

0003

0004

0005

0007

0008

0009

0011

0012

2018 Scrum Process Chart

2018 年 11 月 07 日2018 年 11 月 09 日 ruddyllee發表留言

0002

2018 Scrum Process Chart

新增

PM 的相互依賴聲明.
OKR 目標關鍵結果 (約束=2).
AL 行動學習 (約束=1).

註

rules

敏捷各個方法或框架的約束與自適應圖示

敏捷走向精益的思维过程

2018 年 10 月 30 日2018 年 10 月 30 日 ruddyllee發表留言

當你在運行 Scrum 的時候，眼睛裡只會看到專案，
當你往前一步開始思考DevOps時，則眼前又多出現了產品的生命週期，
這時候你才體會到，你是在做產品全面性的規劃，其實是進入「系統思維」的領域了，
然後在看見全貌之後，往前、往後看自己在哪裡，接著你會開始思考該從哪裡下手?
想到「三步工作法」；想到「限制理論」裡所說的:

※ TOC 的思考程序裡的五大核心步驟：

　第一步，找出系統中存在哪些約束。
　第二步，尋找突破這些約束的辦法。
　第三步，使企業的所有其他活動服從於第二步中提出的各種措施。
　第四步，具體實施第二步中提出的措施，使第一步中找出的約束環節不再是企業的約束。
　第五步，回到步驟1，別讓惰性成為約束，持續不斷地改善

然後；就從眼前最大的限制開始著手吧!

成功變革的八個步驟

2018 年 10 月 19 日2018 年 10 月 19 日 ruddyllee發表留言

上網搜尋一下成功變革；

有效变革的八个步骤( – 約翰. 柯特 1947 ~) …
成功变革的八个步骤( – The great scrum master – 作者： Zuzana Šochová) …
八個步驟實現成功的組織變革(《變革之心》 – 奇異公司執行長,傑克威爾許) …
成功的大规模变革的八个阶段( – Mbalib) …
企业变革｜成功的八个步骤( – 蜻蜓FM是中国第一音频平台) …

整理一下

0005_2

註:

1. Action Learning 行動學習，敏捷主管的必修課程。

《問題應該這樣解決！正確提問x系統思考，行動學習教你找出對的答案》
Optimizing the Power of Action Learning:：Solving Problems and Building Leaders in Real Time

作者：麥克．馬奎德

簡體版: 行动学习实务操作:设计、实施与评估(第2版)

2. OKR 目標與關鍵結果

《OKR 工作法》

作者: 克裡斯蒂娜•沃特克 (Christina Wodtke)

敏捷開發被遺忘的事 – 敏捷管理

2018 年 10 月 17 日2018 年 10 月 27 日 ruddyllee發表留言

我們常常說到敏捷轉型要由上往下才會成功，為什麼呢?

敏捷開發沒有教主管們如何敏捷起來才是主要原因

敏捷教練們經常用同一套教材在教團隊與主管，但這樣做對嗎?是不是應該教導主管們如何來管理敏捷團隊才對呢?! 其實有關這個問題，在早2005 年時就已經有一群卓越的敏捷人士，發現了這樣的需求，就已經在努力的起草有別於敏捷宣言，專門指向專案管理面的宣言，目的是用來協助主管們跨過敏捷管理的門檻，就稱之為相互依賴宣言(Declaration of Interdependence, DOI)，用它來做為進行敏捷管理時的指導原則。你只要在Google搜尋畫面下，輸入”DOI agile” 就能找到下面的結果:

do agile

Google 一下:「DOI Agile」

選擇 PM Declaration of Interdependence: 就能看見了，它所強調的是” 雖然敏捷宣言已有涉及軟體開發，但敏捷專案管理的《相互依賴聲明》則更關注專案的管理領域”。

這個協會初期稱為 Agile Project Leadership Network，APLN，後來又更名為 Agile Leadership Network, ALN(把Project 拿掉了)，但由於未能引起專案經理人社群的青睐(註1)，形成了這個一樣是由一群卓越人士所推廣的運動，卻很少人知道而遲遲沒有發揮應有的效應。也就間接的造成了今天在實行敏捷化時專案經理人遇到問題時經常會有無所適從的局面。這裡就簡單地描述一下它的六大宣言:

6 principles

DOI的六大宣言(APLN並沒有提供中文的版本，因此我自行翻譯了一下，歡迎修正)

每句的特色是目標放在前一句,後面的句子則是作法的描述。後面刮號是我加上的主題.

起草 DOI 宣言的卓越人士:

David Anderson, Sanjiv Augustine, Christopher Avery, Alistair Cockburn, Mike Cohn, Doug DeCarlo, Donna Fitzgerald, Jim Highsmith, Ole Jepsen, Lowell Lindstrom, Todd Little, Kent McDonald, Pollyanna Pixton, Preston Smith and Robert Wysocki worked to see what management principles might be required in order to achieve an Agile Mindset in product and project management， In 2005.

我們常常說這是一個 VUCA的時代(註2.)，要尋找任何問題的解答，只要隨意的Google一下，獲得的訊息便會多到我們不知道要如何來取捨的情境，要如何來抉擇呢?恐怕只有依靠類似敏捷宣言這類核心原則才足以拿來協助我們過濾這些個龐大的資料訊息，因此許多新的理論就紛紛以原則的方式提供我們做為行動的準則，如著名的敏捷宣言是在2001年所訂下的。

宣言.png

2001的敏捷宣言

囉說一下:

敏捷價值Agile value

敏捷開發注重價值的交付，並不斷詢問有關範圍的不同表現是否值得他們提供的價值的問題，因此才能擁抱變化。上面這二個宣言正是在說明這一點。拿來對應到DOI的第一項原則「我們通過專注的持續產出價值流,來增加投資報酬率。」大家可以參考Ron Jeffries 所撰寫的《軟件開發本質論—追求簡約、體現價值、逐步構建》一書中所提到: 敏捷即是以價值為導向，也說明了為什麼我們要依照價值來排列需求開發的優先順序的原因。(這是一本從頭到尾都在強調如何務實地體現價值的書，淺顯易讀是敏捷主管的必讀手冊)

價值才是我們的開始，才是我們的工作重點。

簡單來說，價值就是”我們想要的東西”

– Ron Jeffries.

※ 團隊與任務

「如何管理自組織團隊?」是現代的領導者所遭遇到的最大挑戰之一，你經常要面對到的是應該選擇以具體、明確的方式來交付任務呢? 還是要授權團隊但不做具體說明如何來完成它，讓團隊自行去進行任務拆解的方式。這二者的差異，正是所有的Scrum Master 都會要求主管在遇到問題時，也就是所謂的: 主管要盡量的「後退一步」讓團隊透過討論的方式來解決問題，其實就是希望主管能夠，讓團隊多做自組織的抉擇少下指導棋的意思。許多時候主管會有所疑惑,當我退了那麼多步之後又怎能幫的上團隊呢？說來話長,其實這叫作「賦能」,要讓團隊知道你遇到這樣的問題時會怎麼作,當他們碰到時自然會依照你的思維方式去作,也就跟你在現場沒二樣了。當然, 前題是要先做到「授權」, 否則他們也不敢去作。

敏捷領導者領導團隊，非敏捷領導團隊則負責管理任務。

Agile leaders lead teams, non-agile ones manage tasks.

– Jim Highsmith

》如果再將 OKR 的準則融入後(註3)，便成了主管授權時的二個原則:

授權給團隊去完成任務，但不做具體的執行說明。
為目標設定完成時的驗證關鍵結果，並讓團隊能夠明確知道是否做到了。

遵循計劃不如適應變化

傳統的專案經理總是專注於以最小的變化來遵循計劃，而敏捷的領導者則專注於成功地適應那些不可避免的變化。時時選擇以將顧客的價值放在第一位的前提下，自然的將客戶價值視為專案成功的主要目標。正所謂的，當我們曉得為客戶產生價值和質量為目標時，此時的「計劃」本身就成為了實現這些目標的手段，而不是目標本身了。這便是所謂的敏捷了。

【補述】

《 敏捷管理 : 主管需要學會行動學習 Action Learning》

何謂「行動學習」?

行動學習(Action Learning)是一個團隊在解決實際問題中邊做邊學的組織發展技術及流程。

– AACTP 美國培訓認証協會

行動學習的目的

行動學習是為了解決管理者和人們所面臨的真實的複雜性挑戰和難題，同時它也是個人發展的源泉。此外，有一點是敏捷變革要成功的基礎，那就是變革成功的前提是: 「主管要先行改變自己」，依據不充分授權原則認為，除非我們可以改變自己，否則就不能改變周圍的任何事情。

– Revans ,2011

註1. 未能推廣開來的原由是，未獲得專案經理社群的青睐。

這裡有較詳盡的說明: http://itsadeliverything.com/declaration-of-interdependence

註2. VUCA (是這四個字的縮寫，不穩定 Volatility，不確定 Uncertain，複雜 Complex 和模糊 Ambiguous，霧卡 )

參考: 《原來你才是絆腳石》

註3. 實施 OKR 其實是極端敏捷的，它只有二個規範，就是設定目標，然後再設定如何驗證它，下面這張圖是借自《硝烟中的Scrum 和XP》作者〔瑞典〕Henrik Kniberg在描述各個敏捷方法的規範數時所畫的圖示。

0001

為看板設定目標

2018 年 10 月 09 日2018 年 10 月 31 日 ruddyllee發表留言

【二種做法】

設定持續改善的依循目標 – 持續改善目標表。
為使用者故事或Task 設定要達成的目標 – OKR用戶故事卡。

以紙本的方式

OKR用戶故事卡(左側) 與 持續改善目標表(右下方)

如果你已經在使用看板了，那你對看板的三條約束一定不陌生，它們是劃出價值流、設定WIP及管理你的流程。你也一定知道，它的終極目標是能夠做到持續改善(Kaizen)。但在你實施一陣子之後，一定有過這種疑惑，我們經常改動看板但是到底是改對了還是改錯了呢? 這樣改變WIP的值到底產生了多大的影響，有效嗎?

持續改善就是持續去設定目標，在達成目標之前能有效的持續地進行調整。

– 持續改善目標表

有明確的目標才能持續改善

當你在做一件有意義的事時，你會設定目標嗎? 如果你沒有設定目標這個習慣的話，又怎麼知道目標是否已經達成了呢? 又方向對了嗎，還是漸行漸遠了?舉個例子: 出外旅遊時，我們經常興高采烈的設定要去的地方，然後走著走著，在進入陌生的巷弄時難免就會心生疑慮，懷疑自己是不是走錯了，這時候；有一個可以用來確定對錯的好方法，便是使用目視法；要能始終看到目標物在哪裡，維持一直能看得到目標，這樣不管是怎麼繞來繞去只要一直能看到目標，而且有持續接近的跡象，就可以安心了。這種作法其實是由於可以確定方向是對的，心理頭自然就不會害怕是否迷路了，旅遊的心情也就自然地平穩了下來。這是持續看到目標確定方向的好處。然後篤信只要朝著這個方向去前進，就一定能到達目標。

上面的方法可行，但那是在你已經很接近目標物的時候。如果遇到距離較遠無法目視到目標的時候，我們可能就得先行規劃到達某一個特定目標之後再向主要目標前進，採用兩段式的方式去達成目標，這便有計劃的持續改善了，我們先設定好一個目標，在確定到達後，再朝向另一個目標去前進，自然能按計劃越來越接近目標了。

為看板設定目標

看板上少了一個可視化的設定，就是設定一個持續可改善的目標。雖然你可以辯解說目標一直都存在讓流程更快更順暢上頭，但其實它少了視覺化，這一點讓我們不容易聚焦，少了聚焦時便少了經常被關注到的機率，也就自然地就降低了持續改善的機會了。所以我們應該為看板設定一個現在正在改善的目標，然後讓它一直可以被看到。

目標就是我們想做的事，關鍵結果是讓我們知道自己達成了沒有。

看板上的卡片

將用戶故事設計成包含於OKR關鍵結果相連接的清單上，便利我們在選取 Task 時，確認自己即將做的工作能夠與設定的目標相吻合，以及須要完成到何種程度。當發現有用戶故事找不到與目標對齊的歸宿時，就可以顯現出(可以拿來度量)團隊戰力實際用在開發功能上的時間都花到哪裡去了。遇到這種狀況時，解決方法有二，一、是把它轉為功能目標，在設定好關鍵結果。(懷疑是目標訂得不好，所以就為目標加上一支腳，待事後回顧時可以做檢討用)。二、便是刪除不做。這是考驗PO如何來目標設定，及顯示出團隊戰力都消耗到哪裡去了的好現象。

. 看板上的OKR清單

看板上顯示OKR能關聯到用戶故事的清單(它放置在To do list前)

OKR用戶故事卡: 連結目標、關鍵結果與實際描述需求的用戶故事的卡片。

結語

在看板上實行OKR依目的可採用二種方法，一種是針對持續改善的目標設定方式，以設定「持續改善目標表」來讓團隊知道整個看板運作正在朝向哪個方向進行改善。另一種方式為創建用戶故事與OKR的關聯清單(稱為；OKR用戶故事卡，如果你只有Task 而沒有用戶故事的話，就叫它OKR工作卡)。

對於純粹使用看板方法的團隊，例如維運團隊而言，設定「持續改善目標表」會讓改善看板運行效率成為可以被看得到的成果，團隊容易形成共識進而加強了自組織性。而OKR工作卡則促成我們在做任何事之前先設定目標，由於預設完成後的關鍵結果，這一點可以激勵工程師表現得更好。對於運行Scrum的團隊，幫助就更大了，它可以讓綁定需求(用戶故事)與目標，讓開發需求時的預期目標能夠凸顯出來，更加專注於主要功能而減少去做與目標無關的工作，換句話說就是減少了浪費。

聚焦與持續激勵

聚焦與持續激勵是成就OKR成效的依據。所以必須一直提醒自己，一直提醒團隊是否偏離了目標的路線。站立會議是看板實作OKR開始時，最重要的檢核時機，透過隨時更新關鍵結果的信心度，可以讓團隊持續聚焦在目標上頭，而透明出來的效果更能持續增強團隊對目標的專注度，因此看板在實行OKR時，確切又正向的站立會議將是一大成功要素，不能忽略。

目標管理法

目標管理法概述

註: 幾本實行OKR的參考書籍

OKR工作法谷歌领英等顶级公司的高绩效秘籍

寫得好極了，也有一些獨到的施行方法，值得閱讀。

OKR：源於英特爾和谷歌的目標管理利器

囉說了些，但如果你想多參考一些建議的話，還是好書。

OKR资料全集

明道互联网公司的免費佳作。https://www.mingdao.com/home

運用OKR來量化Sprint的目標

2018 年 09 月 26 日2018 年 10 月 11 日 ruddyllee發表留言

【作法】

將Sprint衝刺的目的定成目標Object, 然後為這個目標設定三個關鍵的結果（key result)，每個結果都必須能夠量化成數據（由0.0到1), 對那些不易量化的結果則預先設定達成何種成果就給它相對的分數，並以難易度來給分。

(給分依據：很難幾乎不可能達成的給1分，必須很努力才能達成的給0.7，稍稍努力就能作到的給0.5，循正常工作就能達到的給0.3，而完全沒作到的就給0分）

然後在「計畫會議」時由團隊一起來設定關鍵結果，再在最後作「回顧會議」時一起來打分數（花上3～5分鐘）。然後在每天的站立會議時過一下團隊進度與預期目標的達成狀態，進行檢討。

這麼作你便能運用OKR的設定來量化Sprint的目標了。

囉嗦一下:

Sprint的結果無法被量化一直是管理人員的困擾，我們也都相信完成故事點的多少並不能做為開發效能的依據(註1，這裡挑戰了你對敏捷的認知，不要太迷信於故事點)，而故事點的多寡最多只能用來看待團隊所面臨負荷大小的參考而已。但在日常的Sprint運行上，我們又常常會面對到一些需要量化才能回答的問題，例如:

(高層總是擔心)

團隊到底是表現得好還是不好?
我們作對了嗎? 現在的開發方式需要改變嗎? 要怎麼變?

(Scrum Master 則常常收到)

PO經常抱怨開發團隊只會埋頭苦幹，沒有商業價值的觀念。
團隊每個Sprint週期，都是以完成所有工作為目標，而不是以達成商業價值為目標。

老實說；這些問題都很難給出明確的答案，即便是團隊現在顯得工作的很愉快，自組織的味道也逐漸在成型，但這還是不足以回答他們到底表現得如何?接下來又會往哪裡去的問題。面對這些疑惑，運用OKR(Object & Key Result) 正好可以拿來正本清源。

目標導向理論是激勵理論的一種。是要求領導者排除達成目標的障礙，

使其順利達到目標，並在過程中，給予員工滿足多種多樣需要的機會。

– wiki

OKR是一種目標導向的引導工具

它是在敏捷宣言誕生之前就存在的一種敏捷理念，安迪．葛洛夫Andy Grove 於1990年在擔任英特爾執行長時所推行的一種簡化版的目標管理法(MBO 註 2. 來自管理學大師彼得.杜拉克)，是一種比Scrum 還要簡單的引導理論，但卻能夠成功的解開Sprint 難以度量的問題，還能夠依據成果導向來激勵團隊開發的衝刺效果，所以我把它跟Sprint的過程畫在一起，讓我們來看看如何融合OKR於Sprint的衝刺過程中的做法。

為一個Sprint衝刺設定目標及Key Result

首先；讓OKR的目標與Sprint的衝刺目標對齊，讓「關鍵結果」成為DoD.

它會讓Sprint衝刺的目標更加明確，有很好的聚焦效果，工程師也會因此而開始關注Sprint所要達成的商業價值。做法是讓團隊在Sprint計畫會議時依據Sprint所要達成的目標，團隊一起定下「關鍵結果」Key Result，這樣作可以讓這個衝刺期間能夠更加關注項目的定義完成 DoD (Definition of Done)，這會讓每個工作單完成的定義，變得更為明確。

上圖描述的是將專案分成為多個Sprint的目標，然後在計畫會議時針對這個目標來制定它的關鍵結果Key Result，再持續用它來做為評估是否達成目標的依據。好處是; 工程師會依據目標是否達成而開始關注目標的商業價值，它聚焦了Sprint的衝刺目標，當目標達成時，剩餘的工作單就值得討論是否該拋棄或下一次在作了。

Object : 我們想作什麼？

Key result : 我們如何知道是否已達成了目標.

– 開始時不能忽略的提問

每日檢討；讓團隊成員以一周為單位設立個人目標。每週週一賦責，週五慶功，並於每日的站立會議加入報告第四件事: 也就是目標達成的狀態說明。能夠即時更新檢討實施的成果，便於修正改善。而缺點是每個人都設定自己目標，常常容易導致團隊目標失焦，因為目標設定多了、太細了花太多時間在目標設定上而少了真正的工作時間，人們很容易便會只專注於自己的使命，而忽略了團隊的使命。(建議先實行團隊的OKR待團隊成熟後再來嘗試個人的OKR，因為個人OKR往往會被導向個人績效的評核，容易走偏了，請謹慎為之)

OKR 的神奇力量，來自0.7的給分標準

好的KR應該是定量的、有挑戰的、具體而有驅動性的

好的關鍵結果(Key Result)可以協助我們衡量達成目標的距離，然後進行快速的檢討和進行行為的修正(一般稱這個動作為復盤，game review 註3.)

如何制定高效 OKR的 CRAFT法則

一個提前完成的Sprint，一個以OKR驅動提前完成的Sprint

如果我們能夠不用作完全部的需求就已經達到Sprint所設定的目標(商業價值)時，就叫它是一個「以OKR驅動提前完成的Sprint」，它因為已經達成目標了，所以就提前結束了(剩下來的需求，就由團隊一起討論是拋棄它呢?還是要把它繼續做完)，Sprint 完成了，但不是團隊作完了所有的需求，試問這有什麼差別嗎?

這是成功Scrum團隊的一大步，它代表了Sprint是以商業目標驅動來決定Sprint 的開發週期的，它超越了1到4周的固定周期式的開發方式，而是視所要達成的目標來調整開發周期，團隊具有一種意識能夠判斷開發功能與商業價值之間關連性的能力，才能夠摒棄多出來的需求單。這是一種理想化達成的Sprint 衝刺目標。也就是不以作完所有需求為目標，而是以達成商業價值為依歸。

結語

在過去自己所帶領的團隊裡，PO經常想盡辦法與開發團隊進行溝通，就是希望工程師在開發時能夠以商業目的為主來進行產品新增功能的開發作業，但最後總是落到抱怨開發團隊只會埋頭苦幹，一點商業價值的觀念都沒有的地步。這一點；其實是不能責怪工程師的，因為將使用者故事拆分成一個個工作(Task)的過程，就是要簡化需求讓它成為單純的功能項目，只有如此工程師才能專注的來進行開發工作。因此要求工程師同時又能兼顧商業價值觀是一件二難的事，但有了OKR的目標導向規範，不但這個問題得以克服，更由於對 Key result 的設定，讓我們能夠用數量化來衡量目標的達成與否，也間接的得以評估團隊的狀態，真是一舉數得。

OKR 是一套明確可追踪目標及其完成情况的管理工具和方法，它易懂又簡單，但實施起來需要先弄清楚許多事情。那些事呢? 完全看你要在哪一種層級來運行OKR。如果把它運用在公司層級，則可能需要先弄清楚公司的使命、願景。如果運用在Sprint的衝刺上，則可能需要先弄清楚專案的目標、方向，前提是在一堆待完成的目標裡識別出現在最需要聚焦的一個，然後設定偏高的衡量標準，在激勵自己盡全力去達成它。最後補上OKR的定義如下: (此為Paul R. Niven和Ben Lamorte的版本)

0029