在許多敏捷愛好者的眼中,他們經常認為敏捷實作依賴於僕人式領導的精神(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
熱門新聞
2024-10-05
2024-10-04
2024-10-02
2024-09-29
2024-10-03
2024-10-01
2024-10-01