敏捷是來自組織精實與團隊認同的結果

敏捷是來自組織精實與團隊認同的結果

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

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

1. 團隊組織是否精實

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

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

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

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

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

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

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

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

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

---

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

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

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

本站所有文章未經事先書面授權,請勿任意利用、引用、轉載。