看板的系統思維

.

.

.

.

.

.

.

.

.

.

.

 

 

如何創建組織文化

 

讓我們退一步思考「如何克服不利於敏捷意識型態的公司文化？」其實實行「敏捷」並不能解決組織的所有問題，事實上，還會在組織內部造成許多問題，因為敏捷幾乎跟務實劃上等號，而這會讓組織暴露出它的缺陷，這就好像我們作人一樣，如果太「務實」了，結果就很容易造成許多傷害ㄧ般。（這種務實的方式一般就稱為太現實了）

一個成長中的組織，總是在面臨著各種困難與功能上的失調中持續爭扎著，只是我們身在其中反到沒有查覺罷了。但要讓組織能夠存活下來的要素卻十分簡單，那就是在快速善變的資訊、社會風潮之下持續學習新知、然後持續成長改變，而不是忽略改變。

引入敏捷

引入敏捷化並非萬靈丹，如果組織原本就作對了的事，就不要藉著敏捷化的名義去異動它，反之，能引入精實（lean)的理念來進化它才是上策，這是我們推行看板方法的初衷(讓lean 與 scrum 交互並行)。許多打算導入敏捷的組織，其實不是想要來一場革命，他們真正想要的是能夠走得更快(敏捷二字太容易讓人誤以為他是一種快速的開發方法)，或是想讓產品更早上市而已，又不需要犧牲任何東西，這是「客製化敏捷」的典型思維，他們並沒有打算接受改變的準備，所以我們常說推廣敏捷必需由上往下才會成功，因為主管的敏捷性決定並且主宰了組織是否持續推行敏捷化的工作(作顧問的最再意的則是如何才能協助組織學習與獨立)。

改善文化，從「溝通」的效能開始

由於要引入敏捷的新概念，有一種作法是對組織先進行全面的評估作業，目的是為了找出對敏捷的認知、知識能力、支持與反對、實作技能等方面的落差，這可以有效的評估導入敏捷的過程中可能會遇到的阻礙及讓作法更明確，然後擬定策略逐步的來縮小這種落差，這是一種有效的作法。但基本上，還是先改善最基礎的「溝通」問題吧！身為顧問，我會經常詢問高階主管當你下達一項命令時，底下最基層的員工要多久才能正確無誤的得知這個指令。是這計算一下；這就是你團隊的溝通效能了。首先要打通這個關鍵點，然後再在上面施力才能有事半功倍的效果。這個關鍵點就是系統思維（System Thinking)之下所謂的槓桿點。

製造「提問的文化」

看板正是製造這種文化的最大利器，團隊需要有團隊的看板，或是開發Dev的看板或是維護Ops的看板（其實DevOps是不該分開來的，即便他們是二個團隊）,而主管則應該有屬於自己作決策時所倚仗的看板 (決策看板)，它可以用來發覺那些需要衡量俱有風險的項目，並要求進行衡量之後再協助下達決策。

看板讓許多我們本以為應該是這樣的事情變得透明化了，大家都看見了現實的工作進度及狀態，但那些看不見的事情呢？那些我們無法控制的等待或是依靠他人來完成的事情呢？(例如: 委外開發)請試著用提問來描繪它抽象化的外型或狀態。只要這項資訊值得我們去衡量來幫助決策時，就去進行衡量的工作，這會幫助你看見許多無形的事物。

當然的，我們自己就是公司文化的ㄧ部份。我們透過學習成長獲取經驗也累積了公司的無形資產，也就融入了公司的文化中。而要創造敏捷的文化當然應該用敏捷的方式來達成，這正是杜威(註 1.)所謂的經驗學習法則，它經由外來問題產生的「刺激」引發我們實際體驗、概念、觀察與行動的彼此交融辯證而產生ㄧ種統合整理的歷程，透過這種方式去驅動成員產生學習的動能，進而對經驗的「觀察」反思，產生特有的「認知」，爾後我們就能憑據這種學習後的認知來作「判斷」的依據，這便行成了所謂的智識，當然它依附在組織之下，而成為組織文化的ㄧ部份。

.

經驗主義就是依據迭代的方式做累積

.

這張圖示大家應該似成相識，杜威的經驗學習模式也正是敏捷所謂的迭代的方式。這一點也驗證了敏捷開發實際上是奠基在持續學習之上，且同樣是一種經驗主義下的產物。他的名言:「教育及改造」，這正是我打算用教育來改善組織文化這種想法的根源。而做法則是推行「提問型的文化」。

「提問」如何改變組織文化?

只是問問題為什麼能改善組織文化呢? 試想；當我們問別人問題、並請他們和我們一起找答案時，這時不僅僅是資訊的分享，也是責任的分擔。因此一個提問型的文化是一個分擔責任的文化。同時，當責任分擔後，大家就會交換意見、共同來解決問題(因為，問題已經不在是你的或我的了，而是我們的)團隊的互助文化也就油然而生了。提問真是好處多多，但是一樣需要練習，它也是經驗主義。(註 2.)

 

問對問題是成功領導的第一步。

.

小結

我的習慣做法會是先採用 “奧卡姆剃刀”法 Occam’s Razor (註 3)，也就是先找到組織的核心價值，然後集中發揮他應有的資源，接著進行簡化再簡化的動作。一般的做法是採用雙管齊下的方式，其一、首先是簡化流程，避免不必要的文書作業，建議引入 ITIL 的(Information Technical Infrastructure Library，是一套公開、並用於規範資訊技術服務管理的架構)辦公室自動化標準，目的是讓組織的行政效能提升（如果我們只用敏捷的角度去看一個企業的轉型，就容易忽略了組織在行政上的改善機會）。再來才是引入敏捷，也就是開始做教育訓練課程與輔導，讓開發及維護的效能提升。作法則是先以看板做開端，先接受現在的工作方式，讓「看見」的看板理論來觸發團隊主動自己改善的意願，接著才是逐步進入Scrum 的開發實務。而我以為必須要讓他們學會這一切才行(理想是這樣，但實際上只要組織開始進入學習的模式就成功了，經驗會讓他們自然的越變越好)，而我以為最好的作法就是讓領導者能學會提問的領導模式(過去我總以為 Scrum Master一定要學會提問的技巧，但實際上主管才是重點)，其實就是一種大家共同負責的模式，團隊也能開始真正為自己的工作負責，這就形成了一種自我管理的模式，則組織自然就會朝向敏捷化的方向在移動了。

.

 

註 1. 杜威 John Dewey，1859年10月20日－1952年6月1日

是美國哲學家和教育家，與皮爾士、詹姆士一起被認為是美國實用主義哲學的重要代表人物。杜威最重要的兩個教育思想：連續性以及實踐中學習（也就是: 從做中學習）

對杜威來說，創造充分的條件讓學習者去「經驗」是教育的關鍵：「所謂經驗，本來是一件『主動而又被動的』（active-passive）事情，本來不是『認識的』（cognitive）事情」，杜威「把經驗當作主體和對象、有機體和環境之間的相互作用。」他主張以這種進步的（progressive）教育方法使學習者從活動中學習，經驗本身就是指學習主體與被認識的客體間互動的過程。但他又說：「經驗的價值怎樣，全視我們能否知覺經驗所引出的關係，或前因後果的關聯。」並不是每一種經驗都是有教育的價值的，對經驗過程逐漸形成的主體的詮釋是關鍵所在。正因如此，杜威亦指出培養出學習者自習能力是教育的功用，他說：「教育功用的經驗的另一方面，即是能增加指揮後來經驗的能力。」他把這種能力的培養稱為「改造」，所以他說「教育即改造」。

.

註 2. 參考自《你會問問題嗎?》 by Michael Marquardt

.

註 3. 著名的 “奧卡姆剃刀”法 Occam’s Razor

他所主張的“思維經濟原則”，概括起來就是“如無必要，勿增實體。”因為他是英國奧卡姆人，人們就把這句話稱為“奧卡姆剃刀”。
他: William of Occam，約1285年至1349年，英格蘭的薩里郡，奧卡姆 是他出生的地方。
這把剃刀出鞘後，剃禿了幾百年間爭論不休的經院哲學和基督教神學，使科學、哲學從神學中分離出來，引發了歐洲的文藝復興和宗教改革。

事實上，我們的組織正不斷膨脹，制度越來越煩瑣，文件越來越多，但效率卻越來越低。這迫使我們使用“奧卡姆剃刀”，採用簡單管理，化繁為簡，將複雜的事物變簡單。

為什麼要將複雜變簡單呢？因為複雜容易使人迷失，只有簡單化後才利於人們理解和操作。隨著社會、經濟的發展，時間和精力成為人們的稀缺資源，管理者的時間更加有限，許多終日忙忙碌碌的管理者卻鮮有成效，究其原因正是缺乏簡單管理的思維和能力，分不清“重要的事”與“緊迫的事”，結果成為了低績效或失敗的管理者。從這個意義上講，管理之道就是簡化之道，簡化才意味著對事務真正的掌控。

 “奧卡姆剃刀”三法
1、精兵簡政，不斷簡化組織結構 。
2、關註組織的核心價值，始終將組織資源集中於自己的專長 。
3、簡化流程，避免不必要的文書作業。

.

主管房間裡的看板

.

以決策為主的看板

.

分成二個部分來協助主管管理它底下的專案與團隊，第一部分是看見追蹤紀錄。第二部分則是用來協助主管進行決策分析的部分。

• 追蹤紀錄(涵蓋 Dev開發 及Ops維護 的全面考量)

• 決策分析 (運用逐漸成熟的大數據及人工智能所提供的範圍與機率等數據式的資訊，協助主管進行決策，包含: 衡量、槓桿點與決策三個欄位)

.

決策分析

曾經幫一些主管設計他們房間裡的看板，那個時候我心裡想的是戰情室的構想，因此詢問了主管想要得到的資訊是那些，就直接以滿足他的需求來做設計囉。但是這個主題一直困擾著我，到底主管房間裡的看板應該做到那些事呢?

 

決策!

現在想起來，應該以協助主管做各種決策為主來設計看板才是。甚至能夠提供預測的資訊就更有價值了。主管如何做決策呢? 通常是試透過「衡量」，依照觀察所得來的資訊去做決定。過去我們常常說:「如果不是自己所能控制的因素時就可以不放進看板裡」，但萬一碰到委外開發時，有需要掌握的事項時，則多半以紅、黃、綠燈的方式來表現在看板上頭（如果能更進一步運用較精確的數據來作依據，對決策的準確度就更有把握了）。其實；這個時候就可以交給位在主管辦公事裡的看板來做好風險的控管，由主管來監控並進行衡量後做成決策。

.

把一個問題敘說清楚，這個問題就已經解答了一半。

–          查爾斯.凱特靈

.

衡量 (measure)

把衡量放在主管進行決策分析的第一個動作，目的是要打破一般主管主觀的將許多事物看成是不可衡量的，因此做決策時的資訊就少於應該有的資訊，因而提高了錯誤的機會。其實萬事萬物都是可以衡量的(註1)，而且大多時候你都無須大動干戈就能獲得足夠的資訊來進行決策分析。做衡量時，我們真正該弄清楚的不是一個明確的數值，而是藉由降低對事情的不確定性來增加做決策時的正確性。

.

若我們能夠衡量資訊本身的價值，便可以運用它來判定進行衡量的價值。其實因爲我們去衡量而誘發的價值，也十分值得關注，打員工績效的KPI就是ㄧ個最好的例子。因此在這個板子上的種種績效，都是員工視為追求表現的事跡。主管可以善用這種看板的透明化讓團隊持續處於積極進取的工作狀態。

.

這裡所謂的衡量是指向度量的範圍及機率，並非指向ㄧ個明確的數值，目的就是要你不必對不清楚的事情或事實去作猜測性的假設。而是用範圍與事情可能產生的機率來協助你作決策。例如: 蒙地卡羅模擬法(註3. Monte Carlo Simulation)目前已廣泛被運用在金融工程學，宏觀經濟學，生物醫學，計算物理學等地方，但在未來 AI人工智能與大數據的強力推展下極可能成為風險分析的基礎運算範疇。

 .

「衡量的定義」:

根據一項或多項觀察，以數量表達的方式來降低不確定性。

.

 

槓桿點

就是改變系統的關鍵點。這是系統思維(System Thinking)的基本理念，將看到的問題視為是系統結構的一種表徵，當我們想解決問題時必須擁有全盤性的考量，思考要如何才能將資源投入到解決問題的系統結構上。這裡所謂的槓桿點，指的就是在系統某處的一個關鍵點，當我們施加一個小的變化時，就能導致整個系統行為發生顯著而巨大的轉變(註2)。

 

 

小結

我是基於二個理念來決定為主管看板加入「衡量」與「槓桿點」二個欄位的。第一點、是想協助主管降低下決策時的不確定性(先進行衡量，在做決策。千萬不要有先入為主的觀念，認為這件事是不可或不易測量的或太花時間）。第二點、則是系統思維，這是實行DevOps 三步法的第一步原則。應該以動態的系統思維來考量解題時應該關注的施力點，而不要以線性方式來作思考(例如: 二倍的工作量的需求，就可以以加入二個人力的方式來解決。但是，動腦的工作，絕不是 1+1=2 這麼簡單的，它是非線性的)。

 

主管房間裡的看板，跟團隊日常站立會議的看板有何差異呢? 其實主管也很需要回饋也需要與團隊溝通，因此這個看板是主管在下決策前用來與團隊進行討論的一個基礎看板(團隊中可能有Dev 的看板及以維護為主 Ops 的看板，但在 DevOps 的系統思維下，是不應該把開發及維護的看板區分開來的)，它陳列的是我們追蹤到的紀錄，並敘述了主管衡量後的結果，其中包含了我們認為可以據以改善系統行為的關鍵點，也就是槓桿點。這個板子充分的展現了主管下達決策時的考量，跟足以支撐這些決策的關鍵因素。他讓（主管）一向神秘的決策變的公開而透明，是實行DevOps時的一大基礎。

.

(這裡不對追蹤紀錄的部分做說明，有疑問的話來聽我的演講吧!)

.

 

註1. 萬事萬物都是可以衡量的

◆ 麻省理工學院指定教材，長踞亞馬遜網站商業類暢銷榜，一生受用的衡量技術！

商業、科學、生活上所有問題的解答
任何需要做分析、決策的人必讀之書

世界上沒有任何事物是不能被衡量的。
所有看似無法量化的難題，
只要能讓你知道得比以前多，就是一項成功的衡量。
本書對於降低決策風險、排除不確定性，大有幫助！

 

註 2. Thinking in System 《系統思考》 by 唐納拉.梅多斯

系統思考，是以整體、動態去思考問題的思維模式，
是複雜動態系統中「化繁為簡」的智慧。
提升系統思考的能力，才能克服思考盲點，
面對複雜性的挑戰，進而徹底解決問題。

工作，其實就是不斷地解決問題，然而，有些問題遲遲無法解決，或是即使換人改用不同的方法，也找不到好的對策因而疲於奔命。事實上，這是因為面臨「複雜性」的挑戰，牽涉到「系統性的問題」。

 

註 3. 蒙地卡羅模擬法(Monte Carlo Simulation)是一種基於大數法則的實證方法，當實驗的次數越多，它的平均值也就會越趨近於理論值。 蒙地卡羅模擬法最能涵蓋投資組合的各種風險因子，尤其是某些難以進行估算的非線性投資組合(如含有凸性的選擇權等)，只要假設合理，此模擬能將分配精確的呈現出來。不要從這裡開始，除非你是ㄧ位經驗豐富的分析師，否則我會建議由常態分布曲線（normal distribution）開始。

 

作決策時，另一個很推薦的是 丹尼爾.卡納曼 的展望理論（英文：prospect theory），是一個行為經濟學的理論，為心理學教授丹尼爾·卡內曼和阿摩司·特沃斯基提出的。這個理論的假設之一是，每個人基於初始狀況（參考點位置）的不同，對風險會有不同的態度。它之於經濟學的貢獻就好像敏捷對專案開發一般，推翻了許多古老的假設，以務實化從朔了理論，並引起了巨大的改變（作者為此獲得 2002的諾貝爾經濟學獎）。公式如下：

.

 

看板之我思故我在

.

敏捷開發；實質上都是在處理人的問題。

.

參考自維基百科

.

我思故我在 I Think, Therefore I am.

敏捷開發；實質上都是在處理人的問題。因此我們不能不對行為科學有所了解。為了更了解人的行為模式，這就是為什麼專注在 Scrum 的人後來都跑去研究引導、精實或是系統思維(system thinking)的原因。其實行為科學就是心理學加上人類學的研究範疇，就是在研究人類的行爲，而如果我們弄不清楚工程師們爲什麼這麼做的因果關係的話，又如何來談改善呢？

》站立會議不是一般的例行會議，不是你報告完了就沒事了，它是提供你在這裡跟著大家一起學習、一起成長的地方。

但這裡想談得東西，其實是因為看到許多運用看板在執行站立會議的團隊成員們經常沒有把心給帶上。只是人站在團隊中，輪到我報告的時候就是交待一下工作的進度就了事了，少了團隊組合裡的責任與義務，也就是對團隊事務的參與。為了這一點，我經常在自己顧問的團隊裡給出會議的宗旨，例如: 專案開始之初，第一周的主題一般都是「專注」。(我用Scrum的價值觀來做站立會議的主旨，它們是: 專注、承諾、公開、尊重、勇氣)而我以專注做開始，實際上是為了在專案開始之初，要求成員盡速的把手頭原有的工作完成或交接清楚，如此才能專心在這個專案上頭。其實任何會議都應該有一個明確的宗旨，否則就容易讓來参加的人變得行屍走肉般的缺乏目標式的参與。

 .

站立會議的四種提問模式

在看板前運行站立會議不是一層不變的，怎麼問、問些什麼? 詢問問題的內容、形式跟得到的答案或效果也將大不相同，以下是我整理出來的四種模式:

•  激勵提問模式

•  品質提問模式

•  反思提問模式

•  領導提問模式

重點不是在選擇哪一種模式來進行，而是在是否能產生「有效的提問」(註1.)，選擇使用那種模式只是用來弄清楚希望獲得的效果或是想要達成的目標是否達到了。因為站立會議的時間簡短，必須迅速的問到重點。因此提問的技巧及方式就非常重要了，他是經驗主義的產物，你必須透過經常性的練習才可能達到好的提問效果的。說明如下:

● 激勵提問模式

這一點幾乎是所有團隊行為裡必然會被問到的基本要素，共同激勵模式。我們可以從球場上每一節都有的簡短休息中看到教練在休息室裡頭運用慷慨激昂的喊話來激勵球員，團隊成員幾乎沒有個體回應的機會，問的問題也都運用封閉式(註2)的提問方式，團隊瞬間成了一個凝結起來的個體，一致的回答讓情緒快速的高漲了起來。當然在站立會議上我們不必要運用喊口號的方式來激勵士氣或提高大家的腎臟腺素，光是運用掌聲其實就夠了。

相對於激勵模式之下的是可以打擊團隊士氣的提問方式 – 打擊式的提問!當我們把問題重點放在「為什麼未能準時完成任務」、「是誰跟不上進度」。這類有歸罪責任傾向的問題時，常常會立即導致被詢問者打開自我反衛能力的保護傘，是站立會議時最應該避免的提問方式。

● 品質提問模式

由於軟體品質的好壞幾乎和整個開發的過程都息息相關，因此在站立會議的進行過程中被詢問到最多的問題，幾乎都是跟品質有關的提問: 「程式碼做過code review了嗎?」、「有作單元測試嗎?」但這樣問的效果常常不良，若能改變一種方式來提問(這類問題都是跟程式設計人員的基本素養有關的問題)，以主動協助式的提問方式會比採用上面那二種被動式的提問要有用的多，例如: 「讓我來幫你做測試，如何?」、「有誰對這段程式碼有興趣的?」。若是能夠讓團隊整個動起來，則效果更好。具體上可以這麼做，將團隊分成數組，分別負責單元測試(單元測試小組)、負責code review(程式碼檢核小組)，就能夠在有人異動工作單時，藉由負責的小組主動發問，主動要求協助。這種既具有提醒作用又有主動提出協助的方式將可以大量提升團隊的協作能力。

● 反思提問模式

試問要如何讓一個人改變他的決定? (尤其是那種固執的可以的人物，例如: 老闆。註2) 答案是: 「問他一個會讓他進入自我反思的問題」。藉由當事人自我的省思，是觸發一個人改變行為的最基本條件，至於他會做什麼樣子的選擇就另當別論了，這種引導的過程，有一個專有名稱叫做「引導反思」。

當遇到需要集思廣益來共同解題時的最佳提問方式。團隊會透過這種協作方式而變得更為團結、默契更上層樓，人們總是把一起學習一起成長的伴侶視成知己，合作起來效能當然就更好了。

提出讓團隊成員產生延伸思考的問題。例如:

•    這種做法可以得到什麼效果呢?
•    能不能舉個例子，或說得更清楚一些?
•    有沒有可以二者兼顧的做法呢?

 

● 領導提問模式

傳統的領導方式是採用告知的方式。就是直接把重點告知下屬，讓他們照著做，用來避開在自我學習的過程中所可能產生的時間浪費及風險，但這麼做固然快又不出問題，可是這麼做卻會破壞團隊自我管理的機制，不但會限制了團隊發展的潛力，也會無形中讓團隊解決問題的能力下降。在這裡，我所謂的領導則是指向類似教練模式的指導方式，領導者不是以下指導棋的命令方式提問，而是以教練作指導鼓勵學習的方式來進行提問，讓團隊成員能夠透過討論或是集思廣益的方式來進行解題。你可以這麼提問:例如；

• 「這麼做固然可以解題，但大家想想看是否還有其他方法可行?  張三你來說說看 」

結論

請把專案開發視為是一種創意的行為，而不是一種解決問題的手法。這是一種跳脫系統來回擺盪的方法。(註4. 請參考《最小阻力之路》這本書的副標題:以創造力修練取代「不斷解決問題」的人生結構革命。)這是系統思維的基本考量。如果你對Scrum、Agile、Lean以至於 System Thinking還有些許迷惑的話，請參考下面這一張圖示。

.

.

實在很難去界定什麼樣的提問是問了個好問題，但好的提問卻擁有一些共同的優點:(註4.)

．讓人專注並竭盡心力。
．創造深度的自省力。
．挑戰那些被視為理所當然的假設；它阻礙了人們用更新更有力的方式做事。
．激發勇氣和力量。
．引導突破性思考。
．掌控打開通往解決途徑之門的鑰匙。
．讓人對情況看得更清楚。
．讓人敞開心胸、思考得更透徹。
．考驗假設，讓大家思索為何他們會這麼做，還有為何他們會選擇採取行動。
．激發正面及強有力的行動。

.

註1. 有效的提問

提問難在哪裡? 我們經常在問問題時，太過專注於立刻想把問題給解決掉，經常不能等到被詢問者經過較完整的思考所作的回答，就急著想下結論了。因此就經常得不到好的回答，因此一個有效的提問必須要考慮到在正確的時機點提出正確的問題，並得到預期的效果。

參考自《你會問問題嗎?》 by Michael Marquardt

 

註2. 每當我想到這個問題就想到《Inception》全面啟動 這部電影，主角李奧納多 費了千辛萬苦，設計了一層又一層的夢境就為了改變繼承人的一個念頭(放棄父親既有的事業，重新建立自己的事業)，如果把這個問題交給你來，你會怎麼做呢?

註3. 引導反思 Processing

五南出版社.吳兆田先生出的書《引導反思的第一本書》

註4. 同化 Assimilation

專案開發是一種創作的過程。依系統思維的方式來觀察人類創作的三個主要階段:分別是萌芽期、同化期及完成期。同化期則是我們在學習組合過程中，用來聚集能量以堅持到最後完成的必經過程。

參考自著名的《最小阻力之路》by Robert Fritz.

.

我的自行車史

.

一早醒來，突然覺得應該記錄一下這幾年騎過的不同種類的車款。(也就這些了!)

.

Giant XTC 2005紀念車(全一級配備，8公斤碳纖車)

.

特殊的FUJI 3盤公路車

.

漂亮的 FUJI 座管一體的單速車 (49 X 15)

第二台單速車(48 X19)，終於騎上冷水坑了

.

太平洋 Carry Me 小車(採用特殊腳變，有二速)

.

A-BIKE我在深圳買過3、4台這個車，輪子太小不好騎。

.

傘兵車，還買了許多套件（但沒有M16)大折 15~20公斤重

.

FUJI Wedgio 雪怪 4吋胎

換了一個2公斤的座墊

這輛捷安特的胖車是買給老婆的(視覺系)

.

西班牙 MSC Fat Bike(鋁車架，前雙盤，但奇快無比)

.

往風櫃

.

古典胖車 FIGO以足球名將的名字命名

KHS 5000 在石碇往烏來

.

MSC的碳纖車(12公斤左右)

.

採用 VOODOO 車架 的高檔小胖車，3吋胎

.

騎士的心聲

瀟灑  vs.  滄桑

騎士的內心裡一直以為自己騎得很瀟灑像左邊這位(多瀟灑)，但事實上右邊才是我們(一副鞠躬盡瘁的滄桑德性)。其實；這個大家都心知肚明，只是總要有一個目標來追從吧! 而我一直以下面這個人為典範，原因很明顯。

史恩康納萊.出生日期: 1930年8月25日

.

深深覺得

人一定要培養一種興趣並終生奉行，因爲等老了之後跟著你的就只剩興趣而已了！

.

善用「站立會議」來建立組織的提問型文化

.

「沒辦法，這就是我們的企業文化。」

– 實施敏捷轉型的企業經常會這麼抱怨

我深信「提問」這個簡單的動作，卻擁有著無比的威力可以改變許多許多我們原本認為不可能更改的事情（例如：老闆早已下定決心了的事情，但可能因爲你運用風險式的提問，而產生重大的轉變，尤其是有關安全性的考量。 但由上往下的效果會更好，也就是倒過來由主管向屬下提問）。當企業要實行敏捷化的過程裡，它可能是唯一可以從根部做起的改變。就因為提問讓人深醒、讓團隊集思廣義，並足以作到徹底的轉變。雖然我沒有具體的數據來支撐我的想法，但我已經開始把這種技巧運用在自己所顧問的案例上了。

企業文化本來就會表現在主管們的身上，因此才會有:「主管的敏捷度是企業實施敏捷化的重要成敗因素」(註1)，雖然這是眾所週知的事(相信主管們也知道這件事，雖然我的課堂裡也常常會有那種很高階的主管出現，但是卻很少有人會問我，要怎麼樣作才能提高敏捷性呢？答案會是：採用「提問式」的領導方式，當你越能問出好問題的時後，也就是團隊越能發揮他們創意的時候了。試試看，它是觸發人們自省的力量，而它經常都在沈睡中)，但上面那句「沒辦法，這就是我們的企業文化」卻依然經常掛在大家的嘴上，到底有什麼方法可以具體的來改善企業文化呢? 這裡提出運用「站立會議」來建立組織成為一種「提問型的文化」，然後再透過形成提問型文化來改變企業文化。至於為什麼要透過站立會議呢? 因為這是每天都要實施的團隊共同的行為，而還有什麼機會比這個時候更適合一起來洗腦的呢? 不是的，而是站立會議本來就是設計成一種用來問問題的過程，因此最適合運用在經營提問型文化上頭（在看板前面的提問應該是詢問看板上所看不見的資訊，而會議預期的結果則是團隊受到激勵而更積極的展開開發作業）。

.

站立會議是形成提問型文化的最佳時機

.

提問型文化是什麼?

當我們問別人問題，並請他們和我們一起找答案時，這不僅僅是分享資訊，也是分擔責任。一個「提問型文化」是一個分擔責任的文化。同時，當責任分擔後，大家就會交換意見、共同解決問題(問題不是你的或我的，而是我們的)、一起承擔後果。當一個組織發展出提問型文化後，他也同時創造了我們的文化，而非你對抗我或雇主對抗雇員的文化 (From: Michael Marquardt)。

.

運用站立會議來落實提問的文化

問問題一直是中國學生最難身體力行的，這一點造成了畢業生進入社會成為社會人後也難以根除的不好習慣(其實歐美的教育，早已經是由學生上課提問的方式來進行教學的。註4.)，也就是很少能在大眾的集會場合裡大膽提問的習慣，但其實我們都知道，成員問問題是讓團隊透過討論的方式解決自己的問題的最好方法(註2.而不是由上級直接下指令)。因此在每日實行的站立會議上讓團隊成員確實提問將是團隊自我管理的最佳實踐。目前大家實施站立會議時仍然是以Scrum Master 提問的方式居多，這樣做當然沒有什麼問題，但若是能夠由團隊成員交互提問的話，則這種行為將逐漸形成團隊的提問文化（賦與團隊成員不同的任務分組讓他們有機會各司其職作提問的練習。例如：某人負責品質組，某人負責code review,等）。具體說來；就是當有人移動工作單時(選擇新工作項目或完成工作項目時)，工程師們互相關心彼此的作業方式的詢問，將會藉由彼此關心及交談進而帶動相互間的協同合作模式，團隊可以藉由分組或相同性質的組合小團隊來訓練提問的技巧。讓提問文化落實於小組之間。藉由小組擴充到團隊，並藉由團隊來影響整個組織。

.

提問型文化的基本認知

首先要讓團隊成員願意承認「我不知道」。因為沒有人是無所不知的，尤其是在這個資訊爆炸的世界，往往承認不知道時反倒是學到最多的時候。因此在接受別人提問時，不但要能夠接受而且要相互鼓勵提問，然後再一起來尋找答案，達到雙贏的策略。當然；需要培養出一套會問問題的技巧，而且能夠問對問題，尤其是不應該問那種打擊信心的問題，反之；應該問那種具有激勵型的問題，讓交互問答的過程來形成解答，而無需去強調什麼才是對的答案。因為往往業界的標準答案卻不見得就適用在你們的團隊裡。

.

敏捷文化就是一種學習型的文化

一個提問型文化會造成大家經常性的提問，重點並不見得是要找尋那個答案，實質上反而是去促成一種熱愛學習的文化，在一個組織裡大家透過提問和學習的方式去創造團隊的共同開發成果。況且；對於許多問題而言，其實沒有什麼所謂的正確的答案。重點是要能夠造成大家的共識才重要。彼此詢問；能夠透過團隊成員在不同的觀點下透過討論來尋求共識，是形成組織持續成長的一個重要過程，而當然也就能夠自然地形成團隊自我管理的文化了。

.

最有用的問題，是那些讓人學會從別人的角度看事情、然後自我反省的問題。

– 蘇珊.米其林

.

提問的重要性

好的提問能夠撞出多少好的成果? 《禮記·卷十八 學記》 裡講到: 「善問者，如攻堅木，先其易者，後其節目，及其久也，相說以解； … 善待問者，如撞鐘，叩之以小者則小鳴，叩之以大者則大鳴，待其從容，然後盡其聲；不善答問者反此。此皆進學之道也。」

請善用站立會議時的詢問：在看板前面，為一張剛剛完成的工作單問出「過程」，技巧而細緻的詢問讓大家就好像都看見了現實的開發過程，並為這個工作項目打上(品質的)分數。

.

結論

改善組織文化看似很困難，而且總給人一種需要很長的時間才可能會奏效的感覺。但其實透過簡單的問問題就能由改善組織的溝通效益，進而改善組織的文化。

因此請思考: 如何作好提問？如何建立組織的提問型文化?如何在短短的15分鐘內達成目的。 這不是Scrum Masterㄧ個人的責任，當然SM也沒有必要ㄧ個人絞盡腦汁的從頭問到尾，實際上要能觸發團隊成員在必要時進行彼此交互發問，透過這種方式也才容易廣泛的獲取大家的意見。前提只有一個，那就是作好「有效的提問」？(註3.)讓團隊在有限的時間裡大量的交換意見，並尋求共識。除此之外，要讓團隊成員停止報怨公司文化的前提，就是讓他們有機會去創造自己團隊的文化，而這種機會其實就隱藏在學習型組織成長的過程裡，所以務必在實施良好提問情境下，形成團隊知不足而勇於學習的精神，自然能讓文化成型。

是的，提問型文化能夠強健團隊並改變組織的文化，團隊成員透過持續學習的成長方式來建立協同的運作模式，他也間接的促成了團隊自我管理的成效，讓企業能夠更敏捷化。

》這樣子的作法會不會讓站立會議變得太沈重了些，會因此而造成站立會議大量超時嗎？

很多人都誤解了站立會議，他是ㄧ個相當高成本的會議，雖然只有短短的15分鐘，但在sprint的週期內全員都必須每天参加，所以應該要開得越是簡潔而有效益才是，應該盡量去增加他的CP值，而促進團隊學習與讓團隊自行系統化的運作，可以說是效益較高的行為了，值得投資。

.

好的問題會激勵人心，而一個提問型文化可以激勵一整個組織。

– Margaret Wheatley.

.

註1. 主管的敏捷度是企業實施敏捷化的重要成敗因素

在 Ken Schwaber 與 Jeff Sutherland 合著的《告別瀑布擁抱 Scrum》一書的書尾 P174頁的地方，有一封Ken Schwaber 致某某公司CEO的信件裡寫道，實施Scrum的成敗關鍵在您(CEO)的身上。

.

註2. 《引導的秘訣》 The Screts of Facilitation  by Michael Wilkinson 著

引導的祕訣一、當解決方案是由受到其影響的人所產生並被他們理解和接受時，往往可以得到更加有效的成果。

.

註3. 「有效的提問」被公認是解決需求模糊、認知不一的最佳方式。

「提問」是解決 Kent Beck 這張認知不一圖示的最佳方式

.

註4. 翻轉課堂 Flipped classroom

是一種新的教學模式，2007年起源於美國，翻轉課堂會先由學生在家中看老師或其他人準備的課程內容，到學校時，學生和老師一起完成作業，並且進行問題及討論。由於學生及老師的角色對調，而在家學習，在學校完成作業的方式也和傳統教學不同，因此稱為「翻轉課堂」。

.

團隊如何解讀看板 – 1分鐘統計報告

.

許多敏捷團隊都已經運用看板進行站立會議，但卻仍然採用傳統Scrum站立會議的三件事來進行會議:

• 昨天做了什麼?

• 今天準備做什麼?

• 有沒有遇到障礙?

 

對看板而言；其實這三件事都已經記錄在看板上了。雖然這種做法基本上沒有什麼問題(我也一直是這麼做的，但總是會覺得好像有些不足的地方，好像可以作得更好才是，因為這是團隊共同的事，所以應該是團隊一起運作才是，一問一答的輪詢方式似乎太個人化了?!)。這麼做會忽略了看板上已有的資訊，而無形間浪費了看板上的基本資訊，也就是團隊在「視覺化」上的認知機會。團隊也會因此把焦點放在了個別成員的身上，而忽略了看板所具有的團體性。那要怎麼做才能充分運用這些特性呢? 一種看板式的站立會議，它是以團體為主的方式，它專注於回饋(一分鐘統計報告):

.

適合團隊共同運作的看板式站立會議

.

一分鐘統計報告

首先；運用值星生的方式，讓團隊成員輪流擔任這個職務，輪到的人，就要負責看板的維護工作，然後必須在站立會議時做先期解讀的工作，先幫大家做一次統計式的解讀，目的是協助團隊迅速進入狀態。然後才是由SM負責一對一的輪詢，問的內容當然就不止於那三件事了。進行的步驟如下:

• 設定「值星生」的制度，以一個星期為一輪，讓他負責日常看板的整理工作還有看板的維護。並於站立會議時首先發言，用一分鐘來向大家解譯目前的看板狀態，讓團隊能迅速進入狀態，而無須重新做個別解讀。提供團隊一起能夠同步看板的視覺認知。這是一種單向的報告方式，團隊無須立即回饋。「值星生」必須以統計分析的方式進行報告看板現狀。

• 然後由SM 接手以 提問 的方式輪詢團隊成員個別的工作狀態，並要求成員對值星生的報告進行必要的解釋或回饋。

• 最後，SM針對個別事件進行 重點討論，詢問團隊是否變更流程以解決障礙、等待Waiting狀態說明及討論是否需要進行變更(WIP值)來改善流程速度，作總結或重申重要事項。

.

參考自一日看板遊

.

統計式的看板解讀

解讀上圖: (← 由右往左)

》團隊還沒有成功的發佈任何東西，因此發佈欄位是空的。

》有一個嚴重障礙，就是測試區Task-A 無法被正常布署，沒能夠通過測試，測試人員正在努力中，但因為測試欄位的 WIP值設成1(因此只要有任何一項測試失敗看板就會被卡住)。

》這時候當初做Task-A的成員正在做 Task-C（是否請他們協助偵錯? 畢竟解鈴還須繫鈴人），而另外一組成員已經做完Task-B了，但受限於看板測試欄位的上限WIP值因此無法移進來做測試，因此沒有進度。

》預備欄位目前只有一個 Task-D 可以再移入一項工作。

》此時產品負責人PO仍在審視所有的工作項目。

看板解讀由右往左的目的是希望能盡快看到障礙，尤其是上圖中將測試欄位的WIP上限設定成1，表示這個團隊非常重視品質，只要有任何一個測試失敗的工作項目，團隊就要停下來解決，一直到解決之後才能繼續開發的流程。當然我們可以考慮把WIP上限調高，但這樣做了就會延遲解決問題的速度，但仍然能夠持續有產能輸出，好處就是生產線不會完全停下來。

 .

善用值日生

看板需要整理，又必須與工具(ALM: Application Life Cycle Management)同步，SM常常為此抱怨連連。採用值星生的方式能夠適當的降低SM的負荷，又能多一個人出來管理、解讀看板。是團隊落實自我管理的一種實踐。

因為以星期為範圍所以稱為值星生好像比較準確。看板值星這件事，勢必會造成「值星生」不得不在站立會議之前先行整理過看板，然後再運用統計的方式先行解讀過看板，然後才能在站立會議時運用足夠簡潔的語句描述給團隊聆聽，而團隊也會因為有人代為解讀了看板，便可以省下各自解讀的時間花費，一起聆聽看板解讀也能造成大家對看板上的動態有更一致的認知。同時這也是一種回饋的方式(只要團隊成員聽完後覺得跟自己的解讀有所差異時，此時成員之間任何的交談與討論都是極具價值的)。

.

小結

團隊共同解讀看板的方式:  （站立會議開始）由「值星生」先為大家以統計的方式做1分鐘看板解讀，然後才是由 SM 接著進行輪詢團隊成員，成員一一更新看板上的工作項目，同時就剛剛值星生的解讀進行解釋或更正。完成一輪後SM 做成重大事項的總結或重申重要任務。站立會議於 15 分鐘內結束。

.