更有效的敏捷領導力

在許多敏捷愛好者的眼中，他們經常認為敏捷實作依賴於僕人式領導的精神（servant leadership）。我相信這是真的，但我也認為它太模糊了，對於敏捷導入沒有特別助益。我們需要更直接的指引。無論你是決定全面採用敏捷，還是小規模地採用敏捷，領導力（leadership，領導階層）都是敏捷實作的成敗關鍵。

關鍵原則：管理結果，而不是管理細節

組織的生死取決於他們做出的承諾和他們遵守的承諾。有效的敏捷實作包括了團隊與領導階層之間的互相承諾。

敏捷團隊（特別是Scrum團隊）向領導階層承諾，在每個Sprint結束時，他們會交付他們的Sprint目標。在循規蹈矩的（high-fidelity）Scrum實作中，承諾被視為絕對的─團隊將竭盡所能地工作來實現他們的Sprint目標。

相對的，領導階層也要向Scrum團隊承諾，Sprint是神聖不可侵犯的。領導階層不會在Sprint期間改變需求或擾亂團隊。在傳統的循序式專案中，這不是一個合理的期望，因為專案週期很長，而且情況必然會發生變化。然而在Scrum專案中，這種期望是完全合理的，因為Sprint通常只有1到3週的時間。如果組織在這段時間內都不能保持專注而不改變想法，那麼組織所面臨的問題可能比「Scrum實作是否成功」這件事還要更嚴重。

「將團隊和Sprint視為黑盒子」以及「僅管理Sprint的輸入和輸出」，這樣的想法和做法帶來了理想的副作用，有助於業務主管避免「微觀管理」（micromanagement），並且鼓勵更多的領導姿態。業務主管需要為團隊指引方向、解釋工作目的、詳細說明不同目標之間的優先順序，然後讓團隊自由發揮，獲得讓他們感到驚豔的結果。

關鍵原則：用指揮官意圖表達明確目的

「自主」（Autonomy）和「目的」（Purpose）是相互關聯的，因為除非團隊了解他們工作的「目的」，否則他們無法擁有「有意義、健康的自主權」。一個自我管理的團隊需要在內部做出絕大多數的決策。他們具有跨職能的技能和這樣做的權力。但是，如果團隊沒有清楚地了解他們工作的「目的」，團隊的決策就會被誤導（字面意義上的「被帶入歧途」）。根據「團隊的自主權」（自主）和「目標的明確性」（目的），團隊可能會獲得不同的結果。

「指揮官意圖」（Commander's Intent）是美國軍方使用的一個概念，指的是對「期望的最終狀態」的公開聲明、軍事行動的目的，以及必須完成的關鍵任務。「指揮官意圖」在這些情況下特別有用：當事件沒有按照原計畫展開時、當溝通中斷時，以及當團隊需要在無法與「更高層級的指揮官」商量的情況下做出決策時。

在軟體情境中，你的目標是相似的。與公司領導階層的溝通可能不會被強行打斷，但一般來說，我們會有很長的一段時間，不容易接觸到公司的領導階層。此時，事件並沒有按照原計畫展開，而團隊仍然需要做出決策。在這種情況下，團隊將因擁有「指路明燈」或「北極星」或「指揮官意圖」而受益，他們可以從中得到方向。

一個良好的「指揮官意圖」將包括以下內容：

●描述這份專案或計畫的「原因」與「動機」；即「目的」。

●生動地視覺化「期望的最終狀態」。應該要讓團隊成員了解成功的樣貌，以及他們在實現成功過程中所扮演的角色。

想要成為「敏捷」的組織需要培養「清楚描述目的」的能力。其管理者應該要更重視透過目標（objective）進行領導，而不是透過關注細節進行管理。正如George S. Patton所言：『絕對不要告訴人們該如何做事。只需要告訴他們該做哪些事，他們的巧思和創意會讓你大吃一驚。』

設定與溝通優先順序

有成效的敏捷主管會透過傳達「明確的優先順序」來支持他們的團隊。我們看過許多組織，他們把所有事情都列為最高優先事項，並把難題留給團隊去解決。有些公司甚至會過度頻繁地重新確定優先順序，或是優先考慮過於精細的細節，或是完全拒絕進行優先順序的排序。這些錯誤非常普遍，導致成效低落。

拒絕進行優先順序的排序是領導階層軟弱的表現。這相當於放棄了制定決策的責任。如果你關心「會完成什麼工作」，就必須針對優先事項做出決定，並將這些決定明確地傳達給你的團隊。

頻繁地重新設定優先順序可能同樣地具有破壞性。優先順序的頻繁變化會破壞團隊的自主權和使命感。主管應該問自己：『從現在起的6個月後，這次重新設定的優先順序是否同樣重要？』如果答案是否定的，那麼它就沒有重要到必須隨機調整團隊的程度。

「指揮官意圖」是一個很好的視角，透過它可以查看適當的優先順序。主管應該要定義成功的樣貌─目標、結果、影響和收益─但不要定義細節。

在設定優先順序這個領域，有效的敏捷實作有機會突顯出組織的弱點，進而威脅到主管。我們偶爾會看到主管終止了敏捷實作，因為頻繁的交付（或缺乏頻繁的交付）突顯了主管無法為他們的團隊提供明確的優先順序。

這一點的重要性再怎麼強調都不為過。如果你無法有效地設定團隊工作的優先順序，那麼你就不是在領導。你的專案所取得的成果將遠遠不及它能夠取得的成果，也遠遠達不到你的團隊應得的成果。設定優先順序方面的弱點或缺失會帶來不適，但任何想要提升效率的組織都不會迴避這一點，反之，他們會利用這種不適作為改進的動力。

關鍵原則：關注產出量，而不是活動

不稱職的主管往往更關注「趕進度」的「感覺」，而不是專案進度的「真實情況」。但並非所有的活動都是進度（progress，進步），而「忙碌」經常是糟糕結果的代表。

一個富有成效的組織，它的目標應該是最大化「產出量」（throughput），即工作完成的速度，而不是工作開始的速度或活動的多寡。主管必須接受，一定程度的鬆綁對於最大化「產出量」來說是必要的（DeMarco, 2002）。

Scrum在團隊層面而不是在個人層面保持「當責（accountability）意識」的一個原因是它允許團隊「自行決定」如何才能達到最高效能。如果其中一位團隊成員休息（暫停）一天就能提升工作效率，那麼團隊可以自由地做出這項決定，讓他休息一天。

「允許個人擁有空閒時間」是一種違反直覺的「最大化」產出量的方法，但追根究底來說，對組織而言，重要的是每個團隊的總產出，而不是每個人的產出。如果團隊正在有效地優化團隊生產力，那麼組織就不應該關心個人層面所發生的事情。

關鍵原則：關鍵敏捷行為的表率

稱職的主管會以身作則，表現出他們希望在員工身上看到的那些行為。這些行為應該包括：

●「培養成長心態」：致力於在個人層面和組織層面持續精進。

●「檢查和調整」：不斷反思、從經驗中學習，並應用所學。

●「寬容對待錯誤」：接受每個錯誤並將其視為學習機會，使用這種做法以身作則。

●「修復系統，而不是個人」：當問題發生時，將其視為尋找系統缺陷的機會，而不是責怪個人。

●「承諾高品質」：用你的行動來傳達對高品質的明確承諾。

●「發展業務重點」：展示你的決策如何包含業務方面及技術方面的考量。

●「強化回饋迴圈」：積極回應你的團隊（即使他們不需要，因為你已經清楚地表達了你的指揮官意圖）。

建議的領導行動

 檢查 

回顧自己作為主管的表現：

●你是否將你的敏捷團隊視為黑盒子，管理他們在履行承諾方面的表現，而不是管理細節？

●你的「指揮官意圖」表達清楚了嗎？你的團隊能否為他們的工作表達一個生動的、最符合現狀的成功定義？如有必要，他們是否可以在沒有你參與的情況下工作幾週？

●你是否為你的團隊設定了明確和現實的優先事項，並為此進行溝通？

●你是否關注團隊的產出量，而不是他們表面上的活動多寡（而不是他們看起來有多忙碌）？

 調整 

●要求你的團隊根據上述「檢查」標準對你的領導績效做一個360度的審查。以身作則從錯誤中學習，歡迎你的團隊給予回饋。

●根據你的自我評估結果和團隊的意見，制定一份「個人領導力自我提升行動」的優先清單。（本文摘錄整理自《敏捷升級》第16章，博碩文化提供）

 書名  敏捷升級：28個提升敏捷成效的關鍵原則

Steve McConnell／著；江玠峰／譯；盧國鳳／審校

博碩文化出版

定價：650元

 作者簡介  Steve McConnell

國際公認的軟體開發實踐思想領袖。他是《Code Complete》的作者，這本暢銷書經常被認為是有史以來最受好評的軟體開發書籍。McConnell的其他著作還包括《Software Estimation》和《Professional Software Development》。他以Construx Software執行長的身分主持Construx的年度軟體領導力高峰會（Software Leadership Summit）。他喜歡與世界各地的軟體主管交流互動。圖片來源_Steve McConnell