八月 2024 – 太陽拳的萬人敵之術

團隊的 agile，不該是五歲小孩的足球比賽

繼續紀錄跟朋友與讀者的討論。

有些遇到的團隊工作模式非常工整，sprint planning meeting ，每天的 standup ，與後來的 sprint review meeting 一個也沒有缺，但形式 100 分，卻一點也沒有輕快的感覺。說實在的，儒家文化就是這樣，注重禮數與形式，但是心法卻一點也不顧。

最重要的是，在『上線送貨』的過程中，非常在意一步到位，整個團隊會先互相協調，確定所有功能都準備好了，前端後端 DevOps 與 app 都完成了，才一起在同一天推出。

但是也因為在同一天內，要所有東西要同時上線，部門間又切得非常清楚，導致很多整合性的部份是上線後才發現問題，於是在上線後的狂暴時間， all-hands-on-deck，團隊進入英雄模式，到處滅火，直到問題穩定下來。

雖然因為 agile 的形式，每兩週要佈署一次，以 water fall 的時程來說算是非常短的。團隊卻因為每兩週都有這些上線抓馬（drama），壓力指數每兩週都會飆高一次，團隊成員也會有上線 PTSD（創傷後壓力症），心理狀態與家庭狀態受到影響。

五歲小孩的足球比賽

這種症頭，我在矽谷的朋友間叫它 “5 year old succor game（五歲小孩的足球比賽）" 。團隊以亞洲群體思維運作，要上一起上，要退一起退，然後所有小朋友同時間就會追著唯一的球滿場跑，團隊與隊友看起來都會很努力，但是成員們實在不知道為什麼這時候要在這裡，在這裡要做什麼？ XD

以下影片是個很好的例子，建議觀看。

球在哪裡，小朋友就群聚到哪裡，他們不知道自己跑到那邊要做什麼，他們都想踢球，但是都踢不到球，都想檔球，但都擋不到球，彼此之間完全沒有溝通與合作，不只是一盤散沙，還是一盤會相互妨礙的散沙。

之前網路上認為這影片是 junior vs senior 的比較，對我來說不然。這不是一個 junior vs senior 的比較，這是一個有沒有戰術的比較。

拆開團隊來上線，會比較有效

大家不用都在同一個時間，做同一件事情！在最好的情況下，團隊之間也不用等彼此，要把等待的時間縮到最小！

打個比方吧，如果你要上線的功能，有後端，有前端，有 iOS ，有 android ，還要管 DevOps 確定系統運行：

前端與 app 在做功能的時候，當然不用等後端的功能上線。
那些整合的 API 全都可以自己假設，喬好 spec 即可，然後誰也不用等誰。
做好之後，就各自放到 staging 上面，對內釋出 APK，或是 testFlight，讓商業團隊可以驗證與迭代。至關重要。
一旦後端的任何 API 上了 staging 或是 dev machine ，前端與 app 端就可以直接開始整合，然後 DevOps 就可以直接開始分析上線後對系統的影響。
如果是個新功能，或者說上線對 user 端不會有影響，反正後端 API 上線後也沒人用，乾脆就跟 DevOps 喬好，直接上 production 。如果把 production 搞掛了，也是 fail early ，不會全部人都 hang 在那邊等你修（見上圖）。跟前端，app 團隊完全沒有關係。
接下來，frontend 與 app 端，可以自己分別上線 production，分別測試，分別驗證。然後商業團隊要 demo 給客戶時也可以直接挑準備好的那個版本呈現即可。
如果還是希望所有功能一起釋出給用戶，只要做個 feature 的開關即可。所有前端的新功能，讀某個後端 API 的版本號啟用。在版號不到之前，功能只對商業團隊開放。

這樣每個團隊都各自拆開，各自驗證，各自上線，商業團隊很快就可以驗證到某個平台上的功能，很快就可以 demo 給客戶，很快就可以有結論與新的學習，如果需要，很快就可以叫停開發，或是 pivot 。

人少，團隊小，不用等，動作自然就快。

Agile 一直都是驗證商業假設的過程，不只是一個開發產品的過程。驗證假設的成本越小，所需時間越短，就可以越快學習，迭代下一輪的假設。

怎麼衡量每個迭代（iteration/sprint）？

這樣問題來了？不注重那些形式，你 agile 或是 sprint 的績效要如何衡量呢？不是要算 sprint 的 burn-down 嗎？

既然重要的是『結論』，你在 review meeting 時就應該直接衡量衡量結論的出產狀況，而不是坊間用的『分數』。如果你分數很高，團隊速度很快，但是沒有人知道我在哪裡，我要去哪裡，還有我為什麼要去那裡，這樣的速度（velocity）又有什麼作用呢？

更何況，用『分數』，很容易讓團隊針對分數去優化，然後糾結於分數，本末倒置。

回到這些外部指標的目的吧：假設 -> 結論。

我自己推薦的作法，是在 planning meeting 時把這個 sprint （或 iteration）的假設與結論都用文件寫出來，用 confluence，google docs，或是 txt 檔案都可以，紀錄好，review 的時候才能使用。

然後在 review meeting 時，跟團隊一起復盤（replay）整個 sprint 所經歷的事情：

這次團隊的假設與結論是什麼？
哪裡的進行順利？
有哪些意外發生？
團隊的學習是什麼？
有時候是目標定得不切實際？
有時候是團隊跑去做別的事情（比如說救火，或是家裡有事）？
有時候是快得到結論，就差那一點，為什麼？下次要如何處理？
有時候是得到結論了，但是過程中，團隊有沒有學習到別的可能性？

這些問題都問了，你應該已經很明白團隊這次 sprint （或 iteration）的表現如何了，那些分數，對這個階段的團隊，應該就只是參考，不是絕對的指標。

用分數衡量，而不在意『結論』，在英文中有個說法，叫做『tail wagging the dog』，尾巴搖狗，而不是狗搖尾巴，意指團隊糾結在某些不太重要的地方。

看到這裡，如果你有共鳴，請跟我討論，或幫我轉發朋友圈八 🙂
Email 訂閱： https://forms.gle/2n7nBjbGw3SRNvim8
加入 Facebook 粉絲團：https://www.facebook.com/winston.chen.sv/

water fall 是死星，而 agile 是 swarm 攻擊

紀錄一下與身邊朋友與讀者看完上兩篇後的討論：
唯快不破不是重點！Agile 只是想『輕量有效』地打死兩位
 註死不適合 Agile 的團隊

感覺還是快不起來？

工作還是一樣，如果人手沒有變多，用什麼方法論還不都一樣？

沒錯，如果定義的工作的方法不改變，那麼我不認為差別會很大。這麼說吧，如果你的終端產品是星際大戰中的死星(death star)，然後從 0 出發，也可以使用傳統的 water fall 方式開發，一路穩穩的完成就好了。何必自討苦吃，硬要聽信坊間謠言，搞什麼 agile 加速？

沒有必要！

我認為 agile 的工作定義是很不一樣的，比起 death star 這種武器，他更像是最近 Star Trek Beyond 中，不斷衝向企業號的的蜂群攻擊(swarm attack)！

不熟蜂群攻擊的朋友，可以參考以下影片：

在這個影片中，蜂群攻擊中每一之『蜂』，都可以視為一個執行成功的 MVP 。儘管單位效果不顯著，卻可以實質影響單位戰局。

當很多有效的 MVP 匯聚成一個蜂群，就可以影響整個戰場的大局，量變導致質變。我們沒有辦法確定是哪隻 MVP 開始，戰局開始對團隊有利，但是這種有效，低成本，密集而匯沙成塔的概念，是我領悟到的 agile 。

死星呢？要全部蓋完才有效果，少一個螺絲，一行 code，都有可能沒有辦法運作。而且死星的開發週期又臭又長，從 Jyn Erso 小時候，爸爸被抓走開始，蓋到他都已經可以加入反叛軍時才完成 XD。這時間帝國早已經所向披靡，沒有什麼能成氣候的阻礙。死星上線後，儘管戰力完全碾壓，卻也沒有讓反叛軍的反抗意志消失，從商業的角度來說，除了增加 GDP 與團隊開支，好大喜功，我實在不知道這個專案到底有什麼必要性！

迭代是什麼？怎麼讓迭代變快？

agile 『迭代』的目的，是要用很少的資源與時間，創造出一隻有效的『蜂』，因此最好的節奏，是每次迭代都可以創造出一隻改進後的『蜂』。

如果你想要理解成，每次 sprint 結束後，就有一隻熱騰騰的，新的，能夠上戰場的『蜂』也可以。或者是，想像成下圖 1 的滑板。

理想的狀況是，早上討論市場需求，中午工作，下午上線一隻新的蜂，或者是把滑板改造成 2 的滑板車。

從滑板車到 3 的腳踏車，或到 4 的機車，甚至之後 5 的汽車當然比較困難，沒有辦法在一個 sprint 之內解決，但是你從 1 與 2 中已經累積到了學習與客戶反饋，你不用等到把腳踏車造完才上戰場找客戶，你甚至可以直接在滑板車上面安裝座墊，這個座墊，就是一隻『蜂』，也是可以在一個 sprint 之內完成的規模。

座墊完成後，如果速度是個問題，根本不用往 3 腳踏車的方向去，直接在有座椅的滑板車上面安裝馬達與電動輪即可。如果是穩定性的問題，你就要考慮換大一點的輪子，不用很急躁的立刻衝到『腳踏車』這個結論。

一切以市場/戰場的直接反饋為依歸，要以『蜂』的單位思考。因為以『蜂』的單位交貨，速度就會很快。

蜂的極限

當然，這種漸進式的發展方式有其侷限性，之前在唯快不破這篇就有提過：它很難有突破性。

以上圖比方吧，從 4 機車跑到 5 的汽車，在工程團隊來說，是跟根本上的不同，根本是完全不一樣的產品。這種突破性的跳躍，是產品團隊捨棄現有的假設，回到問題或是市場本身重新思考的結果。在機車或是滑板車的根基上，沒有辦法推出汽車這種解法或是產品。

但是汽車的 trek 也不會直接衝到去定義汽車，那是『死星』的作法。蜂群的作法，可能會從這種東西開始：

這些看起來弱弱的產品，會是『汽車』版本的某個迭代，某一個『蜂』。

water fall 的 planing
然後用 agile 的執行方式是沒用的！

要用 agile ，就要從頭到尾都是 agile 。不要傻傻的跟大家一起用 water fall 的心態規劃一個龐大的系統，計畫每個運作的細節後，小心的切成每個小組要完成的 mile stone ，最後在要讓各個團隊用 agile 的方式執行 XD

最後，管理層與 PM 再用力『管理』每個團隊，加班加點，務必讓團隊份內工作在『時間內』完成，對上其他團隊的等待時間，以確定全局的時程沒有被拖到？

這還是叫做 water fall ，不是 agile 好杯 XD

正因為不可以一開始就規劃死星，在 lean startup 的 MVP 概念中才會有這張圖：

上面那個被打 X 的部份，就是事事規劃，造出死星的邏輯。

agile 的作法是，規劃一隻可以直接上戰場的『蜂』，或是上列 1 的滑板，然後就直接上戰場了！

跟蜂群攻擊一樣，這隻蜂可能會被打爛，可能會消失得無影無蹤，可能飛回來炸到自己，可能衝出去撞到友軍，但是只要團隊能夠輕量有效地改良出下一隻上戰場的『蜂』，這個循環就可以夠短，就可以大量不斷的讓更有效的『蜂』上戰場衝鋒，直到贏下戰局。

不然簡單一點，就直接用傳統的 water fall ，穩扎穩打的把大專案做出來即可，不用搞工玩什麼 agile 。

註死不適合 Agile 的團隊

圖片來源，通靈少女：HBO Asia

「未註生，先註死，生死有命，天有定數。」　- 通靈少女

小學時，有一段時間，下課後，回家前，會在媽媽辦公室旁『全臺首邑縣城隍廟』榕樹下消磨時間，那時候很怕入門後兩尊大大的，表情兇惡的黑白無常，殿中「爾來了麼」這個匾額，讓當時初知文言文的我怵目驚心。那時候還是會逼自己好好看著黑白無常兩位的臉，好好的打招呼，不要那麼沒有禮貌。

人生在過去這幾年，有小孩後急遽加速，每次回台南，能繞到城隍廟時我一定會走進去參拜，也還是會好好地看著黑白無常兩位的臉，跟兩位好好打招呼。不過此時的情感就大多不是恐懼了，是種緬懷過去的熟悉感，看到「爾來了麼」時，也有種回家了的感覺。很特別。

在台灣傳統宗教習俗中，生與死，是紀錄在生死簿上面的，是老早之前就決定好的了。我覺得 agile 團隊也是一樣的，看看團隊的組成與權力結構，你很容易就可以找出一些『註死』的徵兆，而且你會在很多不同團隊中看到同樣的影子。以下列舉最近看到過的幾個：

一，神諭與隕石團隊

很多美國與台灣很會募資的 startup 創辦人都是這種，他們通常有滿滿的自信，官大學問大，對自己當下相信的東西死心塌地，但是他們的『當下』又來得快，去得快，反映在團隊中的效果，就會有以下幾項：

團隊一定要 100% 照著他的方向與方式前進，急急如律令。
團隊成員常常沒有辦法討論或是辯論，或是這些討論/辯論，只會產生情緒，不會有效果。
心血來潮，換了方向後，會對團隊當下前進的方向與方式完全不滿意，推翻過去的自己時，也會遷怒團隊，認為團隊成員都不 work（儘管方向與方法都是他說的 XD）
團隊立刻掉頭往新的方向前進，時程因為 context switching 而被瘋狂壓縮，於是團隊每天都在加班，每天都在救火。這種窮忙的感覺，被團隊老大稱之為『快』，『pivot』，或是『agile』，其實在對手或是外人看起來，不過就是在折返跑而已，沒有太多效果。
因為 context switching ，煉成陣從來沒有好好完成，效果當然不顯著，於是老闆又回到上列的地 2 點，繼續推進團隊，無限循環，無間地獄。

前些日子，日本的傳出來的『隕石式開發』講得就是一樣的事情，因為有『神』，然後就有了『神諭』，所以團隊成員無時不刻都得請神『降駕』，神會覺得很累，覺得團隊成員能力不足，整個團隊只有他 work，以至於事事都要他處理 …

聽起來有沒有很熟悉？

Agile 的精神是透過『設計實驗』與『實驗』學習，這種官大學問大的隕石式開發方式，跟 Agile 是有根本上的牴觸的。想在這種團隊跑 Agile ，就是註死。

要撥亂反正，團隊要時時都屬於『退駕』的狀態，好好的『設計實驗』與『實驗』，然後讓結果說話。

二，共識決團隊

如果說『隕石團隊』跟 agile 不合是因為有不可撼動的神，共識決團隊的問題，則在於團隊欠缺有效的方向。

說到『共識決』，最有名的例子是歐盟。雖然當初是故意設計的，但是如果每件事情都要有全體共識才能確定執行，每個成員之間細微的差異，或是情感因素，都會造成團隊完全停滯空轉，沒有辦法往前。

這種情況下，團隊中就會有多個山頭，誰也不服誰，一致對外的團隊，變成往內互打，內耗冠軍。在民主政治中，這種機制是一開始就這樣設計的，但是在 agile 團隊中，這種連方向都搞不清楚的狀態，哪裡都去不了，更遑論 agile 了。

如果讓『神』指明方向不行，讓平等的團隊成員投票也不行，那 agile 團隊到底是要怎麼樣？

答案就在前一篇『唯快不破不是重點！Agile 只是想『輕量有效』地打死兩位』中。agile 本身是在無限的低成本『實做』與『實驗』中循環。

團隊建立『假說』，用低成本的方式『實做』，『實驗』，有結論後，再做下一輪的實驗。低成本就註定週期短，一直都會有新的實驗結論回到團隊系統中，看起來就會很快。是那種不費力的快，是那種不加班的快。

你不用找神，也不用找議事專家，你所需要的，是一個會設計實驗，並實驗設計的團隊而已。

三，沒有辦法掌控自己命運的團隊

除了低成本的實驗精神以外，還有一件事情對 agile 團隊非常致命，那就是『等待』。等待管理層同意 (management buy in)，等待供應商資源，等待外部團隊交貨，等待設備移交，等待會計部門核准資金 … 等待。

這些等待，不只會讓時程往後拖延，也會讓團隊的士氣低或，火都花去！所以如果團隊的工作從根本上就沒有辦法自己掌握，需要大量的外部合作，你可能要好好考慮要如何重新設計部門的權責。如果沒有辦法，或許一開始就不要用 agile 的方法論！

我看過的，執行順暢的 agile 團隊，是能夠逐步提昇在整個公司或是組織中的影響力，用同樣的節奏賦能 empower（empower）其他團隊，讓其他團隊也輕鬆起來。如果團隊一開始就因為外部因素綁手綁腳，拖泥帶水，那就得從團隊設計上來做實驗，不要想要從現有的團隊中 agile 起來，註死，沒有辦法。

如果你喜歡我的文章，歡迎
Email 訂閱： https://forms.gle/2n7nBjbGw3SRNvim8
加入 Facebook 粉絲團：https://www.facebook.com/winston.chen.sv/

唯快不破不是重點！Agile 只是想『輕量有效』地打死兩位

我小時候也以為 agile 就是要『快』，還讀了不少書，之前還寫了一些 scrum 的文章。是的，如果你跑 agile 但是快不起來，或是一點也沒有快的感覺，那一定不是 agile XD

但是參與與帶領過一些團隊以後，我越來越覺得，『快』這件事情，是 agile 的結果，或者是根本就是一個副作用，但卻不是 agile 本身的目的。

用任何方法論的目的，應該只有一個，那就是：把事情做好，把錢賺到，然後回家睡覺。所以你方法論的目的本身，應該是『實做成本低』並且『很有效』，然後這兩個加在一起的副作用，就是看起來很快。

因此，比起常常受到傳頌的：『天下武功，無堅不摧，唯快不破』，火雲邪神的以下這句，才是所有 agile 的目的：『我只是想打死兩位，或者被兩位打死』

『想打死兩位』才是他練武的目的，他要做到『很有效』並且『成本低』，『快』只是他看起來的樣子罷了。

順序很重要，因為這樣就代表，團隊不應該一味的追求『快』，而是一開始就應該著眼於『輕量地有效』。

聽起來，有沒有很像是 lead startup？阿不都是借用 80/90 年代日本工廠發展出來的那些工業工程上的作業研究而已？

輕量地有效，要如何達成呢？

上個禮拜有機會從 FB 某個軟工社群中看到看到這個演講，他又聊得更深刻一點。我稍微節錄，並討論一下：

Agile 不是理論，而是實做本身

agile 是學習，人類只有在實做時才會學習，所以團隊 agile 的重點在不同的團隊參數調整與嘗試。思想上的學習，沒有實做，不算是學習。

拘泥於 scrum 或是其他 agile 格式或是流程沒用，實驗比較重要

以此說來，用固定格式與固定方法跑 agile ，然後形式重於實質的團隊，就是有問題的。反之，如果形式很混亂，但是團隊的學習速度卻很快，反饋到產品的速度也很快，那麼格式就不那麼重要。團隊要在意的只有三個，1. 思考學習，2. 實做，3. 回到 1。

快在團隊的 lead time 才有意義

速度的定義只有一個：從 idea 階段，直到產品/功能上線的時間。因為只有整個跑完，才會對全局產生影響。所謂 MVP 那種東西，其實就像是鍊成陣，少一劃都不算完成，但是完成後，就可以立刻發生效果，對周遭的環境（公司，團隊，或是市場）產生影響。

不要只做『線性』的實驗，要大量地重置

『重置』要做很多次！如果說實驗與學習是 agile 的核心，那就不應該拘泥於線性的成功，『重置』也是一個很重要的部份。所謂的『重置』，就是團隊必須忘記過去的解法，重新回到『問題』本身，重新用不同的工具與想法解問題。

線性的成功會把團隊困在區域的最佳解中，『重置』與不同的嘗試方式，會讓團隊更逼近全域最佳解。

這點很可以解釋為什麼大公司資源多，在特定領域，有時候還是競爭不過 startups 。大公司對很多領域有既有的投入，解決問題的時候，很自然地會想要站在過去的肩膀上，大多不會選擇砍掉重練，這樣生出來的解法，大多是線性的改善，很難有突破性的創新。

相反的，startup 本身沒有包袱，會用當下新的工具與方法看待問題本身，這樣的條件，會接近很多之前沒有機會的突破口。

身為 Agile 的團隊，既然實驗與學習是第一要務，就要想辦法實做出突破式創新的環境，有意識把之前累積的付之一炬，重新出發是一個有趣的議題。

話是這樣說，但是最後這一點我還沒什麼實戰心得，我會去想想，然後多實做幾次，有心得再跟大家分享。