在團隊自我組織的世界裡，管理者還有存在的必要嗎？絕對有。 雖然 Scrum 框架沒有明確提及管理者角色，但管理者在敏捷組織中仍扮演重要角色。本章討論功能管理者（functional manager / resource manager）在 Scrum 組織中的職責，以及專案經理角色的定位。

概述#

根據 2011 年的產業敏捷調查，採用 Scrum 的首要障礙是「管理控制感的喪失」（33%），其次是缺乏前期規劃（33%）和管理層抗拒變革（32%）。

然而，擔心管理者角色變得不重要是沒有根據的。在 Scrum 組織中，功能管理者有四大責任領域：

1. 塑造團隊（Fashioning Teams）
2. 培育團隊（Nurturing Teams）
3. 對齊與調適環境（Aligning and Adapting the Environment）
4. 管理價值創造流（Managing Value-Creation Flow）

塑造團隊（Fashioning Teams）#

定義邊界（Define Boundaries）#

自我組織的團隊很少能自行決定要追求什麼產品或專案。管理者定義團隊被允許自我組織的沙盒（sandbox）或邊界：

• 決定要建造多少個「沙堡」（多少產品/專案）
• 設定每個沙盒的邊界（例如，開發團隊是否需要在每個 Sprint 中自行部署）

提供明確的提升目標（Provide a Clear Elevating Goal）#

管理者為每個團隊提供清晰的目標，賦予團隊方向與意義。例如：管理者決定要做一座「在週末沙堡比賽中贏得最佳作品」的沙堡，產品負責人則進一步定義為「建造一座中世紀城堡，包含塔樓和護城河」。

組建團隊（Form Teams）#

團隊通常不會自行組成——管理者決定誰加入哪個團隊。來自不同學科或實踐社群的功能管理者共同合作，從各功能區域選擇成員組成跨功能的 Scrum 團隊。

管理者致力於組建跨功能多元且充足的團隊，成員具備良好互補的 T 型技能。團隊成員可以（也應該）提供意見，但大多數組織中最終決定權在管理者。

調整團隊組成（Change Team Composition）#

管理者有義務在認為有助於改善團隊與組織整體健康和績效時，調整團隊組成。例如處理低績效成員 Fred 的情況：

1. 團隊成員先與 Fred 討論，嘗試協助
2. 若無效，ScrumMaster 作為教練介入
3. 若教練也無效，問題上升到 Fred 的資源管理者（因為 ScrumMaster 沒有聘僱/解僱的權力）
4. 資源管理者可能將 Fred 調到更適合的團隊，或制定績效改善計畫

管理者也可能為了更好地最佳化組織跨產品組合的交付能力，而將具有特殊技能的人從一個團隊調到另一個團隊，但需謹慎行事。

flowchart TD
    A["發現績效問題"] --> B["團隊成員與當事人討論"]
    B --> C{"改善了?"}
    C -->|"是"| Z["問題解決"]
    C -->|"否"| D["ScrumMaster 教練介入"]
    D --> E{"改善了?"}
    E -->|"是"| Z
    E -->|"否"| F["上升到資源管理者"]
    F --> G{"改善了?"}
    G -->|"是"| Z
    G -->|"否"| H["調職或績效改善計畫"]

賦權團隊（Empower Teams）#

團隊要能自我組織，必須得到管理者的授權與信任。管理者可以委派不同程度的權限，Appelo 定義了七個授權層級：

flowchart LR
    A["Tell<br/>告知"] --> B["Sell<br/>推銷"]
    B --> C["Consult<br/>諮詢"]
    C --> D["Agree<br/>共識"]
    D --> E["Advise<br/>建議"]
    E --> F["Inquire<br/>詢問"]
    F --> G["Delegate<br/>授權"]

    A ~~~ H["管理者主導"]
    G ~~~ I["團隊自主"]

管理者委派權限後，必須信任團隊會履行職責；團隊也必須信任管理者不會做出與委派權限矛盾的行為。管理者不應委派決策權給團隊後，自己又去做決定。

培育團隊（Nurturing Teams）#

激勵人員（Energize People）#

管理者應不斷尋求方法激發團隊成員的內在動機，營造有趣、有創造力、能交付價值的環境。

功能管理者習慣於指派任務層級的工作給下屬——在 Scrum 環境中這樣做會削弱團隊自我組織的根基，使人失去動力。

發展能力（Develop Competence）#

• 團隊成員仍向功能或資源管理者匯報（通常不是 ScrumMaster 或產品負責人）
• 管理者積極輔導直屬部屬的職涯目標，提供頻繁且可行動的績效回饋
• 必須營造持續學習的環境——提供培訓和參加研討會的時間
• 應將回饋頻率與團隊的學習循環對齊（例如每個 Sprint 提供一次回饋），而非僅靠年度績效考核

年度績效考核可能與 Scrum 團隊的短 Sprint 節奏不同步，且可能促進團隊內的低信任競爭而非自我組織。個人績效指標也可能驅動獨立行為——人們最佳化個人指標而犧牲團隊利益。

提供功能領域領導力（Provide Functional-Area Leadership）#

功能管理者繼續在其專業領域提供思想領導力，但這不意味著指派任務或告訴人們怎麼做。例如：

• 遊戲公司的美術總監為遊戲設定美術標準並審查個別美術師的作品，確保整體一致性
• QA 主管可以要求分散在不同 Scrum 團隊中的 QA 人員合作選擇新的測試自動化工具

維護團隊完整性（Maintain Team Integrity）#

因為敏捷的貨幣是團隊，管理者應主動維護團隊完整性：

• 不要在 Sprint 進行中將人員抽調去做寵物專案
• 不要不必要地將人員指派到多個團隊
• 盡量在開發工作結束時將整個團隊指派到下一個開發項目，而非拆散團隊

對齊與調適環境（Aligning and Adapting the Environment）#

推廣敏捷價值觀（Promote Agile Values）#

管理者必須理解、真正相信、身體力行並鼓勵他人實踐敏捷價值觀和原則。常見的現象是團隊說：「這一切對我們來說都說得通，但我們需要管理層的支持，否則無法真正實行 Scrum。」

移除組織障礙（Remove Organizational Impediments）#

管理者與 ScrumMaster 攜手合作移除障礙。雖然 ScrumMaster 是推動移除組織障礙的人，但許多障礙（特別是環境性質的）需要管理者的介入才能真正移除。

對齊內部群組（Align Internal Groups）#

• 工程或 IT 部門往往最先採用 Scrum，但如果部署、銷售、行銷、HR 等群組仍以傳統方式運作，就無法實現 Scrum 的全部潛力
• 管理者（包括高階主管）有責任在整個價值鏈（治理、財務、銷售、行銷、部署、支援）中實現內部對齊

對齊合作夥伴（Align Partners）#

管理者也應在供應商管理與外包中推廣敏捷原則：

• 最簡單的外包形式是租賃第三方的 Scrum 團隊，直接取得高績效團隊
• 應考慮替代固定價格合約——這類合約讓組織與承包商立即處於對立面

管理價值創造流（Managing Value-Creation Flow）#

採取系統觀點（Take a Systems Perspective）#

管理者必須以系統性思維看待整體，而非僅專注自己的領域。局部思維（「這需要改變報告結構或工作職稱，所以不可能」）是成功採用 Scrum 的重大障礙。

管理經濟效益（Manage Economics）#

• 高階管理者透過組合管理（portfolio management）和公司治理來監督經濟效益
• 決定資助哪些開發項目、程度和順序
• 根據迭代式增量開發的持續即時回饋，在經濟效益不再合理時終止項目

監控指標與報告（Monitor Measures and Reports）#

管理者應確保只捕捉和報告有助於價值創造流的指標。依據 Scrum 原則的衡量範例：

• 關注閒置的工作，而非閒置的人員——衡量工作流動何時及多常被阻礙（如 cycle time）
• 以可運作的已驗證資產衡量進展——聚焦於交付的價值
• 為快速回饋組織流動——衡量學習循環完成的速度

創新會計（Innovation Accounting）使用可行動的指標來評估學習速度：(1) 建立 MVP 確定基線指標；(2) 透過產品的增量改進提升指標；(3) 若有明顯進展則堅持，否則轉向（pivot）新策略。

專案經理（Project Managers）#

Scrum 團隊中的專案管理職責#

常見的誤解是 ScrumMaster 等同於「敏捷專案經理」。雖然兩者都移除障礙，但僕人式領導（servant leader）顯著區別了 ScrumMaster 與指揮控制式的專案經理。

傳統專案管理的九大職責在 Scrum 中的分配：

原來的專案經理可以根據技能與意願轉型為三種 Scrum 角色中的任一種：

• 許多專案經理成為優秀的 ScrumMaster（如果能放下指揮控制傾向）
• 也可以轉型為產品負責人（如果具備適當的領域知識）
• 較少見的情況下，有技術背景的可以成為開發團隊成員

保留獨立的專案經理角色#

原則上應由 Scrum 團隊自行處理物流與協調。但在大規模開發（數十或數百個 Scrum 團隊）中，團隊間的溝通通道通常不是完全連通的，而是形成協作叢集（collaboration clusters）——叢集內互動密集，叢集間耦合較輕。

跨叢集協調的預設方式仍是團隊自行處理（如 SoS）。但當叢集數量很多時：

可以透過專案/程式經理來協助協調。但關鍵原則是：

專案經理應被視為 Scrum 團隊的助手（如僕人式領導），而非團隊的上級。專案經理應具備全系統觀點，協助各叢集或團隊理解需要什麼跨團隊協調——但團隊仍擁有協調的責任。

複雜多方開發中的專案經理#

在 Scrum 只是更大產品或服務開發的一小部分時（包含分包商、內部非 Scrum 團隊和其他內部組織），專案經理可以專注於跨各方的物流協調。目標不是讓專案經理負責，而是確保各區域之間的依賴被理解和溝通，讓團隊能有效協調工作。

傳統管理者 vs. Scrum 管理者對比#