教授Scrum敏捷方法課程多年以來，不論是在公開班上，或是在企業內部裡，不論是被運用在專案管理上，或是被應用在整體組織的改造上，我發現，不少團隊或組織在施行敏捷方法的時候，經常有意或無意地把一些敏捷方法的重要設計給省略掉，誤認為這樣就能省掉調整組織規章、組織結構和人員心態等的大量心力，仍可輕鬆獲致敏捷方法宣稱的巨大成效。
組織營運或專案管理出了問題，企業對外找專業講師或顧問來協助，是直接、有效且客觀的方法，本無可厚非，不過我得說，如同人生了病會去找醫生一樣，病人如果不照醫生指示去定期服藥治標，也不願意花力氣去運動調整體質來治本，那麼，病好不了，無法根治，也就怪不得醫生和處方了，對吧？
因此，組織若是自認已大力支持敏捷方法（努力看醫生），可是卻依舊成效不彰（病情依舊），很可能就是出現了類似上方的情境。
以下是一些我這些年來常常聽到的症狀，也許您也可以自我診斷一下，看看您的組織或團隊中了多少招。中招愈多，代表您的組織或團隊，偏離敏捷方法的精神和設計愈遠，也就是說，在我看來，那是「偽敏捷」！
1. 當開發團隊對需求有疑惑時，卻經常找不到產品負責人（Product Owner）來澄清解惑。
2. 產品負責人常無法明確回答開發團隊的疑惑，事事得向客戶再確認。
3. 產品負責人優柔寡斷，根本無法即時迅速協助團隊排除需求相關障礙。
4. 產品負責人的權限不足，事事得上報，決策緩不濟急，團隊開發速度根本就快不起來。
5. 老闆和客戶，甚至是產品負責人自己，不時變更已排進衝刺的工作，導致衝刺的計畫和執行混亂不堪。
6. 敏捷大師（Scrum Master）只能幫忙訂雞排、買飲料、跑行政，不僅無法主動探測出開發團隊達成目標的潛在障礙，更無法協助開發團隊及時排除已知的障礙。
7. 敏捷大師根本就沒有正確掌握敏捷方法的心法和精神，無法因時制宜，因應組織文化與產品特性，協助團隊恰當客製化敏捷方法。
8. 開發團隊（Development Team）成員座位分散又很遠，根本無法隨時面對面溝通。
9. 開發團隊成員得同時負責好幾個專案，開會常常人在心不在，時程也常常因此守不住。
10. 專案產品主功能得靠其他開發團隊或外包商才能完成，根本無法精確掌握對方的進度和品質狀況。
11. 開發團隊成員的分工和責任非常明確清楚，根本沒有互相協助的需要。
12. 開發團隊成員還是用過去的慣性在做事，根本沒有嘗試想辦法去改變工法或工具，讓工作能被拆解細分到一個衝刺之內就可以被完成，讓客戶可以去試用。
13. 一些重要的工作，只有特定的開發團隊成員會做，沒人能備援或幫上他們的忙。
14. 每日立會（Daily Scrum）根本沒有每天開。
15. 每日立會經常有人遲到或根本就不到。
16. 每日立會多半在報流水帳，一點幫助也沒有。
17. 每日立會經常開很久，最後大家都不想開。
18. 每日立會上，開發團隊成員只對敏捷大師做報告，一點也不關心其他夥伴的狀況，好像進度只是敏捷大師的責任。
19. 衝刺待辦清單（Sprint Backlog）內的事項，做不完會被老闆K，大家只好犧牲品質來假裝有做完。
20. 衝刺（Sprint）週期時常時短，做不完就延長，老闆或客戶要求就縮短。
21. 衝刺的最小可行產品/成果（MVP）完成不了，就取消演示與審查會議（Demo and Review Meeting），團隊一點壓力也沒有。
22. 回顧與改進會議（Retrospective Meeting）沒有每個衝刺都召開，就算有召開，也盡是些場面話，很少形成可以具體執行的改進方案。
23. 客戶對衝刺的最小可行產品/成果不是沒在試用，就是草草給些幫助不大的官僚式回饋。
24. 客戶表面上同意敏捷團隊使用敏捷方法做專案，可是範疇（Scope）卻仍和以前一樣全部得做完，否則就不驗收，還是一點彈性也沒有。
25. 團隊總是需要花很長的時間把產品待辦清單（Product Backlog）內的每個待辦事項詳細設計，才肯給出專案的總工時估算，開始衝刺，害怕一旦給出時程，就會被老闆或客戶咬住不放。
26. 敏捷團隊成員，沒人敢比老闆先下班，擔心考績受影響。
27. 使用敏捷方法做專案之後，大家班還是沒加得比較少，甚至比以前還要累。
28. 開發團隊成員，三不五時就會被其老闆叫走，導致大家很難培養出革命情感。
29. 其他支援性功能部門對於敏捷式團隊所需要的支援，還是按步就班慢慢來，根本就沒有比較敏捷。
30. 老闆或客戶經常繞過產品負責人，直接找開發團隊給需求，導致產品負責人常常狀況外。
當然了，偽敏捷的症狀絕對不會是只有這些，您還看到了哪些偽敏捷的症狀呢？歡迎各位留言分享。
本站所有文章未經事先書面授權，請勿任意利用、引用、轉載。
