Scrum 很少能在完全不受外部干擾的理想環境中實施。現實中，組織幾乎總要面對三種「入侵」：需要與另一個按順序管理的專案協作（或在 Scrum 專案中以順序方式執行部分階段）、需要遵守企業治理（governance）體系、以及需要符合法規或標準的合規（compliance）要求。

混合 Scrum 與循序式開發#

當組織同時存在 Scrum 團隊和循序式（sequential/waterfall）團隊時，兩者之間的互動會產生諸多挑戰。Stage-gate 方法是最常見的衝突來源。

從循序式專案接收輸入#

Scrum 團隊經常需要接收來自循序式專案的交付物作為輸入。典型問題是：循序式團隊承諾在某個日期交付某個元件，但由於循序式專案本身的延遲風險，Scrum 團隊往往面臨不確定的等待。

應對策略包括：

• 儘早識別依賴關係，並在 product backlog 中明確標註
• 建立緩衝：不要把依賴項排在 sprint 的第一天
• 持續溝通：與循序式團隊保持定期聯繫，儘早掌握延遲資訊

向循序式專案提供輸出#

反過來，當 Scrum 團隊需要向循序式專案交付元件時，挑戰在於循序式專案通常需要提前知道確切的交付範圍和日期。Scrum 團隊可以透過固定日期、調整範圍的方式來配合，同時利用每個 sprint 的增量交付來讓對方提早獲得部分可用的成果。

在 Scrum 專案中執行循序式階段#

有時 Scrum 專案本身也需要在前端或後端包含循序式階段。例如：

• 前端階段：某些專案需要一段前置的架構探索（architectural spike）或需求蒐集期
• 後端階段：硬體相關的專案可能需要在軟體開發完成後進行製造或部署階段

關鍵原則是讓循序式階段儘可能短，並在其中仍然保持 Scrum 的精神——透明、檢視與調適。

治理（Governance）#

企業治理指的是組織用來確保專案符合策略目標、資源被適當分配的管控機制。大多數治理體系是為循序式開發設計的，因此與 Scrum 存在天然的摩擦。

Stage-Gate 審查#

傳統的 stage-gate 流程要求專案在各階段之間通過正式審查才能繼續。這些 gate 通常假設專案按照「分析 → 設計 → 實作 → 測試」的線性流程推進——這與 Scrum 的迭代本質直接衝突。

應對 stage-gate 審查的策略：

• 重新定義 gate 標準：將 gate 從「是否完成了某個階段」改為「是否交付了足夠的商業價值」
• 利用 sprint review 作為自然的審查點：每個 sprint review 本身就是一次展示進度和獲得回饋的機會
• 提供替代的證據：用 working software、burndown chart、velocity 等 Scrum 產出物來取代傳統的階段文件

調整治理體系#

長期來看，組織應該調整治理體系以更好地適應 Scrum：

• 將資金核准從「專案層級一次性核准」改為「增量式資金分配」
• 用可運作的軟體作為進度的主要衡量標準，而非文件完成度
• 讓 gate 審查關注風險降低和價值交付，而非流程合規

合規（Compliance）#

合規指的是遵守外部法律、法規或標準的要求，例如 ISO 9001、CMMI、以及產業特定的監管要求（如醫療器材的 FDA 規範）。

ISO 9001#

ISO 9001 關注的是品質管理系統（Quality Management System）。許多人誤以為 ISO 9001 要求大量文件和僵化的流程，但實際上 ISO 9001 的核心精神是：

• 組織必須定義自己的品質系統
• 必須遵循自己定義的系統
• 必須持續改善

這三點與 Scrum 的理念高度相容。作者本人就曾在使用 Scrum 的組織中成功通過 ISO 9001 認證。雖然文件化流程需要一些額外工作，但這主要是一次性的投入（加上計畫性的年度更新），對團隊的日常影響並不顯著。

Capability Maturity Model Integration (CMMI)#

CMMI 經常被視為重量級流程方法論，是敏捷開發的對立面。然而，多位 CMMI 原始作者認為這種「水火不容」的描述被過度誇大了。

• Mark Paulk（SW-CMM 首席作者）評估後認為 XP 部分或大量滿足了達到 Level 3 所需的 13 個關鍵流程領域中的 10 個
• Richard Turner（CMMI 原始團隊成員）指出 CMMI 與敏捷的差異雖然存在，但被「過度渲染」
• 多家公司已成功將敏捷開發與 CMMI 結合，例如 Philips Research 的 Erik Bos 和 Christ Vriens 領導的敏捷專案通過了 CMM 稽核，稽核員對「透明、易取得且一致的專案資訊」印象深刻

Systematic 是一家丹麥和英國的獨立軟體開發商，擁有超過 400 名員工。在達到 CMMI Level 5 約兩年後引入 Scrum，發現兩者互補良好——Scrum 將每個工作類別（缺陷、返工、總工時、流程開銷）降低了約 50%，同時維持了相同水準的流程紀律。

Scrum 與 CMMI 的結合被 Jeff Sutherland、Carsten Jakobsen 和 Kent Johnson 稱為「magic potion」——Scrum 確保流程被高效地實施並擁抱變化，CMMI 確保所有相關的流程都被考慮到。

實現合規的實用建議#

在理論和實務上都已確立 Scrum 與 ISO 9001 和 CMMI 相容之後，以下是在組織中成功結合兩者的具體做法：

• 在 product backlog 上投入足夠的心力：擁有良好維護、可逐步細化的 product backlog 對達成合規目標有顯著幫助
• 將合規工作放入 product backlog：如果需要產出某份文件或其他合規產出物，就把這項工作放進 product backlog，確保它不會被遺忘，同時讓合規成本可見
• 善用檢查清單（checklists）：檢查清單不應引入新的強制步驟，而是記錄團隊已經在做的事情，用來向稽核員證明活動確實在執行。例如 Systematic 使用一頁式的 story 完成檢查清單，從估算到整合都涵蓋在內
• 自動化：建置和測試自動化對任何 Scrum 專案都很重要，對有合規要求的專案更是加倍重要
• 使用敏捷專案管理工具：可追溯性（traceability）是大多數合規標準的重要考量，敏捷專案管理工具可以協助滿足這個需求
• 緩慢但穩定地推進：不可能一夜之間全面改造 ISO 9001 品質系統手冊，應該以增量方式逐步修訂，這正是 Scrum 團隊最擅長的
• 與稽核員合作：儘可能提前與稽核員溝通，非正式地討論你們的開發方式，請他們指出潛在的問題。選擇有經驗的稽核員，他們能理解流程看起來不同並不代表無法達成標準的目標
• 引入外部專家：如果你沒有通過認證的經驗，找一位有經驗的外部顧問；如果你不熟悉 Scrum，找一位有經驗的 ScrumMaster。兩方面的專業知識都不可或缺

總結#

Scrum 幾乎不可能在完全隔離的理想環境中實施。本章探討了三種常見的外部干擾：與循序式專案並存的需要、遵守企業治理體系的需要、以及符合法律法規或標準的合規需要。在每一種情況下，都存在務實的策略來讓 Scrum 與這些外部要求和平共存。下一章將繼續探討 Scrum 團隊如何受到組織內其他群體的影響——包括人力資源、設施管理和專案管理辦公室（PMO）。