 |
| 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 手快打手慢，讓敵人看不到你的車尾燈。
——————————————————————————————————–
如果喜歡我的文章，非常歡迎你填入您的 Email 信箱，訂閱 Winston Chen，
或是直接關注我的 Facebook 粉絲團。
#mc_embed_signup{background:#fff; clear:left; font:14px Helvetica,Arial,sans-serif; } /* Add your own MailChimp form style overrides in your site stylesheet or in this style block. We recommend moving this block and the preceding CSS link to the HEAD of your HTML file. */
訂閱 Winston Chen – 台灣工程師的矽谷故事
也非常歡迎你來信跟我討論，謝謝。
太陽拳的萬人敵之術 