5個落實敏捷管理的常見問題分析與對策【敏捷管理手札】

敏捷已經是不可逆的浪潮，各公司也陸續開始導入敏捷的概念，或展開敏捷試點工作。

隨著各企業的敏捷投入，如果能預先避免一些其他公司實施敏捷管理常見的問題，毫無疑問的能減少不必要的冤枉路，進而降低進入成本。那各企業開始推行敏捷之後，經常出現哪些困難或挑戰呢？

以下分享一些常見的問題，以及可行的應對策略。

---

問題一：績效考核的公平性

---

敏捷團隊裡各種不同專業領域的專才都有，這種全新的組合也帶來全新的問題。舉例來說，某個敏捷團隊剛拿下一張大訂單，請問該如何論功行賞？

• 銷售人員說：如果不是我每天頭頂鋼盔，忍辱負重，在客戶與公司高層間反覆聯繫與折衝，怎麼可能完成這麼大的訂單？所以我的功勞最大。
• 財務人員說：這次的付款條件空前複雜，如果不是我在公司政策、銀行端、以及客戶的財務部門間反覆溝通，雙方的高層絕不可能批准這筆訂單，所以我的功勞最大。
• 法務人員說：都別吵了，不管你們的方案再怎麼好，都要白紙黑字寫下來才算數，如果不是我跟雙方的律師事務所以及法務部門，明爭暗鬥，字字計較，用盡一切談判手段，根本別想簽約，還敢跟我爭功勞大小。
• 資訊人員說：你們講的都對，但只要IT部門不去執行，你們都是在紙上談兵。我才是最主要做事的人，把雙方ERP系統整合在一起的任務都要靠我不眠不休地去完成，功勞當然是我最大。
• 生產人員說：前期簽合約事小，後期交貨事大。後續要有交貨才能收錢，我的功勞怎麼算？
• 風險分析人員：既然沒人肯定我的貢獻，我離開這個團隊總行吧！

團隊裡每個職能都很重要，任務完成後，如何論功行賞，經常是敏捷團隊產生工作成果後第一個挑戰性的難題。

---

績效考核常見作法的優劣分析

如果公司績效考核制度有強制分配的比例規定，績效等級必須依人數比例分配，那更是吵翻天了。所以這績效考核問題該如何解決呢？以下是幾種常見作法的優劣分析：

作法	優點	缺點
大家是一個團隊，功勞均分	能強調團隊整體的概念，維持團隊內的凝聚力，塑造人人都一樣重要的平等意識。對管理人員而言，相對省事，也不用得罪人。	如果團隊內有比較懶散的、扯後腿的、不合作的一樣可以均分功勞，可能會讓認真做事的員工心生不滿。既然做多做少都是一個樣，大鍋飯制度下，很難期望團隊成員能主動創新，或主動承擔更多責任。如果公司有績效強制分配制度，每個人的績效等級就必須按人數比例分配，就不能都一樣高。
由團隊成員相互投票來決定彼此的貢獻高低	每個人手上都握有賞罰權，能促使團隊彼此更尊重他人的感受，合作更順暢，也更有機會辨識出貢獻度較高的員工。管理人員不用為績效問題傷腦筋，把問題交給團隊解決。	團隊可能會越來越強調「和諧」，即使團隊方向偏差，某成員工作怠惰，沒有人會站出來講話。因為沒有人想得罪人。大家多一事，不如少一事，別跟獎金過不去。人緣好，不得罪人，逐漸成為最高行為準則。為了追求高票數，相互「換票」的結黨行為可能會出現，不參與派系的「孤鳥」票數可能最低，投票結果與實際表現可能出現偏差。
訂定過程考核指標（OKR）	每位成員在過程中都有清楚的「關鍵成果」指標必須滿足，也提供考核的依據。成員過去習慣於OKR指標時，接受度也較高。	可能導致滿足績效指標，遠比滿足客戶需求來的重要。創新不再是創造工作價值的優先考量，考核哪些過程指標，員工就做什麼。如果需求不明，或需求變動大，就不可能在任務一開始就預知過程中的關鍵結果，OKR指標的正確性會很低，可能會限制團隊的思考方式，或引導出錯誤的工作方向。
只考核最終結果（KPI）	這種方式不考核過程，給團隊充分的發揮空間，也能符合敏捷的運作方式。只要能完成最終目標，團隊可以盡其所能地，全力發揮。	如果需求不明確或經常改變，可能導致最終的考核指標，會訂的較為寬鬆，或更有彈性一些。以至於期末時辨識績效高低的難度高，不容易分辨個別團隊成員的貢獻高低。只以成敗論英雄的一刀切考核方式，可能會抹煞團隊成員在過程中的努力。

---

敏捷團隊績效考核的2個建議

整體來看，似乎沒有一種績效考核的方法是完美的。那該怎麼辦呢？

答案很簡單，就是回歸敏捷的精神與作法。以下有兩個建議：

• 第一是回歸敏捷的試驗性精神，實際去測試與調整不同的績效考核作法，甚至是混用不同的手法，看哪一種考核方法最能誘導出團隊的好績效，就用哪一種。不同的任務或不同性質的團隊，適用的考核方式也不同。
• 第二是配合敏捷的頻繁交付，提高階段性的評估次數。敏捷已經從一次性交付成果轉型為「經常交付」，我們的績效考核當然也要從一次性考核轉型為「經常考核」。雖然不一定要做到每個迭代（Sprint）評估一次，但越密集的考核，績效的可辨識度當然是越高。

延伸閱讀：潛藏在團隊和諧下的殺手！預防「艾比林矛盾」對敏捷團隊的負面影響

---

問題二：公司運作習慣於傳統計畫性思維

---

公司設立了敏捷的試點團隊，但主管還是要求產品負責人在期初提供詳細的計畫書，以便向公司高層展示完整的規劃，以及財務預測。更有甚者，財務部門還會要求敏捷團隊依照專案的完成比例動支預算。

這樣的情形會讓敏捷團隊十分困擾，如果一開始就要求交出完整的計畫書，那跟原本瀑布式專案管理的作法完全一樣，一切照計畫走，過程中毫無應變彈性，那敏捷要如何使用？

如果專案的預算要依照完成的比例來撥付，麻煩更大。因為傳統專案管理是以計畫完成的百分比來評量，而敏捷是以交付多少成果來評量，如果連過程都要用傳統的專案完成百分比來評量，敏捷就完全不能用，只能回歸舊式的作法。

要解決這個問題，我們還是要回歸敏捷的優勢。相對於傳統瀑布式的專案管理而言，敏捷式專案管理更適合用在需求變化快速，或是需求不明確的專案，所以公司在分派任務，或評估敏捷的效益時，應該把傳統瀑布式管理不容易做的專案（需求不明或經常變動），交給敏捷團隊來做。

其次，在評估敏捷團隊的計畫上，可以嘗試一開始先接受一個較為概略的全面計畫或專案目標，然後依照每個迭代（或每一個月或每一季），逐步將計畫細節加以明確化，而不是一開始就要求詳盡的計畫書。如果有財務撥款方面的需求，也可以依照階段性的交付成果，或每月/每季的財務規劃達成情形來審核與撥款。

---

問題三：過度擴張每日站立會議的使用

---

公司引入敏捷時，會同時導入「每日站立會議」，但正確性還有加強的空間。在敏捷架構中，進行每日站立會議時，每個人每天同一時間都要回答三個問題：

• 我昨天做了什麼？
• 我今天要做什麼？
• 我碰到什麼障礙？

---

每日站立會議的2個效果

許多公司的老闆會要求各部門負責人，每天上午同一時間一起進他辦公室報告每日站立會議的三個問題。每天都向老闆報告同樣的三個問題，算不算是落實敏捷？要回答這個問題，要先回來看每日站立會議的兩個效果：

效果一：提高工作上的透明性。

讓團隊瞭解彼此的進度，以及大家的工作量與貢獻，避免工作重複進行，也能提高工作的銜接性，強化團隊合作。不是績效考核會議，也不是問題解決會議，更偏向一個廣播式的單向溝通，有問題會議後再加以處理。

效果二：帶來群眾的壓力。

我們不能說設計敏捷的人故意想讓每日站立會議帶來群眾的壓力，因為這些設計者幾乎都是程式設計師的背景，他們的想法應該沒有那麼複雜，但公開發言就一定會帶來一定的群眾壓力。

想想看，團隊在報告時，其他人天天都有進展，一個任務接一個任務地認領新工作，而你的工作遲遲沒有進展，認領的工作量也少，請問你自己會不會有些壓力？其他團隊成員看你的眼神，會不會讓你覺得有些不自在？這種團隊成員間形成的壓力，是促成敏捷團隊自主管理一個很重要的約束力來源。

接下來我們來看看，老闆把各部門負責人召集起來，每天開站立會議是否有效果？如果開會的目的是要求每個部門分享工作進展，提高部門間業務銜接的透明性，那肯定會有一些效果。

但要注意的是部門的工作由許多的敏捷團隊與個人所共同完成，個別的小進展可能天天有，但部門整體的工作進展可能需要幾天甚至幾週的時間，才能累積成明顯的進展，每天召開站立會議，有那麼多進展能天天回報嗎？如果每天的進展變化不大，天天開站立會議會有提高透明性的效果嗎？

其次是營造群眾壓力的效果。依你自己的經驗，在部門例行會議上，其他人在報告時，你在做什麼？經常是在想自己的事情是吧！每個人各做各的，別人做的好壞與你有何關係？所以如果參與每日站立會議的人員，彼此工作上關連度低，各報告各的。別人在報告時，你只能在旁枯等，還不如回辦公室工作還比較有生產力。

所以，一群部門負責人每天站在老闆面前報告工作進展符合每日站立會議的精神嗎？ 答案應該是見仁見智的。但可以確定的是來自老闆的壓力肯定非常巨大，因為老闆把團隊自主管理的工作自己扛起來做了。

延伸閱讀：一次搞懂每日站立會議(Stand up meeting)！全面提升敏捷團隊績效

---

問題四：未實際落實敏捷回顧會議的功能

---

通常為了方便起見，敏捷團隊在開完審查會議之後，原班人馬會在原場地就直接開回顧會議，因為這樣的安排最有效率，不需要重新預約會議室，也不需要花時間重新暖場。

如果前面的審查會議進行順利，團隊接著開回顧會議，除非是真的到了無法忍受的地步，心情好時即使有團隊合作上的問題也不見得會提出來。但問題經常是出在前面的審查會議受挫後，接著開的回顧會議仍然會聚焦在開發過程中的問題，而不是回顧會議上該檢討的團隊合作流程。

儘管我們不斷提醒團隊，先把開發上的問題放一邊，先開回顧會議解決團隊合作的問題。但團隊猶如一群鬥敗的大公雞，腦海中只有剛才被客戶或產品負責人挫敗的失落情緒，根本沒有心情討論回顧會議的議題。如果是這樣，建議不妨讓團隊繼續開產品檢討會議，另外再找時間開回顧會議。

不過問題經常也出在這裡。團隊經常會因為進展順利，容忍團隊協作上的瑕疵，回顧會議沒有認真開；或是進展不順利，導致回顧會議的時間被用在其他地方，而沒有開會。敏捷回顧會議累積一些時間沒有開會，或沒有發揮應有功能，將導致成員間的摩擦逐漸擴大，衝突越來越多，最後會影響團隊的運作。

解決的方法當然就是要固定在每個迭代結束前開回顧會議。如果因故無法在同一個迭代內召開回顧會議，在下一個迭代的規劃會議開始之前，先花個30分鐘到一小時，召開上一個迭代的敏捷回顧會議也是可以的。

延伸閱讀：高績效敏捷團隊維持專案品質與效率的秘密—視覺化的「帆船回顧會議」

---

問題五：只有敏捷試點單位懂敏捷

---

公司認真的成立了敏捷團隊，也提供敏捷團隊相關的訓練與資源。但需求單位不瞭解敏捷，仍習慣於傳統的作法，專案一開始提完需求之後，就只等最後的結果。

當敏捷團隊進行階段性的交付，要求需求單位出席審查會議時，收到的回應經常是：「需求講的很清楚了，給我們結果就好」、「你們部門內部的驗收，你們自己處理」、「我們部門沒有多餘的人力可以支援你們做測試」等。

但問題經常是：人們經常是要看到東西之後，才會發現自己需要什麼。例如：你要買一台新的電視機，該考慮的尺寸、規格與功能都考慮完整了，買回家才發現看久了眼睛容易酸，才發現為了小孩，你應該買有護眼或濾藍光功能的機型。但在這之前你完全不知道你會有這方面的需求，你想到的只是尺寸與價格而已。

所以期末一次性交付專案成果的風險是非常巨大的，如果使用者對自己的需求不能充分掌握，一次就把事情做對是絕不可能的。公司不想在敏捷的測試評估完成前，就投入大量資源來進行全員培訓的想法是可以理解的，但這對負責評估敏捷效果的敏捷團隊卻是個難以跨越的門檻。

外部客戶有時反而比內部客戶更願意配合，因為他們付了錢，會希望做出更符合他們需要的產品，如果訂合約時就清楚溝通要求客戶來配合階段性的交付驗收，彼此會配合的更好。而內部客戶就需要更多的溝通，鼓勵他們參與到敏捷運作的過程中來，才不會回到開發結果不符需求時，互踢皮球的老路。

整體來看會發現落實敏捷的主要困難，主要都落在我們已經習慣了較具有全局觀的計畫性思維，與過去的運作方式。要落實敏捷不是只有負責執行的敏捷團隊需要做改變，公司整體的績效考核制度與運作方式都需要跟著敏捷化，不斷地「滾動檢討、滾動調整」，來試驗出一套最適合公司運作的敏捷方法，以更多「階段性」的應變思維，來取代「一次性」的固定思維。

延伸閱讀：一次搞懂Kanban看板管理法—最容易上手的敏捷工作法