如果世世代代都住在一個被大洋環繞的小島上的村落，靠著採集和捕魚為生，村子中最先進的科技是獨木舟，當有天突然看到飛機飛過頭頂時，心裏的OS是什麼呢？
在二次世界大戰時，美日兩國為了爭奪太平洋的制海權和制空權，紛紛在汪汪大洋中、既偏遠又與世隔絕的島嶼駐軍。當軍隊開到時，島上的村民眼看著海上的超級大箱子（軍艦）靠岸，大鳥（飛機）從從頭頂飛嘯而過，還有神仙（士兵）從大箱子和大鳥走出來，下巴都掉到合不起來。
如果換成我的話一定覺得神仙降臨來處罰世人，世界末日要到了！幸好這群神仙不但沒有處罰世人，還賞了不少寶物給村民，如生病時吃了就痊癒的仙丹、會變出食物的盒子等等。當世界大戰打的如火如荼時，這是村民世代以來過的最好的日子，根本就是身在天堂啊。
可惜好景不長，幾年後世界大戰結束了，這些島嶼的戰略價值消失，軍隊慢慢撤出。村民眼看著神仙們走光，剩下來的寶物也越來越少，心中越來越著急，怎麼辦呢？這時就有聰明的村民說了，一定是神仙覺得我們不虔誠，只要我們表現出敬意，神仙就會回來賞賜我們寶物的！
數十年後，當人類學家到達這島嶼上，發現村民用樹木打造出飛機、刻出步槍、在身上畫USA，模仿當時駐軍做的事情，還在期待有一天神仙回來帶給他們寶物。人類學家把認為模仿表像（木頭飛機）就能帶來實質利益（藥品食物）的行為稱作貨物崇拜。
聽起來很天真、感覺只會發生在荒島的貨物崇拜行為，其實經常發生在身邊的對話。
基本句型是：『只要』做一個行為，『就會』得到你要的結果。企業組織內這種句型不少，根本就是萬用句型。
「要怎麼樣賺錢？」
『只要毛利抓3%，我們就會比紅海更紅哦。』
「要怎麼樣創新？」
『只要讓每個人有20% Time，我們就可以跟孤狗一樣金頭腦哦。』
「要怎麼樣讓大家表現更好？」
『只要有績效考核加上KPI，我們就會比政府更有效率哦。』
「要怎麼樣更了解市場？」
『只要用Big Data，我們就可以做出外星科技哦。』
「要怎麼樣更快做出產品？」
『只要跑敏捷，我們就會比非死不可死更快哦。』
遇到這種句型，可以先檢視一下因果關係是否正確，如毛利3%是結果、還是原因？如果可以賺4%不賺嗎？
就算有因果關係，也可能過度簡化，把複雜的動態系統關係簡化成線性關係。孤狗創新除了20% Time，還可能有辦公室設計、特地挑選有創意的人、升遷方式等等。
回到跑敏捷的團隊，相信也多少聽過類似的話。
「要怎麼樣做好產品？」
『只要我們用使用者故事（User Story）寫需求，顧客就會愛死我們的產品哦。』
「要怎麼樣進步？」
『只要我們每個禮拜都開自省會議Retrospective，我們就會天天向上哦。』
跑敏捷最重要是自我察覺，要怎麼知道有沒有貨物崇拜作祟呢？
Stefan Wolpers有整理一份敏捷貨物崇拜清單（The Cargo Cult Agile Checklist），經作者同意後翻譯成中文如下，一起看看我們飛機拜的多虔誠 XD。
敏捷貨物崇拜清單（簡稱拜飛機清單）
我們一起來看看一些組織內常見的拜飛機儀式。本清單假設組織使用Scrum，但其他的敏捷方法一般也是適用。如果符合組織的情況，請回答“是”。（備註：組織越大可能越不適用本清單。）
- 沒有溝通（產品的）願景和策略
- 產品藍圖和發佈日期在一年前就由CTO規劃好了
- 組織內沒有人跟顧客對談
- CTO和利害關係人堅持所有的改動都要經由他們批准
- 因為保密資安等理由，禁止使用實體的看板或告示
- 利害關係人直接跟CTO對談，跳過Product Owner
- 由利害關係人來決定交付產品增量，而不是Product Owner
- 專案/產品只有在完成時才交付，而不是增量式的交付
- 避免利害關係人直接跟開發團隊對談
- Product Backlog是由一個產品委員會決定的
- 就算對功能的價值有所懷疑，但還是硬上了（為了年終獎金…）
- 業務為了成交，答應客戶增加目前不存在的功能，而Product Owner不知情
- 就算是不重要的問題，也有固定的進度表和期限
- 負責產品管理的角色沒有取得商業智能（BI）資訊的權限，沒有充足的資訊和數據幫助決定
- 利害關係人使用需求文件來和產品與工程部門溝通
- Product Owner大部分的時間都在撰寫和管理使用者故事（User Stories）
- 在Sprint開始後不久Sprint Backlog就變了
- 專門成立一個開發團隊來修Bugs和處理小的需求
- 利害關係人沒有參加過Scrum活動（例如Sprint Planning和Sprint Review）
- 主要是用『速率（Velocity）符合當初的承諾』來當指標評估Scrum是否成功
- 開發人員沒有參與創造使用者故事
- 同時處理的專案數量和工作會改變開發團隊的人數跟組成方式
- 在Daily Stand up中團隊成員對ScrumMaster報告
- 定期舉行自省會議（Retrospectives），但沒有改變隨之發生
- 開發團隊並不是跨功能（Cross Functional），而要靠其他團隊或部門才能完成工作
組織敏捷貨物崇拜虔誠度測試（簡稱拜飛機測試）
這是很有趣的活動，試試把清單列印出來，花個五分鐘讓團隊中的每個人作答，依照結果分析和評估一下目前的狀況。
平均0 – 2個是：太神奇了，可以跟我（作者）聯絡你們是怎麼辦到的嗎？
平均3 – 5個是：事情看起來是在對的方向發展
平均6 – 8個是：有可改善的空間，蠻多的
平均9 – 14個是：如果你們不是剛剛開始跑敏捷，也許可以考慮換個實行方式
平均15 – 20個是：試試重新開始導入敏捷吧，目前的安排在你們組織沒有用
平均21 – 25個是：要嘛是你們還沒開始跑敏捷，要嘛是在傳統的專案方式外包裝了敏捷的糖衣，良心建議：這沒有用的。
（譯者注：分數是有趣，而交流一下每個人那些問題回答“是”，有那些相同，那些不同，收穫會更大）
結論
敏捷沒有教戰手冊是套入後就可自動在你的組織運行順利的，你必須要找出屬於自己的敏捷方式，先嘗試用其他組織成功的方法。
如果這方法對你也有用，那太好了，就繼續用吧。如果沒用，就試試其他方法。更改甚至是取消標準的敏捷儀式是絕對沒問題的，只要能幫助你判斷在你的組織中什麼事情是有用的。如果你看到其他合適的實踐方式，也別遲疑，就依照組織的情況修改試用吧。
作者：Yves Lin 別名小伊
文章出處 : 敏捷進化趣 Agile FunEvo
原文連結 :今天拜飛機了沒？ – 談敏捷開發中的貨物崇拜
圖片出處：http://gizmodo.com/what-burning-man-has-in-common-with-a-south-pacific-car-1207361630
本站所有文章未經事先書面授權，請勿任意利用、引用、轉載。
