今天拜飛機了沒？ – 談敏捷開發中的貨物崇拜

如果世世代代都住在一個被大洋環繞的小島上的村落，靠著採集和捕魚為生，村子中最先進的科技是獨木舟，當有天突然看到飛機飛過頭頂時，心裏的OS是什麼呢？

在二次世界大戰時，美日兩國為了爭奪太平洋的制海權和制空權，紛紛在汪汪大洋中、既偏遠又與世隔絕的島嶼駐軍。當軍隊開到時，島上的村民眼看著海上的超級大箱子（軍艦）靠岸，大鳥（飛機）從從頭頂飛嘯而過，還有神仙（士兵）從大箱子和大鳥走出來，下巴都掉到合不起來。

如果換成我的話一定覺得神仙降臨來處罰世人，世界末日要到了！幸好這群神仙不但沒有處罰世人，還賞了不少寶物給村民，如生病時吃了就痊癒的仙丹、會變出食物的盒子等等。當世界大戰打的如火如荼時，這是村民世代以來過的最好的日子，根本就是身在天堂啊。

可惜好景不長，幾年後世界大戰結束了，這些島嶼的戰略價值消失，軍隊慢慢撤出。村民眼看著神仙們走光，剩下來的寶物也越來越少，心中越來越著急，怎麼辦呢？這時就有聰明的村民說了，一定是神仙覺得我們不虔誠，只要我們表現出敬意，神仙就會回來賞賜我們寶物的！

數十年後，當人類學家到達這島嶼上，發現村民用樹木打造出飛機、刻出步槍、在身上畫USA，模仿當時駐軍做的事情，還在期待有一天神仙回來帶給他們寶物。人類學家把認為模仿表像（木頭飛機）就能帶來實質利益（藥品食物）的行為稱作貨物崇拜。

---

聽起來很天真、感覺只會發生在荒島的貨物崇拜行為，其實經常發生在身邊的對話。

基本句型是：『只要』做一個行為，『就會』得到你要的結果。企業組織內這種句型不少，根本就是萬用句型。

「要怎麼樣賺錢？」
『只要毛利抓3%，我們就會比紅海更紅哦。』

「要怎麼樣創新？」
『只要讓每個人有20% Time，我們就可以跟孤狗一樣金頭腦哦。』

「要怎麼樣讓大家表現更好？」
『只要有績效考核加上KPI，我們就會比政府更有效率哦。』

「要怎麼樣更了解市場？」
『只要用Big Data，我們就可以做出外星科技哦。』

「要怎麼樣更快做出產品？」
『只要跑敏捷和Scrum，我們就會比非死不可死更快哦。』

遇到這種句型，可以先檢視一下因果關係是否正確，如毛利3%是結果、還是原因？如果可以賺4%不賺嗎？

就算有因果關係，也可能過度簡化，把複雜的動態系統關係簡化成線性關係。孤狗創新除了20% Time，還可能有辦公室設計、特地挑選有創意的人、升遷方式等等。

回到跑敏捷的團隊，相信也多少聽過類似的話。

「要怎麼樣做好產品？」
『只要我們用使用者故事（User Story）寫需求，顧客就會愛死我們的產品哦。』

「要怎麼樣進步？」
『只要我們每個禮拜都開自省會議Retrospective，我們就會天天向上哦。』

---

跑敏捷 Agile 最重要是自我察覺，要怎麼知道有沒有貨物崇拜作祟呢？

Stefan Wolpers 有整理一份敏捷貨物崇拜清單（The Cargo Cult Agile Checklist），經作者同意後翻譯成中文如下，一起看看我們飛機拜的多虔誠 XD。

敏捷貨物崇拜清單（簡稱拜飛機清單）

我們一起來看看一些組織內常見的拜飛機儀式。本清單假設組織使用Scrum，但其他的敏捷方法一般也是適用。如果符合組織的情況，請回答“是”。（備註：組織越大可能越不適用本清單。）

1. 沒有溝通（產品的）願景和策略
2. 產品藍圖和發佈日期在一年前就由CTO規劃好了
3. 組織內沒有人跟顧客對談
4. CTO和利害關係人堅持所有的改動都要經由他們批准
5. 因為保密資安等理由，禁止使用實體的看板或告示
6. 利害關係人直接跟CTO對談，跳過Product Owner
7. 由利害關係人來決定交付產品增量，而不是Product Owner
8. 專案/產品只有在完成時才交付，而不是增量式的交付
9. 避免利害關係人直接跟開發團隊對談
10. Product Backlog是由一個產品委員會決定的
11. 就算對功能的價值有所懷疑，但還是硬上了（為了年終獎金…）
12. 業務為了成交，答應客戶增加目前不存在的功能，而Product Owner不知情
13. 就算是不重要的問題，也有固定的進度表和期限
14. 負責產品管理的角色沒有取得商業智能（BI）資訊的權限，沒有充足的資訊和數據幫助決定
15. 利害關係人使用需求文件來和產品與工程部門溝通
16. Product Owner大部分的時間都在撰寫和管理使用者故事（User Stories）
17. 在Sprint開始後不久Sprint Backlog就變了
18. 專門成立一個開發團隊來修Bugs和處理小的需求
19. 利害關係人沒有參加過Scrum活動（例如Sprint Planning和Sprint Review）
20. 主要是用『速率（Velocity）符合當初的承諾』來當指標評估Scrum是否成功
21. 開發人員沒有參與創造使用者故事
22. 同時處理的專案數量和工作會改變開發團隊的人數跟組成方式
23. 在Daily Stand up中團隊成員對ScrumMaster報告
24. 定期舉行自省會議（Retrospectives），但沒有改變隨之發生
25. 開發團隊並不是跨功能（Cross Functional），而要靠其他團隊或部門才能完成工作

組織敏捷貨物崇拜虔誠度測試（簡稱拜飛機測試）

這是很有趣的活動，試試把清單列印出來，花個五分鐘讓團隊中的每個人作答，依照結果分析和評估一下目前的狀況。

平均0 – 2個是：太神奇了，可以跟我（作者）聯絡你們是怎麼辦到的嗎？
平均3 – 5個是：事情看起來是在對的方向發展
平均6 – 8個是：有可改善的空間，蠻多的
平均9 – 14個是：如果你們不是剛剛開始跑敏捷，也許可以考慮換個實行方式
平均15 – 20個是：試試重新開始導入敏捷吧，目前的安排在你們組織沒有用
平均21 – 25個是：要嘛是你們還沒開始跑敏捷，要嘛是在傳統的專案方式外包裝了敏捷的糖衣，良心建議：這沒有用的。

（譯者注：分數是有趣，而交流一下每個人那些問題回答“是”，有那些相同，那些不同，收穫會更大）

結論

敏捷沒有教戰手冊是套入後就可自動在你的組織運行順利的，你必須要找出屬於自己的敏捷方式，先嘗試用其他組織成功的方法。

如果這方法對你也有用，那太好了，就繼續用吧。如果沒用，就試試其他方法。更改甚至是取消標準的敏捷儀式是絕對沒問題的，只要能幫助你判斷在你的組織中什麼事情是有用的。如果你看到其他合適的實踐方式，也別遲疑，就依照組織的情況修改試用吧。

 

圖片來源：http://gizmodo.com/what-burning-man-has-in-common-with-a-south-pacific-car-1207361630