.
上網搜尋一下成功變革；
.
整理一下
.
1. Action Learning 行動學習 ， 敏捷主管的必修課程。
《問題應該這樣解決！正確提問x系統思考，行動學習教你找出對的答案》
Optimizing the Power of Action Learning:：Solving Problems and Building Leaders in Real Time
作者： 麥克．馬奎德
簡體版: 行动学习实务操作:设计、实施与评估(第2版)
2. OKR 目標與關鍵結果
作者: 克裡斯蒂娜•沃特克 (Christina Wodtke)
.
我們常常說到敏捷轉型要由上往下才會成功，為什麼呢?
.
敏捷開發沒有教主管們如何敏捷起來才是主要原因
敏捷教練們經常用同一套教材在教團隊與主管，但這樣做對嗎?是不是應該教導主管們如何來管理敏捷團隊才對呢?! 其實有關這個問題，在早2005 年時就已經有一群卓越的敏捷人士，發現了這樣的需求，就已經在努力的起草有別於敏捷宣言，專門指向專案管理面的宣言，目的是用來協助主管們跨過敏捷管理的門檻，就稱之為相互依賴宣言(Declaration of Interdependence, DOI)，用它來做為進行敏捷管理時的指導原則。你只要在Google搜尋畫面下，輸入”DOI agile” 就能找到下面的結果:
.
Google 一下:「DOI Agile」
.
選擇 PM Declaration of Interdependence: 就能看見了，它所強調的是” 雖然敏捷宣言已有涉及軟體開發，但敏捷專案管理的《相互依賴聲明》則更關注專案的管理領域”。
這個協會初期稱為 Agile Project Leadership Network，APLN，後來又更名為 Agile Leadership Network, ALN(把Project 拿掉了)，但由於未能引起專案經理人社群的青睐(註1)，形成了這個一樣是由一群卓越人士所推廣的運動，卻很少人知道而遲遲沒有發揮應有的效應。也就間接的造成了今天在實行敏捷化時專案經理人遇到問題時經常會有無所適從的局面。這裡就簡單地描述一下它的六大宣言:
.
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年所訂下的。
.
2001的敏捷宣言
.
囉說一下:
敏捷開發注重價值的交付，並不斷詢問有關範圍的不同表現是否值得他們提供的價值的問題，因此才能擁抱變化。上面這二個宣言正是在說明這一點。拿來對應到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在描述各個敏捷方法的規範數時所畫的圖示。
.
.
【二種做法】
.
OKR用戶故事卡(左側) 與 持續改善目標表(右下方)
.
如果你已經在使用看板了，那你對看板的三條約束一定不陌生，它們是劃出價值流、設定WIP及管理你的流程。你也一定知道，它的終極目標是能夠做到持續改善(Kaizen)。但在你實施一陣子之後，一定有過這種疑惑，我們經常改動看板但是到底是改對了還是改錯了呢? 這樣改變WIP的值到底產生了多大的影響，有效嗎?
.
持續改善就是持續去設定目標，在達成目標之前能有效的持續地進行調整。
– 持續改善目標表
.
有明確的目標才能持續改善
當你在做一件有意義的事時，你會設定目標嗎? 如果你沒有設定目標這個習慣的話，又怎麼知道目標是否已經達成了呢? 又方向對了嗎，還是漸行漸遠了?舉個例子: 出外旅遊時，我們經常興高采烈的設定要去的地方，然後走著走著，在進入陌生的巷弄時難免就會心生疑慮，懷疑自己是不是走錯了，這時候；有一個可以用來確定對錯的好方法，便是使用目視法；要能始終看到目標物在哪裡，維持一直能看得到目標，這樣不管是怎麼繞來繞去只要一直能看到目標，而且有持續接近的跡象，就可以安心了。這種作法其實是由於可以確定方向是對的，心理頭自然就不會害怕是否迷路了，旅遊的心情也就自然地平穩了下來。這是持續看到目標確定方向的好處。然後篤信只要朝著這個方向去前進，就一定能到達目標。
上面的方法可行，但那是在你已經很接近目標物的時候。如果遇到距離較遠無法目視到目標的時候，我們可能就得先行規劃到達某一個特定目標之後再向主要目標前進，採用兩段式的方式去達成目標，這便有計劃的持續改善了，我們先設定好一個目標，在確定到達後，再朝向另一個目標去前進，自然能按計劃越來越接近目標了。
.
為看板設定目標
看板上少了一個可視化的設定，就是設定一個持續可改善的目標。雖然你可以辯解說目標一直都存在讓流程更快更順暢上頭，但其實它少了視覺化，這一點讓我們不容易聚焦，少了聚焦時便少了經常被關注到的機率，也就自然地就降低了持續改善的機會了。所以我們應該為看板設定一個現在正在改善的目標，然後讓它一直可以被看到。
.
目標就是我們想做的事，關鍵結果是讓我們知道自己達成了沒有。
.
看板上的卡片
將用戶故事設計成包含於OKR關鍵結果相連接的清單上，便利我們在選取 Task 時，確認自己機將做的工作能夠與設定的目標相吻合，以及須要完成到何種程度。當發現有用戶故事找不到與目標對齊的歸宿時，就可以顯現出(可以拿來度量)團隊實際用在開發功能上的時間都花到哪裡去了。解決方法有二，一、是把它轉為功能目標，在設定好關鍵結果。(懷疑是目標訂得不好，所以就為目標加上一支腳，待事後回顧時可以做檢討用)。二、便是刪除不做。這是考驗PO如何來目標設定，及顯示出團隊戰力都消耗到哪裡去了的好現象。
.
看板上顯示OKR能關聯到用戶故事的清單(它放置在To do list前)
.
OKR用戶故事卡: 連結目標、關鍵結果與實際描述需求的用戶故事的卡片。
.
在看板上實行OKR依目的可採用二種方法，一種是針對持續改善的目標設定方式，以設定「持續改善目標表」來讓團隊知道整個看板運作正在朝向哪個方向進行改善。另一種方式為創建用戶故事與OKR的關聯清單(稱為；OKR用戶故事卡，如果你只有Task 而沒有用戶故事的話，就叫它OKR工作卡)。
對於純粹使用看板方法的團隊，例如維運團隊而言，設定「持續改善目標表」會讓改善看板運行效率成為可以被看得到的成果，團隊容易形成共識進而加強了自組織性。而OKR工作卡則促成我們在做任何事之前先設定目標，由於預設完成後的關鍵結果，這一點可以激勵工程師表現得更好。對於運行Scrum的團隊，幫助就更大了，它可以讓綁定需求(用戶故事)與目標，讓開發需求時的預期目標能夠凸顯出來，更加專注於主要功能而減少去做與目標無關的工作，換句話說就是減少了浪費。
聚焦與持續激勵
聚焦與持續激勵是成就OKR成效的依據。所以必須一直提醒自己，一直提醒團隊是否偏離了目標的路線。站立會議是看板實作OKR開始時，最重要的檢核時機，透過隨時更新關鍵結果的信心度，可以讓團隊持續聚焦在目標上頭，而透明出來的效果更能持續增強團隊對目標的專注度，因此看板在實行OKR時，確切又正向的站立會議將是一大成功要素，不能忽略。
.
目標管理法概述
.
註: 幾本實行OKR的參考書籍
寫得好極了，也有一些獨到的施行方法，值得閱讀。
囉說了些，但如果你想多參考一些建議的話，還是好書。
明道互联网公司的免費佳作。https://www.mingdao.com/home
【作法】
將Sprint衝刺的目的定成目標Object, 然後為這個目標設定三個關鍵的結果（key result)，每個結果都必須能夠量化成數據（由0.0到1), 對那些不易量化的結果則預先設定達成何種成果就給它相對的分數，並以難易度來給分。
(給分依據：很難幾乎不可能達成的給1分，必須很努力才能達成的給0.7，稍稍努力就能作到的給0.5，循正常工作就能達到的給0.3，而完全沒作到的就給0分）
然後在「計畫會議」時由團隊一起來設定關鍵結果，再在最後作「回顧會議」時一起來打分數（花上3～5分鐘）。然後在每天的站立會議時過一下團隊進度與預期目標的達成狀態，進行檢討。
這麼作你便能運用OKR的設定來量化Sprint的目標了。
.
囉嗦一下:
Sprint的結果無法被量化一直是管理人員的困擾，我們也都相信完成故事點的多少並不能做為開發效能的依據(註1，這裡挑戰了你對敏捷的認知，不要太迷信於故事點)，而故事點的多寡最多只能用來看待團隊所面臨負荷大小的參考而已。但在日常的Sprint運行上，我們又常常會面對到一些需要量化才能回答的問題，例如:
.
(高層總是擔心)
.
(Scrum Master 則常常收到)
.
老實說；這些問題都很難給出明確的答案，即便是團隊現在顯得工作的很愉快，自組織的味道也逐漸在成型，但這還是不足以回答他們到底表現得如何?接下來又會往哪裡去的問題。面對這些疑惑，運用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)，這會讓每個工作單完成的定義，變得更為明確。
.
– 開始時不能忽略的提問
.
每日檢討；讓團隊成員以一周為單位設立個人目標。每週週一賦責，週五慶功，並於每日的站立會議加入報告第四件事: 也就是目標達成的狀態說明。能夠即時更新檢討實施的成果，便於修正改善。而缺點是每個人都設定自己目標，常常容易導致團隊目標失焦，因為目標設定多了、太細了花太多時間在目標設定上而少了真正的工作時間，人們很容易便會只專注於自己的使命，而忽略了團隊的使命。(建議先實行團隊的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的版本)
.
OKR 的定義說明
.
註1. 故事點的多少並不能做為團隊開發效能的依據.
因為故事點只是估算時的參考值，無法換算成絕對的數值，因此不能成為依據。
註2. MBO(Management by Objectives)來自管理學大師 彼得.杜拉克 Peter Drucker 在上世纪60年代即提出來的MBO的思想
註3. 復盤，game review
復盤是圍棋中的一種學習方法，指的是在下完一盤棋之后，要重新擺一遍，看看哪里下得好，哪里下得不好，對下得好和不好的，都要進行分析和推演。是一種極致的回顧方式。
【補充資料】
.
簡潔、易懂的OKR，有著極高的敏捷性及聚焦性。
.
二個約束:
一、設定目標；充分授權於下屬，不要具体的說明如何去作到,讓他可以充分的去自我發揮。
二、運用關鍵結果作驗証目標是否達成了。以便於在過程中時時鼓勵、提醒與敦促努力的方向是否正確。
.
.
.
僅僅用在專案上，有人又稱之 MOKR( Mission OKR)
參考自《OKR：源於英特爾和谷歌的目標管理利器》，稍加了補充.
.
一種超越敏捷的激勵力量(Google有團隊訂成0.75，就更有趣了)
.
如果運用在公司層面上，訂定"使命“便成了第一步，應該多參考別人的使命.
.
參考自《OKR工作法：谷歌、領英等頂級公司的高績效秘籍》的好方法
.
曾經試過 .2、.4、.6、.8的五分法的打分數方法，但還是奇數看起來必較有味道。
.
公司的使命不是為了想要賺錢，而是為何要創業的初衷。
.
實行OKR，你需要建立一個高效的團隊
.
.
這堂Session (2018 DevOpsDays 台北 Keynote session)目的在談衡量的意義及我們的做法；會採用倒敘的方式開始，由後往前講，首先描述我們公司Data 團隊對資料分析的處理步驟(有一個案例)，會談到一點點OKR對應到Sprint目標的度量(註)，然後再談到看板對衡量的助益及我們如何將衡量置入工作流程中，千萬不要將衡量單獨拿出來執行，而成為一種浪費(要精實Lean)，有帶到「數據崇拜」的觀念這是針對手機低頭族的一個新詞彙(它源自《人類簡史》作者:尤瓦爾•赫拉利)，接著在談到衡量/度量的意義。至於餐廳這一段是真實度量的說明，有一段影片要放，目的在闡述數據分析本身不應該是重點，解題方案才是。(閃電秀: 我們需要專職的 ScrumMaster嗎?)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Google 的合格標準為 0.75
.
.
.
.
.
註. OKR 的度量
OKR (Object & Key Result) 目標關鍵結果，這裏我拿它來跟Sprint 的Scrum process 相對照。目的是激勵與明確化Sprint目標達成的度量，主旨是在讓負責開發作業的工程師，也能夠時時不忘記Sprint目標的商業意義(好難)。
過去我輔導的轉型案例裡，起手式都是依據看板之父也就是 David J. Anderson 先生所謂的一種成功的方式(註1，第一步、專注於質量)的切入法來開始改變組織的行為模式的，也就是從「要求品質」開始，更具體的說；就是從開發部門開始改起。這種敏捷化的起步方式看起來十分合理，因為敏捷的初期本來就是針對開發單位所應運而生的(2001年的敏捷宣言目標是專注於開發團隊)，因此從開發單位開始改起就很合理了，再來對開發及運維單位做要求品質改善的行為，本來就是不可或缺的要求，所以從這裡下手很少會遭人反對的，再說進行品質改善是一種換來紀律的行為，對團隊有利而無弊，很少會有人反對的意見。但是我發現這麼做是錯的…
敏捷轉型要從產品部門做起
最近，突然發覺敏捷轉型要從PO作起才是對的，為什麼呢? 因為如果是由客戶端就要求你在開發時，每2到3週就要讓我看到成果，要求進行功能檢核，到底做得對不對、合不合我用，然後尋求我的回饋來作調整的話，這不就是一種小增量、迭代式的開發嗎?這就是敏捷啊! 而客戶給出的需求只要求能領先開發團隊產出的2到 3個開發週期就夠了，需求的優先順序也是客戶說了算數，這個小開發週期結束時的展示會議(review meeting，就等於SCRUM的檢核會議)看起來就好像是在作驗收一般，這位扮演客戶角色的團隊成員不正是我們不陌生的PO (product Owner)嗎，他的要求自然而然地會將團隊導向敏捷化的路徑上，團隊為了符合PO的要求，不得不將步調挑整成一種小增量、小迭代的模式，這個時候的開發流程也就自然而然地符合了敏捷的精神，而團隊的開發方式自然的就敏捷化了，真是事半功倍。所以敏捷轉型要從PO所在的產品部門做起。
.
人們的需求才是真正在改變這個世界的起因。
.
讓需求敏捷化來引導開發團隊
一切都要由讓需求夠敏捷化開始。不要讓開發部門再去主導敏捷化的行為了，應該讓需求來引導開發團隊的行為才是，需求一旦敏捷了團隊自然就敏捷了。而需求如何變敏捷呢?自然是產品規劃部門運用符合敏捷開發的方式來規劃需求的產出，由此作推論，便是組織推行敏捷化要由產品的規劃部門開始。過去我的做法則是一直由開發部門的敏捷化作開始，以讓開發人員踏上正確的敏捷原則為依據，運用一個較小的開發團隊成功的達成敏捷化的方式來作範例，作為組織敏捷化的標竿，然後在來希望這個成功的案例能夠吸引其他團隊來群起效法。這種起手式是許多書上的建議，由一個成功的案例讓開發團隊來主導敏捷化的過程，用好的開始逐步的來推行敏捷化。老實說；這麼多年以後，如果在讓我做一次的話，我會選擇由產品部門的敏捷化開始。或許這是由於推行DevOps所產生的改變吧，我們藉由下面這張圖來做說明: 首先；DevOps的概念實質上應該要包含商業的運作在內的，因此全名應該是 Business DevOps, 而 DevOps則是簡稱(註2.)。
.
含有商業運作的 DevOps 圖示
.
上圖說明了，如果只有在開發(Development) 單位實行Scrum 的敏捷開發模式，則實質上是在運行Water-Scrum-Fall而非真正的敏捷化。真正的敏捷必須向前與向後去做推廣。因此由產品部門開始實行敏捷化能夠以較省力的方式，也就是從能夠承上起下的地方是最適合的起始點。
敏捷不是單一部門敏捷就說敏捷化成功了的，一定是由運維、開發一直到業務部門都敏捷了，企業才能嘗到哪種成功的滋味。由開發部門開始運作敏捷的方式，是一種由下往上的推行方式，而由產品部門開始敏捷化的方式則比較偏向由上往下的推行方式。相對的成功率會高一些，當然高層長官的支持，依然是成功的先決條件。只是由客戶的立場做起敏捷化來會更符合以顧客為導向的思維方式罷了。
.
需求看板Up Stream / 開發看板Mid Stream / 運維看板Down Stream
.
需求看板是敏捷化的源頭
如果能從需求端就開始敏捷，則下游的開發與運維端便能夠自然而然地跟隨著需求而逐漸的敏捷起來。這個道理不難理解，但執行起來要從哪裡作起呢? 來自各方的需求，運作起來其實可以大致分成:規劃與執行二個部分。上圖綠色部分是運作時的執行看板，也就是執行的部分，另外應該還要有一份企業俱有巨觀型的規劃看板，也是規劃部分(它應該包含許多大顆粒的需求，跟流動路徑與相對單位需要配合的價值流，這裡就不做細談)。它的流動方式決定了下游所有其他看板的依據。包括何時啟動由哪一個單位負責及需要些什麼配合。
.
需求的好壞決定了開發團隊的效能，需求的敏捷性則影響著團隊開發的模式。
.
需求要先視覺化；視覺化可能是最重要的手續之一，他可以確保開發的流程能夠符合精實的原則來進行，能夠適當的消除穀倉效應，因此產品部門要實施敏捷化的起步當然是由需求看板做出發，讓它務實的反應出規劃與執行面的進度與流程(對於完成Definition of Done的定義有所不同，這是與傳統看板之間最大的差異處，相對的它將更專注於處理 Definition of Ready資料備妥)。運用透明化的訊息來與各個相關單位做聯繫，這一步是開始也將是敏捷化成敗的重要因素。
結語
如果看板之父的企業變革的「一種成功的祕訣」是減少組織轉型阻力的方法，則由PO需求開始敏捷化的啟動方式，便是一種事半功倍的轉型方法。開發與運維的敏捷化將由於PO對產品規劃的敏捷化而牽動，一種基於客戶的要求，為了與需求相配合而自然形成的敏捷化。這種思考方式是認為因為來自客戶端的需求方式，所引發的敏捷才是自然因應需求而生的敏捷，是一種在順暢不過的敏捷衍生過程，前提是以客戶為導向，所以用一種「敏捷的需求」來引發開發、運維配合而自然改變行為模式的敏捷，是一種事半功倍的轉變方式，也是一種符合以客戶為導向的開發模式。
邁克·考恩(Mike Cohn) 有一段話在支持這種想法:
“The Scrum product owner is typically a project’s key stakeholder.
Part of the product owner responsibilities is to have a vision of what he or she wishes to build, and convey that vision to the scrum team.
This is key to successfully starting any agile software development project.
The agile product owner does this in part through the product backlog, which is a prioritized features list for the product.
The product owner is commonly a lead user of the system or someone from marketing, product management or anyone with a solid understanding of users, the market place, the competition and of future trends for the domain or type of system being developed”
– Mike Cohn
.
註1. 《看板方法: 科技企業漸進變革成功之道》by: David J. Anderson
.
註2. BizDevOps (Business DevOps) 有許多單位向DevOps 之父反映過這個疑慮，Patrick 的回答是認同的，DevOps 應該包含商業運行，只是 DevOps 這個詞彙已經被大眾所接受了，沒有必要在做修改徒增疑惑，只要正確的詮釋就好了。
讓團隊自行做決策的手指湯
– 精實開發與看板方法
前情是: 老闆說我們需要一個看板。
忙碌的工程師們面面相覷，好像是誰先出聲誰就要負責似的，大家都不吭聲。
(沉默了一回兒…, Scrum Master 首先開口了)
「看起來大家都很忙碌的樣子，我們就讓團隊一起來做決定好了」
「我們來玩一個手指頭的遊戲，請大家圍成一個圓圈然後把食指借給我，我們用推舉的方式來選出團隊認為適合做這件事的人選，這叫全民推選，用民意來做決策。規則只有一條，就是被指到的人都是最適合的人選。」
「首先把手指指向天花板，然後開始畫圓圈，… 都好了嗎?」
(用手指頭畫圈的動作，狀似像攪湯的動作，因此稱為指頭湯，好吧，牽強了一點.)
.
「仔細聽我倒數由3開始，當我數到1的時候，就停止畫圓圈.」SM 大聲的說道.
「接著就把手指指向你認為最適合畫這個看板的人，好了嗎?」
.
「開始，3、…，2…、1」
.
「這是第一輪，凡是被指到的人，都是最適合的人，請後退一步」
「接著我們進行第二輪，請內圈的人把手指借給我」
.
「開始畫圓圈，3、…，2、…1」
.
當大家都被指到後，結論是，所有的人都是適合畫看板的人，就大家一起來吧!
SM為了確認沒有人沒被選到，因此讓自己也加入圈圈裡頭，然後透過一輪在一輪的手指湯的遊戲，所有的人都被指到了。
.
結語
手指湯的概念來自石頭湯的故事(註)，是希望團隊在自組織的原則下，共同來做決策，然後在一起來承擔責任所設計的遊戲，目的是在敏捷做前提下進行引導，在過程中，SM應該視狀況適時地做出許多改變遊戲規則的做法，例如: 先選出第一高票的人，在用指定的方式，讓持續引導的行為涵蓋整個團隊。其實團隊運作很多時候都可以採用這種民主決的方式來進行，目標是讓團隊一起做決策，然後透過遊戲來激發團隊成員一同參與的熱情。
.
註. 《石頭湯的故事》
作者：瑪西亞．布朗（Marcia Brown）
它是一本繪本，原文是Stone Soup，它不只是一個故事而已，圖片中引出了不少重要的含義，例如: 打破偏見，齊心齊力，終會成功。
「石頭湯」是歐洲家喻戶曉的民間故事。在法國、瑞典、俄國、英國和比利時，都流傳著不同的版本。
故事在描述三個聰明的士兵，如何運用智慧在既滿足他人又滿足自己的需求的情境下成功的完成了與村民之間良好互動的故事。
