「天下武功，無堅不破，唯快不破。」這句話來自周星馳電影《功夫》裡，火雲邪神一角所說過的經典台詞。簡意是說，「快」為武功的最高境界，沒有任何招式能將其克制。「快」，也是普遍台灣中小企業一直在追求的，尤其當敏捷管理的概念在台灣開始被廣泛推廣時，快速迭代馬上就成為各企業朗朗上口的詞彙，彷彿只要夠快，產品就能搶得先機，並且逐步站穩市場，但真的是這樣嗎?

過去幾年，敏捷管理一度在台灣科技產業間盛行，但經過蜜月期之後，開始有人探討敏捷管理失敗的原因，我從自己實際參與幾年的敏捷團隊運作，從兩個面向來切入探討 :

1. 團隊組織是否精實

敏捷團隊最佳的人數約在5到10人間，並且橫跨不同職能角色。主要的原因在於，過多的人數會增加溝通複雜度，缺乏不同角色的團隊，則無法有效橫向串聯，在任務的執行上容易出現漏洞。組織層級關係一向是職場上為人詬病的羈絆，傳統企業喜歡階層式管理，當企業逐漸擴大時，一個決策可能要經過多個主管，自然就拖慢了專案運作速度。

敏捷團隊的核心精神並不是靠快速溝通、快速核決，甚至刻意加快執行速度來達到敏捷的成效，而是簡化了縱向、橫向的往來複雜性，並透過每天10到15分鐘的站立會議(註1)，讓團隊成員將問題透明化，取代信件、會議的等待時間。當工作中的雜訊被降低後，自然有更多的時間、更高的效率可以投入重要的任務中，因此反映出快的結果。

另一個重要的因子，是公司、主管必須充分授權團隊運作，減少出手干預。當團隊能夠為自己的決定負責、面對產品推出後的成敗，才能從用戶端取得最直接的回饋，進而自發性提出改善的提案，然後反覆執行，在每一次的優化中吸取教訓，做為下一次修正的參考。導致敏捷團隊失敗的原因之一，便是Sponsor的過度指導，使團隊無法打從內心支持提案，甚至意圖去滿足Sponsor的期望，這樣的迭代速度再快，時間一久，也會消磨團隊向心力。

2. 團隊成員是否認同敏捷管理的精神

敏捷團隊雖然減少了溝通的層級與方式，但並非減少溝通的次數，反而強調成員之間的即時溝通。要達成即時溝通的兩個要件，其一是團隊成員必須聚集在同一個區域內工作(註2)，其二是成員必須願意去溝通。而我認為最重要的是後者，偏偏多數的企業總以為把大家關在一間辦公室裡面，大家就會自主產生各種腦力激盪的火花。但身分、任務的差異原本就會造成工作型態的不同，若再加入每個人的獨特性格，就可以想像同處一室擦出的不一定是美麗的火花，也有可能是燎原的星火。

先撇開性格問題不談，在凝聚敏捷團隊之前，最好要讓每個人充分理解敏捷管理的精神，以及需要配合的項目等等。

我曾經有一次新創團隊的經驗，過程中因為成員們對於文件的產出形式出現認知差異，導致不愉快收場。企劃認為敏捷的運作要快速迭代，因此很多規格是透過口頭交代，文件上只有簡易的圖文說明，工程師則強調規格寫法不精確，與其花時間說明規格，不如提供詳細的文件較不干擾工程師開發。這個經驗並不是要追究誰該負起責任，而是敏捷管理在執行上的確會有文件不齊全的風險，在決定運作之前，團隊若無法在基本的規範上取得共識，就會出現大大小小因著眼點不同而產生的衝突。

至於溝通意願，我倒有一個令人開心的經驗，當時我任職一間上市資訊公司，由於公司正值實驗及推廣敏捷管理的階段，因此給予團隊充分授權，也使我們能夠扎扎實實執行相對正統的敏捷管理。某天團隊有一位工程師在review會議(註3)中提到自己在團隊運作一段時間後，因為經常性的溝通往來，不自覺逐漸修正了原本火爆的脾氣，並且也很願意在會議中檢討自己的缺失，這是一開始所預料不到的收穫。

整體來說，敏捷管理並不是萬靈丹，在導入任何管理機制前，都應該做好充分的準備與溝通，並理解這些機制能解決的核心議題，以及可能衍生的問題或風險，然後妥善去應對。執著去定義目前所使用的方法屬於瀑布、敏捷，或混合形式，並不會讓專案變得順利，找到最適合團隊的運作模式才是最須關注的事。

---

註1 : 站立會議是敏捷管理中所提倡的會議形式，會議必須在15分鐘內結束，因此通常會採用站立的方式，讓大家容易聚焦且簡短時間。會議中每個人輪流發言，簡述自己昨天完成什麼事、今天預計做什麼事，以及需要什麼協助。當有成員提出請求時，其他成員可以快速回應，若無法馬上取得共識，則將議題記錄下來，於會後追蹤。

註2 : 敏捷管理提倡war room(戰情室)的概念，亦即將敏捷團隊集中在同一間辦公室內，使團隊成員能夠即時溝通解決問題。

註3 : Sprint Review Meeting，是在每個執行週期(一般來說是兩周左右)結束的時候舉行，目的在讓團隊成員共同檢視成果，並收集改善方案。是產品能快速迭代的重要基石。