文／葛仲安, PMP, PMI-ACP, CSM, CSPO
敏捷Agile在業界已經成為當紅炸子雞。不論是教育訓練機構，或是服務諮詢顧問，大家都爭先恐後掛上敏捷專家的名牌。同時，敏捷也翻過了「軟體工程ONLY」的城牆，大幅擴展到各個不同的產業別：金融業、服務業、教育界、製造業、研發界等。嘗試敏捷導入轉型的組織，也不再侷限於小型團隊；舉凡公家機關、私人企業與各個中大型機構，也都一窩蜂的跟著潮流「上車」。此外，各種人才的相關認證課程與機制也大幅佔據版面，不同的認證機構，有著相異的認證機制與條件，開始發送認證證書。
看起來，Agile is everywhere —到處是敏捷。
事實上真的是如此嗎？也許口號喊地震天價響，敏捷二字也充斥於所有的對話文字中，然而，大眾對於敏捷概念的錯誤認知，其實比比皆是。筆者不會、不能、也不敢說自己能夠把所有的迷思都能夠表列出來在此；但是，接下來要談論的，就是最常見的幾項敏捷錯誤認知。
迷思1
敏捷就是快速
Agile是Agility這個字眼的形容詞，2001年時被17位軟工前輩選為代表其共同價值思想的字眼；形容詞做為專用名詞使用。這個字的意思不是Fast，也不是Speed；真正的涵義在於是否能夠保持自我身段的靈活敏捷性。而不被繁文縟節或是鉅細靡遺的事先規劃細節綁死。我們要知道的是：在現今瞬息萬變的環境中，要採取任何行動方案，或是擬定組織願景，又或是設定專案目標，就如同人生的發展一樣，每個人的成長在一輩子中充滿了太多的可變性、不確定性、錯綜複雜性以及模糊性(VUCA)；試想若是在小學三年級，就把未來二三十年的人生計畫規範完畢，照章執行，而不依照外在持續獲得的新知，以及對於自我省思評估的回饋資訊修正調整自己的志向，是完全不可能也不實際的。
迷思2
傳統專案過度依賴文件，敏捷不需要文件
文件在傳統專案扮演了很重要的角色。傳統專案的環境下，客戶對於產品的需求明確，團隊打造產品的手法也是熟練的。在What與How雙軸穩定的條件下，是否明確地蒐集並且詳盡地記錄專案的真需求，並制定出高水平及詳細步驟說明的相關計畫書，的確對於專案的運行來說，扮演了關鍵要素。敏捷其實不是不注重文件，而是強調文件的細節，比不上所有當下所得到的反饋資訊。敏捷也是需要文件的，如是以為敏捷手法不用寫文件，其實是個完全錯誤的認知。很多人認為除了不寫文件是敏捷的特性外，同時認為敏捷也不做任何的規劃動作。事實上是：敏捷在規劃上所耗費的比例，絕對不比傳統做事的方式少；敏捷針對規劃的想法是在於近期細部規劃，而中長期的規劃在於願景刻畫上，在細節上不做特別著墨；簡言之，敏捷的規劃是從案子開始一直到結束前重複執行的動作，有別於傳統作法規劃的心力集中於專案的前期。
迷思3
敏捷團隊的組成，跨職能 Cross-Functional就是唯一最重要的因素
大家都知道，敏捷要發揮其功效，團隊組成上有四個特性：一、團隊是小型的；二、團隊是自組織的；三、團隊是跨職能的；四、團隊成員是通識專才Generalizing Specialists。在團隊初期養成時，小型跨職能的條件是很容易滿足的，自組織需要大環境的支持以及人員心態的培育。很多情況下，直接選擇忽略了通識專才的這個屬性。因為在傳統架構下精細分工，專才是不缺乏的，但是要開發人員在自己專長的領域外，還要具備勝任其他職能的能力，是很少見的，所以在組建或是發展敏捷團隊時，通識專才常常會被忽略。事實上，單具備跨職能並缺乏通識專才屬性的團隊，還不能算是敏捷。因為成員間，無法跨職能互相支援，也很難建立感同身受的同理心，充其量來說，只是把原來的大瀑布切割成以團隊為單位的迷你瀑布。在開發過程中，還是有太多不必要的浪費產生，同時瀑布開發模式因為依賴特定專才的風險還是存在。
迷思4
敏捷之迭代審查等於傳統專案手法的確認範疇流程
傳統手法在內部以「管制品質」對於各種可交付成果驗證之後，接下來就是與客戶坐下來面對面進行所謂的確認範疇流程。此時客戶會依照檢驗審查結果，對於各個可交付成果進行允收或是拒收之實。從外表看起來，敏捷之迭代審查似乎是一樣的事情，開發團隊將在迭代中打造完成的增量產出，送至利害關係人前檢閱，通常配合了實際操作與體驗，所以這個場合就是產品負責人Product Owner代表客戶驗收或是拒絕開發團隊產出的時候。其實這是個迷思，敏捷開發的環境下，需求在主客雙方的認知中，其實有著非常的不確定性或是差距，開發團隊奮力打造的增量產出，其實是對應產品負責人心中對於客戶真需求的推測與假設。這樣的增量產出，利害關係人實際感受到後，有利於他們明白是否符合他們心中期望。不管是否符合，利害關係人的重要回饋，才是指引敏捷團隊未來調適方向的重要資訊。符合了很好，產品負責人可以決定是否將其發布；不符合也很棒，因為客戶真需求也藉由回饋開始浮現在眼前。所以，傳統專案注重的是接受或是拒絕，而敏捷手法在意的是檢查並且調適。
迷思5
大型組織導入敏捷應該要一氣呵成嗎?
你知道嗎？大型組織導入敏捷如果一氣呵成，內部會有彼此協調不彰的後遺症。
對於產品開發而言，敏捷與傳統瀑布方式最大的不同，就是採取批次增量交付，藉由持續檢驗所得來的回饋，進而調適路線修正方向。然而在大規模導入組織時，很多從業人員都抱著一鼓作氣、全面到位的作法；此種方式，反而缺乏了敏捷的基本精神與思維，BigBang的變革模式，不僅在可能遇到的強大環境反彈力道之外，還會因為無法實際了解，所以可能環節對於現有模式的衝擊的情況下，而貿然大步前進；雖然在短時間之內，感覺起來似乎有了動能，但這個都是表面上的和諧，實際上在背後，有著水土不服的危機，還有無法落地生根的衝突感。所以筆者建議：在大規模導入敏捷時，以小團隊為增量單位，迭代式的循序漸進，同時可以藉由組織架構對於實際運作所得到的經驗與參與利害關係人的回饋，調整方向與步伐，如此才可以將所有問題或是衝突提早浮現檯面，也能夠提早因應修正，對是否能夠大規模導入敏捷的最終目的來說，打下一個更穩固的根基。
文章出處 : 《專案經理》雜誌2021年6月號21世紀敏捷人才攻略 Be an Agile Talent