要在 Scrum 上取得長期成功，敏捷化的影響必須傳遞到組織的其他部門。如果忽視開發團隊以外的群體，組織慣性（organizational gravity）——那些在轉型開始前就塑造了組織形態的力量——會把一切拉回原點。

本章探討三個經常被忽略但影響深遠的群體：

• 人力資源（Human Resources）：年度績效考核只獎勵個人貢獻，與 Scrum 強調的團隊協作直接衝突
• 設施管理（Facilities）：當設施部門阻止團隊使用牆面張貼 burndown chart，或無法提供適合協作的空間時，團隊士氣會受挫
• 專案管理辦公室（PMO）：如果 Scrum 團隊以「不需要文書和流程」的態度啟動專案，PMO 會成為敵人而非盟友

人力資源（Human Resources）#

HR 相關的問題大多源自從個人當責轉向團隊共同當責的改變。正如 Katzenbach 和 Smith 在 The Wisdom of Teams 中所述，大多數組織本質上偏好個人而非團隊——職位描述、薪酬方案、職涯路徑和績效評估都以個人為焦點。

作者分享了一個典型案例：Chuck 是團隊中最優秀的程式設計師之一，當聽到要嘗試 pair programming 時，他站起來威脅要去告 HR。Chuck 擔心結對程式設計會讓主管無法分辨誰寫了什麼程式碼，導致他的加薪被拖累。HR 主管 Ursula 支持了 Chuck 的立場，禁止團隊進行結對程式設計。

像 Chuck 這樣的情境說明，Scrum 轉型中最棘手的問題往往與人力資源政策相關。HR 部門的人既可能是重要的助力，也可能是巨大的阻力。

彙報結構（Reporting Structures）#

沒有哪一種彙報結構是 Scrum 成功的必要條件。功能型、專案型和矩陣型組織都可以成功。但作者建議組織結構應儘可能扁平化——團隊成員與高層之間的層級越多，產生功能失調的機會就越大。

向 ScrumMaster 彙報：常見的建議是團隊成員不應向 ScrumMaster 彙報，以避免在 daily scrum 中不敢暢所欲言。作者的觀點較為溫和——如果 ScrumMaster 能理解不應將成員提出的障礙當作攻擊的武器，那麼讓團隊成員向 ScrumMaster 彙報是可以接受的，而且這樣的 ScrumMaster 有時更能有效移除障礙。

向 Product Owner 彙報：作者強烈反對團隊成員向 product owner 彙報。健康的團隊中，product owner 與團隊之間應存在自然的張力——product owner 推動更多功能和更快交付，團隊則在必要時推回以保護產品的內部品質。當 product owner 同時是老闆時，這種張力會消失。同理，ScrumMaster 也不應向 product owner 彙報。

定期績效考核#

許多人呼籲廢除年度績效考核制度，但在大多數組織中這不太可能實現。更務實的做法是調整考核方式，減少負面影響、強化正面效果：

• 儘量減少個人因素的權重：個人導向的考核因素會引導個人導向的行為。如果完全消除個人因素會遇到太大阻力，可以嘗試個人與團隊因素各佔 50% 的折衷方案
• 納入團隊合作因素：不只是問「這個人是否與人相處融洽」，而是改為團隊層級的衡量。例如將「個人是否在預算和時程內完成任務」改為「團隊是否在預算和時程內完成工作」，且團隊成員獲得相同的評分
• 提高考核頻率：不要只做年度考核。Scrum 專案變化快速，員工在頭一兩年不斷學習新技能，更頻繁的回饋對雙方都有利
• 從廣泛的來源徵求意見：撰寫績效考核時，向員工的 ScrumMaster、product owner、團隊成員、同職能群組的同事、甚至合作過的使用者或客戶徵求回饋
• 教育並爭取 HR 部門的參與：主動讓 HR 了解開發組織正在進行的變革。邀請 HR 人員參加 Scrum 培訓。Yahoo! 的敏捷產品開發總監 Gabrielle Benefield 就是這樣做的，結果 HR 部門甚至開始用 Scrum 來管理自己更新年度考核流程的專案

移除團隊成員#

團隊是否有權將某人逐出團隊（所謂的「voting someone off the island」）？作者認為團隊不應單獨擁有這個權力。根據第 12 章討論的 CDE 模型（Container, Differences, Exchanges），自我組織發生在組織設定的邊界之內，而團隊組成的最終決定權應由組織的領導層掌握。領導者當然應該傾聽團隊的意見，但不應讓團隊自行決定移除成員——因為團隊可能會出於本能排斥新加入的、不同風格的成員，從而破壞領導者刻意引入多樣性的努力。

職涯路徑（Career Paths）#

Scrum 帶來的組織扁平化和角色消除，會讓許多員工擔憂自己的職涯發展。傳統路徑是：技術熟練 → 團隊領導 → 經理 → 高級經理，每一級都有更多直屬下屬。

在 Scrum 組織中，成功不再以管理的人數來衡量，而是以被賦予的責任來衡量。例如：

• 新的 ScrumMaster 可能先負責一個小型、成熟的團隊
• 成功後轉而協助一個沒有 Scrum 經驗、更重要的專案團隊
• 最終可能同時服務多個團隊、領導 ScrumMaster 實踐社群等

這種「成功帶來更多責任」的路徑適用於所有角色——程式設計師、測試人員、設計師等。SAS 公司就是這種文化的典範，它相信激發心智的工作能帶來卓越的績效和更好的產品，最恰當的獎勵是一個更具挑戰性的專案。

設施管理（Facilities）#

在不適當的工作空間中嘗試 Scrum 是一件非常困難的事。理想的工作空間能夠支持團隊成員以敏捷方式工作。物理環境對團隊敏捷程度的影響如此之大，以至於 Kent Beck 和 Cynthia Andres 在 Extreme Programming Explained 第二版中將「Informative Workspace」提升為主要實踐之一。

空間#

傳統的六呎高隔間牆是協作的明確障礙。最常見的替代方案是室內設計師所謂的「caves and commons」——結合小型安靜空間（caves）和共同區域（commons）。

Scrum 團隊通常會完全放棄隔間，以大型開放式共同工作區為主，搭配幾個小型辦公室或會議室。3M 的 Scrum 團隊描述他們對開放空間的感受：「我們發現開放區域對於鼓勵即興協作非常棒。團隊成員可以快速看到其他人是否有空。」

大多數人發現，與隊友更頻繁互動所帶來的好處遠超過噪音增加的壞處。如果有人真的需要安靜，退到「cave」中應該是被團隊尊重的選項。

War room 的概念進化：在 Scrum 之前，許多團隊會渴望一間專屬的「war room」（會議室）。但在開放式工作空間中，整個空間就是 war room。Daily scrum 和其他會議直接在團隊的開放空間中進行。

大型專案的空間配置：100 人的專案不需要全部坐在一個巨大的開放空間。更好的做法是建立多個能容納約 20 人的開放區域，讓三四個密切合作的團隊共享。注意讓人們按 Scrum 團隊而非職能坐在一起——避免所有程式設計師坐在大樓的一邊、所有測試人員坐在另一邊。

高層支持的重要性：改善工作空間往往需要 Enterprise Transition Community 或高階主管的支持。Scrum 培訓師 Gabrielle Benefield 在領導 Yahoo! 的轉型時發現，設施部門通常有自己的流程和官僚體系，團隊經常被拒絕，需要持續溝通並爭取高層支持來移除這些障礙。

傢俱#

• 可移動的桌子是最佳選擇：允許團隊自由排列工作區域，傳遞「你們要自我組織」的訊息。有些團隊喜歡面對面坐、有些喜歡背靠背
• 桌面的形狀和寬度比桌子本身更重要：pair programming 需要兩個人舒適地並排坐在同一個螢幕前，小型或弧形桌面會造成困難
• 注意小細節：電話是常見的問題來源。搬遷桌子後改接電話線比想像中困難。有些公司嘗試在開放空間中用共用電話取代個人電話，但團隊成員可能會覺得被剝奪了身份感

工作空間中應該可見的物品#

• 大型可見圖表（Big, Visible Charts）：sprint burndown chart、release burndown chart、通過的客戶驗收測試數量、每日測試通過/失敗狀態等
• 額外的回饋裝置：熔岩燈（自動建置失敗時亮起）、紅綠燈、LED 顯示看板等，將資訊以不打擾的方式帶入工作空間
• 團隊所有人：每個人都應該能看到其他團隊成員，包括 ScrumMaster 和理想情況下的 product owner。ScrumMaster 通常坐在最靠近入口的位置，像守門人一樣保護團隊免受外部干擾
• Sprint backlog：最好以 task board 的形式展示在牆上。Task board 以行列排列，每行代表一個 user story，每列至少包含 To Do、In Process、Done

• Product backlog：將即將到來的 user story 卡片釘在牆上或放在團隊空間中央的鞋盒裡，讓成員看到當前 sprint 的工作如何與更大的全貌相連
• 至少一塊大白板：放在共同區域中鼓勵即興討論
• 安靜私密的空間：開放溝通很重要，但有時成員需要安靜思考或打私人電話
• 食物和飲料：不需要多高級，一台小冰箱或咖啡機就能讓空間更宜人
• 窗戶：在開放空間中，窗戶的景觀可以被所有人共享

專案管理辦公室（The Project Management Office）#

一個積極參與並支持 Scrum 轉型的 PMO 可以成為巨大的助力。反之，如果 PMO 沒有被適當納入，它可能成為抵抗的來源——試圖維護現有流程而非促進改善。

PMO 中的人自然會抗拒 Scrum，因為 Scrum 將傳統的專案管理職責分散給了 ScrumMaster、product owner 和團隊，讓專案經理不確定自己的角色定位。加上 Scrum 和敏捷文獻中幾乎不提 PMO，更加深了他們的不安。

PMO 在 Scrum 組織中的貢獻可以從三個面向來看：人員、專案和流程。

人員（People）#

• 制定培訓計畫：PMO 可以協助安排 Scrum 培訓課程——選擇外部講師、安排內部培訓、或親自授課
• 提供教練服務（coaching）：超越課堂培訓，實際坐在團隊旁邊，引導他們進行真正的 sprint planning meeting 或其他 Scrum 活動。PMO 初期可能需要從外部引進教練，但應著力培養內部教練能力
• 選拔和培訓教練：成功的 Scrum 推廣終將需要超出 PMO 自身能力的教練數量。PMO 應識別並培養組織內部的教練——通常是保留原職但額外花每週數小時協助特定團隊的人
• 挑戰既有行為：當團隊開始回歸舊習慣時，PMO 成員應指出來。後期則提醒團隊 Scrum 的核心是持續改善，防止自滿的出現

專案（Projects）#

• 協助報告：協助產出標準化的週報或狀態報告，由 product owner 或 ScrumMaster 出席狀態會議
• 協助合規需求：幫助團隊了解 ISO 9001、Sarbanes-Oxley 等標準的要求，作為合規知識的集中交換中心
• 管理新專案的流入：協助控制新專案進入開發組織的速率，避免工作堆積。每完成一個專案，才啟動一個同等規模的新專案

流程（Process）#

• 提供和維護工具：工具決策通常應留給個別團隊，但 PMO 可以協助採購、配置和客製化
• 協助建立和收集度量指標：Scrum 團隊對度量指標比傳統團隊更加謹慎，PMO 應謹慎行事。重點應該是收集團隊交付價值的相關資訊
• 減少浪費：agile PMO 應積極幫助團隊消除流程中的浪費——不必要的文件、會議、審批等
• 建立和支持實踐社群（communities of practice）：這是 agile PMO 最重要的貢獻之一。實踐社群不僅幫助 Scrum 在組織中傳播，也幫助好的想法從一個團隊傳遞到另一個團隊
• 在團隊間建立適當的一致性：不是透過命令來強制一致，而是透過實踐社群和共享教練讓好的做法自然擴散
• 協調團隊：PMO 成員與多個團隊合作，往往最先發現團隊之間工作開始偏離或重疊的狀況
• 以身作則使用 Scrum：許多 agile PMO 最終會用 Scrum 來管理 PMO 自己的工作——進行月度 sprint、每日 scrum 等
• 與其他部門合作：PMO 可以協助團隊與 HR 和設施管理部門溝通

重新命名 PMO#

許多 PMO 選擇重新命名以匹配其轉變後的角色。常見的新名稱包括：

• Scrum Center of Excellence
• Scrum Competence Center
• Scrum Office
• Development Support

無論叫什麼名字，PMO 必須實質性地改變其運作方式，而不只是換個名稱。如果只改名而內容不變，只會招來更多的冷嘲熱諷。

總結#

你可以暫時忽視 Scrum 對這些群體的影響而仍然取得短期成功。但終究必須爭取它們的配合，才能實現成功且持久的轉型。採用一個以「個人與互動重於流程與工具」為核心信念的流程，卻不讓人力資源部門參與其中，幾乎是荒謬的。同樣地，物理環境直接影響團隊的工作方式，而 PMO 擁有豐富的政治資本和專案經驗。

與其將 HR、設施管理和 PMO 視為需要克服的障礙，更好的策略是將它們視為需要爭取的盟友。通往敏捷的道路漫長，在可能的時候，選擇交朋友而非樹敵。