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

評論
評論

本文作者 Yves Lin,現任職於新加坡商鈦坦科技。 喜歡並相信敏捷,期許能帶入一些不同的思維,能讓華語圈不只軟體產業,都可以更敏捷。

原文刊載於 敏捷進化趣 Agile FunEvo,Inside 獲授權轉載。

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

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

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

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

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

cargo cult
(Photo Credit:  Bexx Brown-Spinelli

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

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

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

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

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

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

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

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

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

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

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

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

checklist
(Photo Credit:  Crispy)

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

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

敏捷貨物崇拜清單(簡稱拜飛機清單)

我們一起來看看一些組織內常見的拜飛機儀式。本清單假設組織使用  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 個是:要嘛是你們還沒開始跑敏捷,要嘛是在傳統的專案方式外包裝了敏捷的糖衣,良心建議:這沒有用的。

(譯者注:分數是有趣,而交流一下每個人那些問題回答「是」,有那些相同,那些不同,收穫會更大)

結論

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

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

歡迎加入「Inside」Line 官方帳號,關注最新創業、科技、網路、工作訊息

好友人數

評論