版權所有© 2006-2018 Jeff Sutherland 及 Scrum Inc.
Scrum@Scale是Scrum Inc.的註冊商標。本指南基於署名-相同方式共享許可協議4.0發佈。(CC BY-SA 4.0)
簡體中文版原創翻譯團隊：申健 Jacky Shen (CST, CTC, Agile Coach); 王洪亮 Stephen Wang (CSP, Agile Coach); 李國彪 Bill Li (CST, Agile Coach);
簡體中文版授權譯文鏈接：http://www.uperform.cn/scrum-at-scale-guide-chinese/，歡迎轉載，請保留所有版權信息並遵循共享許可協議進行演繹。
Scrum@Scale指南之目的
最初在Scrum指南中描述的Scrum，是單個團隊進行開發、交付和持續發展複雜產品的框架。自誕生以來，它已經擴展到需要多個團隊合作來創建產品、處理過程、服務和系統。創建Scrum@Scale是爲了有效地整合這種新型的團隊生態系統，從而優化組織的整體策略。爲了實現這個目標，它利用一個自由擴展的架構建立起一個“最小可行的官僚機構”，自然地將單個Scrum團隊的功能擴展到整個組織中。
本指南包括構成Scrum@Scale框架的組件定義，包括擴展的角色、擴展的事件、企業級工件，以及將它們組織在一起的各種規則。
Jeff Sutherland博士基於Scrum、複雜自適應系統理論、博弈論、面向對象技術等背後的基礎原則開發了Scrum@Scale。本指南採納了許多有經驗的Scrum實踐者的輸入，基於他們的現場工作成果。本指南之目標是讀者能夠自行實施Scrum@Scale。
爲什麼要Scrum@Scale?
Scrum是爲單個團隊而設計，使其能夠在可持續的速率下發揮最佳生產力。在該領域中，人們發現隨着組織內的Scrum團隊數量增長，最佳輸出（可工作的產品）及那些團隊的速率會開始下降（比如由於跨團隊依賴和重複勞動等問題）。很明顯，爲了獲得線性的可擴展性，人們需要一個有效整合那些團隊的框架。設計Scrum@Scale是爲了利用自由擴展的架構達成這個目標。
通過使用無標度架構，組織的增長並不受限於以一組武斷規則所決定的特定方式；相反，它可以有機地基於自己的獨特需求而增長，並維持可持續的變革速度，從而可以被組織的成員們接受。
Scrum@Scale是爲組織的整體擴展而設計：所有部門、產品和服務。它可以被運用到不同領域，包括工商業、政府或學術界中的各類組織。
Scrum@Scale的定義
Scrum（名詞）：Scrum是一個框架，在此框架中，人們可以解決複雜自適應問題，同時高效並創造性地交付最大價值的產品。
Scrum指南是最小功能的集合，它通過徹底的透明性促進檢視和適應性，從而驅動創新、績效和團隊幸福感。
Scrum@Scale（名詞）：Scrum@Scale是一個框架，在此框架中，一致採用Scrum指南進行運作的Scrum團隊網絡可以解決複雜自適應問題，同時高效並創造性地交付最大價值的產品。
注意： 這些“產品”可以是硬件、軟件、複雜的集成系統、處理過程、服務等，取決於Scrum團隊所處的領域。
Scrum@Scale是: * 輕量的 – 最小可行的官僚機構 * 易於理解的 – 僅僅包含Scrum團隊們 * 難以精通的 – 需要實施一個全新的運作模型
Scrum@Scale是一個對Scrum進行擴展的框架。通過使用Scrum來擴展Scrum，它徹底簡化了規模擴展。它僅僅包含一些Scrum團隊，這些團隊通過Scrum of Scrums和MetaScrums進行整合。
Scrum@Scale本身基於組件的性質允許組織定製他們的轉型策略和實現方式。它使得他們獲得一種能力，可以將轉型的努力聚焦在他們認爲最有價值或最需要改變的領域內，然後再向其他方面取得進展。
在Scrum中，要注意區分對“What”與“How”的問責。在Scrum@Scale中也是一樣，那麼就要明確地理解權限和職責，從而消除浪費性的組織衝突，令團隊更容易達致最佳生產力。
爲了區分這兩個權限，Scrum@Scale包含兩個循環：Scrum Master循環（“How”）和產品負責人循環（“What”），彼此具有兩個相互接觸點。總之，這些循環造就了一個強大的框架，整合多個團隊朝着同一個方向而努力。
Scrum@Scale框架的組件
價值觀驅動的文化
除了區分對“What”與“How”的問責，Scrum@Scale還進一步在實證背景下創造價值驅動的文化，旨在建立健康的組織。Scrum的價值觀包括：開放、勇氣、專注、尊重和承諾。這些價值觀驅動着實驗性決策，而其取決於透明、檢視和調整這三大支柱。
開放支持着所有工作和過程的透明性，沒有這種透明度，就無法誠實地檢視並試圖更好地調整它們。勇氣指的是大膽跳躍，這是以創新方式更快地交付價值所需要的。
專注和承諾是我們處理工作職責的方式，把交付客戶價值作爲最高優先級。最後，所有這一切都必須發生在一個尊重每個人的工作環境中，否則不可能創造任何東西。
Scrum@Scale支持僕人式領導風格和基於意圖的領導力模型，以幫助組織蓬勃發展，1培養一個以可持續速率進行工作的積極環境，致力於將面向客戶價值放在努力的第一位。
開始使用Scrum@Scale
在實施大型團隊網絡時，針對少量團隊開發出一個可擴展的參考模型是至關重要的。當部署多個團隊時，Scrum實施中的任何缺陷都會被放大。
因此，第一個挑戰就是建立少量良好實施Scrum的團隊。這組團隊克服了那些阻礙敏捷性的組織問題，併爲Scrum創建一個在組織中衆所周知可運行的參考模型，將其用作整個組織範圍內擴展Scrum的模式。
隨着團隊參考模型的加速，延遲交付、產生浪費或妨礙業務敏捷性的障礙及瓶頸會變得明顯。消除這些問題的最有效方法是在整個組織中傳播Scrum，以便優化整個價值流。
Scrum@Scale通過使組織浸泡在Scrum中，並有機地分配速度和質量，從而實現了生產力的線性擴展，與組織的特定策略、產品和服務保持一致。
Scrum Master循環
團隊級過程
在Scrum指南中明確闡述了團隊級過程。它由三個工件、五個事件和三個角色組成。團隊級過程旨在：
-
最大限度地使完成和通過質量驗證的工作流動起來。
-
每個Sprint都提高一點點速率。
-
以一種可持續和豐富的方式運作。
整合如何做事(“How”) – Scrum of Scrums
需要協作的多個團隊組成一個“Scrum of Scrums”（SoS） 。SoS是“團隊之團隊”2，每天舉行一個規模化每日例會（SDS）事件，每個團隊派代表參加（通常是團隊的Scrum Master，儘管任何人都可以參加，也可以派多個人參加）。SDS的存在是爲了協調團隊並移除障礙以交付價值。
SDS事件反映了每日Scrum例會，優化了團隊網絡的協作和績效。另外，SDS：
-
少於15分鐘的時間盒。
-
每個團隊必須派代表參加。
-
是一個團隊代表們解決3個簡單問題的論壇：
我的團隊有什麼障礙阻止了他們完成他們的Sprint目標（或影響即將發佈的版本）？
我的團隊是否在做任何事情阻止了其他團隊完成他們的Sprint目標（或影響他們即將發佈的版本）？
我們發現了團隊之間的任何新的依賴關係嗎，或者找到了解決現有依賴關係的方法嗎？
這一組Scrum Master們本身就是一個Scrum團隊，負責在每個Sprint末尾從所有參與團隊那裏完全地集成出一個潛在可交付的產品增量。SoS團隊需要實時地應對所有參與團隊所提出的障礙。
SoS充當一個發佈團隊，必須能夠直接地向客戶交付價值。爲了能有效地做到這一點，它需要與Scrum指南保持一致；也就是說，要有自己的角色，工件和事件。這包括一個待辦清單梳理事件，他們在其中決定哪些障礙已經“準備好”被移除，最佳移除障礙的方式是怎樣的，團隊如何才能知道它是“完成”的。要特別關注SoS回顧事件，團隊代表們在其中分享各自團隊中的任何成功的學習收穫或流程改進，以便在SoS中的各個團隊能夠將這些實踐標準化下來。
爲了在每個Sprint結束時交付一個完全集成的潛在可交付產品，它需要具備所需的所有技能。它具有產品負責人代表來解決優先級問題。它可能需要經驗豐富的架構師，QA負責人和其他操作技能組。當啓動Scrum@Scale時，團隊們可能還不具備能夠支持持續部署的基礎架構。這會迫使SoS建立一個“集成團隊”或“發佈團隊”，以完成克服工程缺陷所需的額外工作。SoS被鼓勵去激進地解決集成和部署的障礙，因爲它創造了一個超高生產力的環境，例如，亞馬遜有3300個Scrum團隊，平均每秒部署超過一次3。
Scrum of Scrums Master (SoSM)
SoSM負責聯合團隊的發佈，並且必須：
-
使組織可以看到障礙待辦清單。
-
移除團隊自己無法解決的障礙。
-
對障礙進行排序，特別要關注跨團隊依賴和產品待辦清單的分配。
-
提升Scrum of Scrums的效果。
-
與產品負責人們密切合作，每個Sprint部署至少一個潛在可交付的產品增量。
-
利用產品負責人的發佈計劃來整合多團隊的部署工作。
擴展SoS
根據組織或實施的規模，可能需要多個SoS來交付非常複雜的產品。在那些情況下，可以從多個Scrum的Scrum中創建一個Scrum of Scrum of Scrums（SoSoS)。SoSoS是Scrum團隊的一個有機模式，可以無限擴展。每個SoSoS都應該有SoSoSM角色們，以及每個工件和事件的擴展版本。
擴展SoS減少了組織內部的溝通路徑數量，因此複雜性被封裝了起來。SoSoS與SoS的接口、SoS與單個Scrum團隊的接口，兩者都採用了相同的方式，從而實現線性可擴展性。
示例圖：
注意： 儘管Scrum指南將最優團隊規模定義爲3到9人，但哈佛大學的研究認爲最優團隊規模爲4.6人。4 針對高績效Scrum團隊的研究一再表明4或5人在一起工作是最優人數。對於SoS中的團隊數量，這種模式帶來的線性可擴展性是至關重要的。因此，在上圖和下圖中，選擇了五邊形來表示一個5人團隊。這些圖僅僅是示例，您的組織圖表可能會有很大差異。
高管行動小組
針對整個敏捷組織的Scrum of Scrums被稱爲高管行動小組（EAT）。EAT是SoS不能移除的那些障礙的終點站。所以，它必須由在政治和財務上得到充分授權的人們組成，去移除那些障礙。EAT的職能是協調多個SoS（或者SoSoS）。和任何Scrum團隊一樣，它也需要具備一個PO和SM。EAT最好也像Scrum團隊一樣可以每天見面。每個Sprint他們必須至少見一次面，並且具備一個透明的待辦清單。
例圖展示了1個EAT，正在協調分佈在5個羣組中的25個團隊
EAT的待辦清單及責任
Scrum是一個區別於傳統項目管理的敏捷操作系統。整個SM組織彙報給EAT，後者負責在組織內建立、維護和提升其打造的敏捷操作系統。EAT的角色是創建組織轉型待辦清單（一份經過排序的列表，包含待完成的敏捷舉措）並確保落地執行。例如，如果在一箇舊組織中存在一個傳統的產品開發生命週期，那麼一個新的敏捷產品開發生命週期需要被創建、實現和支持。通常它會比舊方法的更好地支持質量和合規事項，但是需要採納一套不同的規則和指南來實施。另外，組織發展和治理的很多方面也需要調優。
EAT對於整個組織的Scrum質量負責。它的職責包括但不僅於：
-
爲參考模型創建敏捷操作系統，以擴展到整個組織，包括提升敏捷性的企業運營規則，過程和指南。
-
度量和改進組織內的Scrum質量
-
構建組織內業務敏捷的能力
-
創建一個針對Scrum專業人士的持續學習中心
-
支持去探索新型工作方法
最後，EAT必須比照SoS，聚集PO羣體來建立和支持相應的的產品負責人組織，從而擴展PO職能。這些PO和關鍵干係人的團隊被稱爲MetaScrum。
Scrum Master組織的輸出/效果
SM組織（SoS、SoSoS和EAT）作爲一個整體來完成Scrum Master循環的組件：持續改進和移除障礙，跨團隊協調，和部署
持續改進和移除障礙的目標是：
-
識別障礙並轉化爲機遇。
-
維護一個安全的和結構化的環境以排序和移除障礙，並驗證和落實改進。
-
確保組織內的可見性以促成變革。
跨團隊協調的目標是：
-
協調多個關聯團隊間的相似流程。
-
管理跨團隊依賴以確保它們不會變成障礙。
-
使團隊規範和指南的保持對齊，以確保持續的輸出。
SoS的目標是像個發佈團隊一樣工作，因此產品部署也是其分內事，而決定發佈內容則是PO的分內事。因此，部署的目標是：
-
持續流動式地向客戶交付有價值的完成產品。
-
將不同團隊的工作集成到一個無縫的產品。
-
確保用戶體驗的高質量。
產品負責人循環
整合做什麼事(“What”) – MetaScrum
如果一組產品負責人有必要整合一個唯一的待辦清單，以供Scrum of Scrums來工作，那麼他們自己就形成一個團隊稱爲MetaScrum。每個SoS都有一個對應的MetaScrum。MetaScrum沿着同一路徑來對齊多個團隊的優先級，這樣他們就可以整合多個待辦清單，並和干係人保持一致以得到他們對待辦清單的支持。MetaScrum舉行一種規模化的待辦清單梳理活動。
-
每個產品負責人（或其代理）都必須參加
-
這個事件是領導者、干係人或其他客戶表達各自傾向的論壇
這個事件按需發生，每個Sprint至少發生一次，以確保一個“就緒”的待辦清單。MetaScrum的主要職能是：
-
創建產品的主要願景並且使之對整個組織可見。
-
和干係人保持一致以確保他們支持產品待辦清單的實現。
-
創建唯一的排序的待辦清單；確保規避了重複工作。
-
針對SoS內所有團隊創建統一的“完成的定義”。
-
消除由SoS提出的依賴。
-
生成一份整合的發佈計劃。
-
監控能夠洞察產品的度量，並基於其進行決策。
類似於SoS，多個MetaScrum本身也作爲Scrum團隊來運作。所以，需要某人來扮演SM來保持團隊的正常溝通。他們還需要唯一的人來負責協調，使得MetaScrum覆蓋的所有團隊創建出唯一的產品待辦清單。這個人被指定爲產品總負責人。
產品總負責人(CPO)
通過MetaScrum，產品總負責人與各個團隊的產品負責人來協調優先級。他們以干係人以及顧客需求來對齊待辦事項的優先級。類似於SoSM，可以是某個團隊的PO來扮演這個角色，或者是某個人全職擔任這個角色。他們的主要職責和普通PO是一樣的，但是在擴展的時候：
-
建立整個產品的戰略願景
-
創建唯一的、排序的待辦清單，包含將要被所有團隊交付的價值。
-
這些事項對於一個團隊的PO來說可以是更大規模的故事。
-
與相應的SoSM緊密工作在一起，以便有效地部署MetaScrum團隊創建的發佈計劃。
-
監控客戶對產品的反饋並相應地調整待辦清單。
擴展MetaScrum
如同SoS可以增長到SoSoS，MetaScrum也可以用同樣的機制進行擴展。沒有專門的術語對應這些擴展單元，他們的CPO們也沒有專門的擴展頭銜。我們鼓勵每個組織發展自己的方式。下圖中，我們選擇了再增加一個“總”以突出那些PO。
一些例圖：
注意： 如上所述，這些多邊形代表着理想規模的Scrum團隊和MetaScrum。這些圖僅僅作爲例子，你的組織圖可能會顯著不同。
高管MetaScrum（EMS）
MetaScrum使得PO及其對應的SoS能夠以一種網狀設計進行無限地擴展。整個敏捷組織的MetaScrum是高管MetaScrum。EMS擁有組織的願景並設立整個公司的戰略優先級，使各個團隊圍繞共同目標來對齊。
例圖展示了1個EMS，正在協調分爲5個組的25個團隊：
產品負責人組織的輸出/效果
PO組織(各種MetaScrum，CPO和高管MetaScrum)作爲整體來工作以滿足產品負責人循環的組件：戰略願景、待辦清單優先級排序、待辦清單分解和梳理，以及發佈計劃
設置戰略願景的目標是：
-
透過一個共享的路徑清晰地對齊整個組織。
-
清晰而有力地表述組織爲什麼存在。
-
描述組織會做什麼從而調度其關鍵資產以支持其使命。
-
持續更新以響應快速變化的市場情況。
待辦清單優先級排序的目標是：
-
針對待交付的產品、功能和服務，識別出一個清晰的排序。
-
待辦清單的排序反映了價值創造、風險緩解和內部依賴。
-
在分解和梳理待辦清單之前，先在整個敏捷組織內對高層舉措進行排序。
待辦清單分解和梳理的目標是：
-
把複雜項目和產品分解爲獨立的可工作元素，每個元素都可以被一個團隊在一個Sprint中完成。
-
捕獲和提煉涌現的需求和客戶反饋。
-
確保所有的待辦事項條目是真的“準備就緒”以便被各個團隊拉取。
發佈計劃的目標是：
-
預報關鍵特性和能力的交付
-
向干係人溝通交付預期
-
按需更新優先級排序
連接SM與PO循環
理解反饋
反饋組件是PO和SM循環所交叉的第二個點。產品反饋通過調整產品待辦清單來驅動持續改進，發佈反饋通過調整部署機制來驅動持續改進。獲取和分析反饋的目標是：
-
驗證我們的假設。
-
理解顧客如何使用產品和與產品互動。
-
捕獲新特性和新功能的創意。
-
定義針對已有功能的改進。
-
朝着產品/項目完成的方向更新進度，以更好地規劃發佈計劃並與干係人對齊。
-
識別出部署方法和機制的改進項。
度量與透明性
徹底的透明性是Scrum最佳狀態運作的本質，但是隻在能夠擁抱Scrum價值觀的組織中可行。它使組織能夠誠實地評估進度並檢視和調整其產品及過程。這是Scrum指南中記載的Scrum的實證主義本性的基石。
SM和PO循環各自需要的度量會分別由SM和PO組織來決策。對於兩個特定組織以及那些組織中的特定功能來說，度量也可能是唯一的。Scrum@Scale並不要求任何特定的度量集，但是它推薦了最低配置，即組織應該度量如下方面:
-
生產力 —— 例如，每個Sprint交付的可工作產品的總量變化
-
價值交付 —— 例如，單位團隊工作量能夠帶來的業務價值
-
質量 —— 例如，缺陷率或者服務宕機時間
-
可持續性 —— 例如，團隊滿意度
設置這些度量指標以及透明性是爲了：
-
提供適當的上下文給所有的決策者——包括團隊成員在內——以做出優秀的決策。
-
儘量縮短反饋週期以避免矯枉過正。
-
最小化地要求團隊、干係人和領導者進行額外投入。
關於組織設計的一些說明
Scrum@Scale自由擴展的本性，允許將組織設計爲一個個組件，就像框架本身一樣。它允許重新平衡和重構團隊，從而響應市場。隨着組織的增長，分佈式團隊帶來的益處可能也很重要。一些組織在無法獲取人才的時候則通過外包開發來擴展和簽約。Scrum@Scale展示瞭如何擴展這種情況，同時避免過長的延遲時間、妥協的溝通以及低劣的質量，使得組織在規模上和地理分佈上兼具線性擴展性。
客戶關係，法務/合規、人力運營也包含在這裏，因爲他們是組織中必要的部分，他們將獨立於Scrum團隊而存在，其他人將依賴於他們。
關於EAT和EMS的最後一點：在這個圖中，由於有2個成員同時存在於這兩個團隊中，所以兩者看起來是重疊了。在非常小的組織或者實施中，EAT和EMS可以由同一批人組成。
結束語
Scrum@Scale是爲了擴展生產力而設計的，使得整個組織在一個顯著改善的工作環境中能夠高質量地做到事半功倍。在大型組織中適當的應用本框架可以削減產品和服務的成本，並且提升質量和創新。
Scrum@Scale是爲了讓Scrum浸透組織而設計的。所有團隊，包括了領導層、人力資源、法務、諮詢和培訓，以及產品和服務團隊，他們在精簡和提升組織的時候都採用同一種Scrum風格。
良好實施的Scrum可以運作起整個組織。
致謝
我們感謝IDX創建了Scrum of Scrums，它允許Scrum擴展到上百個團隊，6感謝PatientKeeper創建了MetaScrum，7它使得創新產品能快速部署，感謝OpenView Venture Partners將Scrum擴展到整個組織。8 我們珍視來自英特爾的二萬五千多人實施Scrum的輸入，教會了我們——“沒有事物能擴展”——除了一個自由擴展的架構，還要感謝具有最大的Scrum團隊的SAP產品組織，教會了我們讓2000多個Scrum團隊一起工作的必要因素就是讓管理層參與到MetaScrum中。
敏捷教練和培訓師們與Jeff Sutherland一起工作，在亞馬遜、GE、3M、豐田、Spotify和很多其他公司實施了這些概念，這對於在更廣範圍的不同領域的公司中驗證這些概念是非常有幫助的。
最後，Avi Schneier和Alex Sutherland制定和編輯本文的工作是價值無量的。
歡迎喜歡搞敏捷項目管理的同仁們，加微信多交流！
