手快一定打手慢，唯快不破的合作方法（中）：Scrum 加速的方式，出招與變招

3/11/2015 01:11:00 PM 0 Comments

接續上一篇 Scrum 文章：手快一定打手慢，唯快不破的合作方法（上）：Scrum 異于常人的基本假設

先來一點心理建設，你的團隊並不會像是學了瞬身術的鳴人，馬上變成黃色閃光，相反的，團隊的加速，會是在你暖身後，習慣節奏後漸進式的達成的，感覺起來有點像是在學跳舞，一開始你很賣力地跟上每個節奏，隨著你的心，技，體慢慢地成熟，你會很自然地可以加快節奏，並在節奏中做出令人驚豔的動作。

Scrum 實踐的秘密，可以說全都在於這個節奏之中。

回到拳法的比喻上， Scrum 加速的方式有兩個層面，一者是出招速度的加速，由 Scrum Master 負責帶領，另一者是變招的速度，由 Product Owner 負責操刀。

出招的速度：Scrum Master - PDCA

Scrum 的執行單位是以 backlog 中的 user story 所組成，這兩個術語的定義我們下篇再談，現在請先把這些執行單位想像成待辦事項即可。

Scrum Master 的角色，就是負責想辦法把這些待辦事項迅速確實地處理完成。一般而言，在好的 Scrum Master 的帶領下，團隊消化待辦事項的速度會越來越快，以我自身的經歷來說，團隊可以在同樣長度的時間下，吃下 2 到 3 倍的工作量，主要是因為 Scrum Master 做了下列三件事情：

1. 團隊合作的加速 - 以短跑（Sprint）為單位，定期 Demo 進度

在傳統的干特圖（Waterfall Model）中，所有的執行細節在開春第一天之前都全部定義好了，所剩下的，只是找個執行團隊，照表操課，把一切都執行出來罷了，如此簡單，應該不費吹灰之力是嗎？畢竟難的部分是腦力規劃的工作，用腦工作的，賺得本來就比用勞力工作的人多，不是嗎（XD）？

紙面上一切看起來相當完美，只要我把這個完美的干特圖規劃交辦下去，每個人都應該知道每個人的工作與應有的進度，戮力執行，我只要定期開會，確定專案 on budget on time ，不就天下太平了？

問題是，執行是人做出來的，在多人合作的團隊中，溝通成本認知成本隨著人數呈指數性增加，很可能的情況是，有多少人，就有多少種對進度與工作的定義認知，就有多少種實作的想法與優先順序，你坐在干特圖的另一邊，怎麼管理這些在干特圖上面看不到的事實？

於 是在 Scrum 中，執行是以 Sprint （短跑）為單位，你可以依照工作的本質來定義 Sprint 的時間，一般而言，矽谷 RD 團隊會以 2 周為一個 Sprint 的長度，如果是客戶 Support 團隊，因為要快速地回給客戶，一次 Sprint 可以是一天或是兩天。

在每次 Sprint 結束時，團隊必須要交付出一個可以 Demo 的產品，沒錯，不是報告，不是投影片，沒有陳核，不需要蓋章，你要直接刻出最終產品的某部分出來，呈現演示給『所有有興趣的人』看，接受所有有興趣人的測試與評斷。

有沒有摸魚整天打開心農場，就可以從這個定期的 Demo 中看出端倪，為什麼大家資質差不多，你所消化的工作量就是比較少？是不是有什麼心理/生理/家庭上的轉折？有沒有需要幫忙？有沒有需要改進？ Scrum 這種逢 Sprint 必 Demo 的方式，會讓團隊中所有人更負責任（Accountable）， Scrum Master 也才能及時處理團隊問題。

於是 Sprint 讓專案/產品管理者，能夠跟著每個 Sprint 的節奏，第一手地直接測試產品，參與雕塑產品成型，而不是只是坐在干特圖的另一端，遙想專案結束的那天，真實產品與理想中產品慘痛的差距。

隨著 Sprint 的推進，團隊與產品/專案經理的溝通與默契越來越好，團隊對工作的細節也漸漸熟能生巧，彼此間的溝通與合作漸漸進步，每次 Sprint 能做的事情越來越多，動作越來越精准，速度自然越來越快。

2. 剷除障礙的加速 - 把浪費時間的因素一個個剔除掉

Scrum Master 的另一個任務，就是剷除讓團隊慢下來的因素。

一 開始合作的時候，團隊還沒有發展出彼此的默契，有時候 A 在等 B 把某件事情做完，但是 B 並不知道 A 在等他，慢慢處理比較不急的 C 的問題，於是 A 就慢慢逛 Amazon 買電子書等 B ，因為事情不緊急，B 跟 C 也就慢慢來，輕鬆來，團隊進度就在這樣的慢慢等待中度過，等到花兒也謝了。

或是 D 與 E 在溝通上還沒有很純熟，每次 D 做出來的東西 E 都不能用，必須要回去跟 D 溝通修正，一來一往，又是時間的浪費，偏偏 D 跟 E 都是大忙人，怎麼都沒有想到下次實作之前，先坐下來把東西都定義清楚。

Scrum Master 於是適時介入，用 Daily Standup 或是 Sprint 結束後的 Review Meeting 及時處理讓團隊慢下來的情況， A，B，C 在下次 Sprint 的過程中，要怎麼更有效率地把工作優先權定義清楚？ D 與 E 這種來來回回的失誤發生多少次了？要怎麼在根本上剷除掉這個問題？有沒有團隊成員遇到自己沒有辦法解決的問題？或是本業以外的問題？跟其他團隊溝通合作的問題？ Scrum Master 可以怎麼樣幫忙解決？

更有可能的是，deadline 趕不上了，從管理層的角度來說，有沒有些東西真的沒有那麼重要，可以先捨棄不做？然團隊趕上客戶的時程？

在這裡 Scrum 借用的是 Toyota 在生產線加速中的理論，剷除障礙（impediment），減少浪費。

3. 團隊溝通上的加速 - Daily Standup Meeting 增加資訊交換的速度

一般的公司，大概是一周跟團隊開一次會議，會議的過程要不是照個甘特圖盯進度，就是照本宣科，聽上級談論他的家庭與奮鬥歷程（那些甘我屁事啊？）。

Scrum 在每個 Sprint 開始與結束分別有兩個 Sprint 的會議，我們下篇會談到，在這裡我想提到的事，是你看到工程師每天早上站 15 分鐘那場。

每天早上同一時間，Scrum Master 會聚集所有團隊成員，依序問他們三個問題：

• 1. 你昨天做了什麼？
• 2. 你今天要做什麼？
• 3. 有沒有遇到阻礙或是卡關？

前兩個問題讓團隊成員彼此交換工作上的訊息，讓大家比較有工作的背景資訊 ，重點在第三個問題，第三個問題讓負責人把問題『及早』丟出來，用所有團隊的人力資源集思廣益，如果這是個技術性的問題，其他成員可能有更好的想法或是解法可以用，如果這是產品定義上的問題，Product Owner 或 Scrum Master 可以及時跳入澄清解釋，如果這是政治上，管理上，或是合作上的問題，Scrum Master 要想辦法再下一個 Standup Meeting 之前給出一個交代。

非常注意的是，這三個問題都不是為了做進度，Stand up meeting 是在幫助團隊溝通跟發現問題，而不是在交代自己的工作，如果每天都有交出成績的壓力，團隊成員會有做短視決定的誘因，這是 Scrum Master 要儘量避免的。

（這邊感謝網友 Pengyu Chen 的討論與協助）

團隊的 Manager （有權管加薪人事的人） 如果參加這種 Standup Meeting，最好一句話都不要吭，不然會使隊友不敢說出自己的困難或是承認自己需要幫助，這對團隊的 Scrum 是有害的。

每個 Standup Meeting 都像是一次專案的心跳，把需要的資訊與資源送到所有需要的組織成員手中，心跳正常運作，團隊資訊交換的速度大大提升，進度與挑戰所有人都清楚，Scrum Master 可以一手掌握，比起週會的反應速度至少快上 5 倍（一周一次 v.s. 每天一次）。

Scrum 的團隊大小在 3 到 9 個人之間最佳，3 到 9 個人回答這三個問題，不應該超過 15 分鐘的時間，如果超過 15 分鐘，一定是哪裡出錯了。

Scrum Master 的角色是根據二次世界大戰後讓日本製造業起死回生的 PDCA （Plan 計劃，Do 執行，Check 審核，Act 改善） 理論而設的，上列團隊合作的加速，剷除障礙的加速與團隊溝通上的加速的練習，會在每次 Sprint 之後檢討改進，每次 Sprint ，就是一個 PDCA 的循環，不斷改善，出招速度自然不同凡響。

變招的速度：Product Owner - OODA Loop

你知道在韓戰的時候，蘇聯的飛機其實在性能上比美軍的飛機還要好很多嗎？但是在真實空戰的時候，美軍卻能夠以 1 比 10 的比例打掉蘇聯的戰機，沒錯，1 比 10 ！平均起來，美軍每被打掉一架飛機，蘇聯已經掉了 10 架飛機了，也就是說，蘇聯蓋飛機，訓練飛行員的速度要比美軍快 10 倍，才能跟美軍打上平手 XD。

主要原因在於美軍軍機，可以讓飛行員的反應速度快很多，在蘇聯飛行員看到敵機，準備交火的時候，美軍飛行員早已經扣下機鎗的板機。

沒錯，變招快，正是手快打手慢！

Scrum 中 Product Owner 這個角色，就是為了團隊的方向與反應而設立的。Scrum Master 只管團隊出招的速度，方向與變招的速度則是由 Product Owner 負責。

既然 Scrum Master 與團隊的主要工作是專注消化所有的待辦事項，把消化速度變得飛快，總需要有人負責出來制定這些待辦事項的細節與優先權啊，沒錯，Product Owner 正是掌管這兩項重要工作的角色。

如果方向不對，快速地執行只是加速死亡的過程而已，理想中，Product Owner 必須要是個對產品與產業生態非常熟稔與敏感的人，富有業界的經驗與人脈，能夠在大環境變化時迅速察覺，並帶領產品改變方向。

在 Growth Hacking 這麼興盛的年代，他對市場的理解並不能僅止于第六感，他必須要能夠以數字或是實驗說服（而不是強迫）團隊相信他所擘劃產品或專案的未來。

Scrum 在這邊的架構世借用美國空軍的決策框架：OODA Loop，Observe（觀察），Orient（研究），Decide（決定），Act（行動）。

1. Observe（觀察）

身 為 Product Owner 你必須要在 Observe 這個階段中搜集所有有用的環境變數，理想中，Product Owner 要花超過 50% 以上的時間在客戶與市場中感受與打聽，Product Owner 是團隊的眼睛與耳朵。

市場或是客戶如何反應我們上次推出的產品更新？他們喜歡什麼？不喜歡什麼？還是完全不感興趣？對手有沒有新的動作？有沒有新的對手加入戰局？市場對這些 player 的反應又是？

對手被用 150 個 mm 美金買掉了，這數字怎麼這麼少？我們以為同等公司的產值至少可以賣到 300 個 mm，這個變化打亂整個團隊的退場機制，怎麼回事？

2. Orient（分析）

分析 Observe 階段所接收到的訊息，消化所有環境變數的 delta（變化） ，更新你之前所認知到的現實。

從數字上面看來，上次的產品更新沒有騷到使用者的癢？是因為產品速度不夠快，還是這功能根本可以砍掉不做？新的對手一直在做我們之前沒做過的功能，他們的假設是什麼？有什麼樣的市場機會我們根本整個沒有看到？

對手賤價出售的意涵是不是因為我們所在的產業其實含金量不高？如果真的如此，我們有沒有籌碼切入那含金量更高的區塊呢？

3. Decide（決定）

你不是光領錢的顧問，你是大將，負責團隊的總成績，觀察與分析後，你必須要迅速地歸納所學，決定下一步採取的行動。

新對手到處找中小型企業合作，打的是鄉村包圍城市的算盤，我們的根基比較深，品牌名聲比較響亮，那就直接大張旗鼓地搶住那幾間最重要的大企業客戶，金角銀邊草肚皮（圍棋），我們先把所有重要的角加速拿到，趁對手還沒有站穩陣腳，在大企業客戶還競爭不過的時候，把這些灘頭堡搶下來。

4. Act（行動）

制定好策略後，就用 Get Shit Done 的精神戮力執行吧！衝到下一個檢核點。

5. Loop（讓一切循環）

跟 PDCA 一樣 OODA 是個循環，不是一個 Water fall （一條鞭法），雖然不像 Scrum Master 一樣，每個 Sprint 做一次循環（市場環境不太可能在 2 周之內改變一次），但每個 Sprint 就是 Product Owner 檢核產品 demo ，審視產品發展的優先權的時候。

他必須要好好試用現在完成的產品進度，跟 Scrum Master 坐下來討論下一個 Sprint 要完成的待辦事項，幫 Scrum Master 調整這些待辦事項的優先權，要補的，要拿掉的一次搞定，然後立刻把頭伸回到客戶與市場中觀察，分析。

幾個 Sprint 以後，如果感受到產品或是市場有異，產品有必要因而改變，他會招集團隊解釋分享他的觀察與他所做的決定，然後把這些決定，反應到接下來 Sprint 的待辦事項與其優先權中。

一切都在於比對手快的節奏

Scrum 的精神就在他一個 Sprint 接著下一個 Sprint 的節奏中，跟跳舞一樣，等你開始跟上節奏，在節奏中能夠放手表現的空間會越來越大，動作的品質也會越來越好。

OODA Loop 的創始人 John Boyd 相信，只要你的 OODA Loop 比對手快，你就有辦法在對手 OODA 循環完成之前切入他的 OODA Loop 中搞怪，攔截他的決策，防堵他的陣線，甚至擊落他，無獨有偶地，李小龍所創的截拳道中所謂的『截拳』理論也是一般。

只要你出招的速度比對手快（Scrum Master 所掌管的 PDCA），變招的速度對手跟不上（Product Owner 所控制的 OODA Loop），你就有辦法用 Scrum 手快打手慢，讓敵人看不到你的車尾燈。

訂閱 Winston Chen - 台灣工程師的矽谷故事