最近社區討論規模化敏捷的話題不少，甚至會在幾個大規模敏捷框架Scaled Agile Framework®（SAFe®），大規模Scrum（LeSS）和規範化敏捷交付（DAD），Scrum@Scale，Nexus 的選擇中糾結和爭論。
這裏我們一起探索規模化敏捷的核心是什麼，如何在實踐中指導我們探索出最適合自己組織的規模化敏捷的框架。
首先我們定義什麼是規模化敏捷？本文我們討論的是兩個以上的Scrum團隊在遵循敏捷價值觀和原則下圍繞一個整體產品( a whole product)或服務如何快速交付價值給最終客戶。規模化敏捷是敏捷方法超越團隊級別，基於一個產品或者產品投資組合級別上的擴展。這裏的前提是一個Scrum團隊是組織敏捷和進化的有機生命單元。我們以產品的視角來討論，避免用項目一詞，項目是交付產品的一種組織資源的臨時形式，產品的生命週期要遠遠大於項目。
敏捷（agile）的廣義定義：組織響應市場和客戶變化的敏捷度和靈活性。我更喜歡用adaptive來詮釋敏捷。Scrum是一個最精益（lean and barely sufficient) 的團隊工作的框架。大寫的Agile代表敏捷宣言。
我們一起看看多團隊會給我們帶來什麼問題？首先，想到加人會帶來的複雜性，人是複雜的有思想和價值觀的個體。加人帶來的複雜性包括：角色，流程，結構，信息的流動即溝通成本, 比如溝通的管道和使用物件（Artifact）的增加等等。
所以，規模化敏捷的首要原則：First rule of scaling agile - DON'T do it
規模化敏捷的本質是減少複雜性or 瘦身（De-scaling）, 增加角色和崗位，組織架構的層級，重的流程， 都會阻礙我們價值交付的速率。通過局部優化解決局部(local)問題的方案，通常會成爲組織（global）問題的根本原因。規模化敏捷不是增加複雜性。
“Simple, clear purpose and principles give rise to complex and intelligent behavior. Complex rules and regulations give rise to simple and stupid behavior.” – Dee Hock, CEO Emeritus VISA International
對於複雜的大型產品（比如電信，保險，銀行等行業），如果我們確實需要通過增加人，但要考慮團隊有機的增長。而不是一味簡單的做加法。
規模化敏捷帶來的第二個挑戰是，依賴問題。依賴有多種：多個產品之間的依賴，產品外部和內部的依賴，團隊的依賴，包括能力的依賴。文章稍後我們討論如何減少依賴。
因此， 我們在引入和定製規模化敏捷的方法時，要時刻記住我們的目的什麼？如何減少複雜性，如何避免依賴關係，而不是簡單的照抄和copy model, one size can NOT fit all. 同時要不斷通過檢視(inspect)和調整(adapt), 採取回顧持續改進的方法， 探索出最適合自己組織的規模化敏捷的框架，也不要簡單的copy其它同事和部門的最佳實踐。最佳實踐是非常危險的。
規模化敏捷的目標是清晰的：用盡可能最好的方式鞏固多個Scrum團隊的成果(outcome)來擴大過程迭代（Iteration）和產品增量(Increment) 交付的規模。
這意味着我們至少需要建立一個基本的跨越多個團隊的流程框架，並且持續不斷的迭代改進。這個規模化的框架應滿足和遵從：
i. 簡潔(Simplicity)的原則，不能增加複雜性，對待複雜問題不能依靠複雜的套路來解決，增加角色，流程，結構，層級，物件都會使問題更加複雜化，要遵從Scrum的框架。（Scrum is a basis）
ii. 需要我們組織的身體力行，進化出最適合的多團隊以上的組織設計架構；最大化聚集多個團隊一起工作的價值流；沒有現成的菜單可以照抄。(Learn by doing)
iii. 多個敏捷團隊的能量，熱情，士氣, 幸福感(happiness) 依然像單個Scrum 團隊一樣得到最大釋放，而不是被壓制；（Morale is a multiplier for velocity, by Joe Justice）
iv. 管理層和領導力的重新定義和定位，敏捷文化驅動組織最大化價值的產生。（agile leadership and culture）
規模化敏捷宣言(Agile Scaling Manifesto)：
1. 切斷依賴優先於管理依賴 （cut dependency over dependency management）
2. 減少複雜性優先於規模化敏捷的框架 (reduce complexity over scaling framework)
3. 拓展能力優先於團隊協作 (build competence over coordination )
4. 做好Scrum 優先於規模化 (do better Scrum over Scaling)
規模化敏捷產品開發， 有內部依賴和外部依賴。外部依賴則在產品以外，比如硬件組件或依賴其它產品。內部依賴，在產品內的非特性團隊， 比如組件團隊（undone work）或集成團隊。 對於產品內部的依賴，PO需要考慮如何拆分產品功能複雜性降低。特性團隊的設計會消除依賴，對於共享代碼的團隊，其實不需要管理內部依賴（LeSS 有詳細的闡述）。循環型依賴（Circular Dependency） 50%的時間會耗費在溝通上。作爲產品負責人始終關注依賴關係，儘早識別依賴關係，與所有人合作尋求幫助移除依賴。
一個壞消息是，“管理依賴”的文化將會阻礙基本解決方案的實施。最小化依賴關係的最佳方法是切除(cut)依賴關係，即沒有依賴關係。通過以下方法我們徹底消除依賴：培訓和拓展技能；複雜的架構簡單化；減少組件的數目；組織設計並組建跨組件和跨職能的Scrum團隊（Less 定義特性團隊）。
作者建議，組織在規模化敏捷的實踐中要遵循的三個基本原則：
第一條原則：
自治團隊單元是組織進化的硬核 -- 培育小而穩定的踐行Scrum的團隊
“small, autonomous, cross-functional teams work best vs component team”
組織不是通過簡單擴大規模來處理大的複雜的問題，而是將複雜的問題分解成一個個小的部分，由小的團隊來處理。特別對於大規模複雜關鍵的產品，自組織團隊和團隊單元（Team based organization）的建立和輔導很重要。
任何一個團隊必須歷經塔克曼（Tuckman model）團隊發展階段模型的四個階段：形成期、震盪期、規範期、成熟期。團隊進入高績效的狀態，需要花費6-12月的時間和相當大的努力。我們傳統的做法是：項目結束，把老團隊拆散，新項目開始我們再重新組建新的團隊。我們把人當作資源，可以替換也可以隨時plug-in。 卻忽略了人是有學習能力的，每個個體是一個複雜的自適應系統，有自己的價值觀和理想。個體之間需要時間與集成和融合， 成爲真正的團隊。
因此，我們需要把錢花在組建一支穩定的團隊上，他們是專注於某個產品的一個穩定單元，而不是項目完成之後解散團隊。我們要創建跨職能團隊，團隊成員來自不同的職能部門：包括業務分析師、設計師、開發人員、測試人員。核心團隊成員都是全職的（至少80%或者更多時間）投入到產品中。工作應該儘可能由小型的、自主的、跨職能的團隊在短週期內完成相對較小的最高價值工作，並從最終用戶那裏獲得即使持續的反饋。LeSS 中明確定義了特性(feature)團隊，特性團隊擴展地圖。
幫助成就自組織敏捷團隊的這個管理框架就是Scrum，也是企業導入敏捷思想，團隊落地敏捷的簡單遊戲規則. Scrum框架“進化價值交付”的兩個關鍵特徵：
(1) 增量產品交付(Incremental Product Delivery)：以一種被叫做迭代 (Sprint)的小塊的形式將產品交付到市場；
(2) 過程迭代(Process Iteration)：很短時間盒內以小顆粒度的工作級別執行整個軟件生命週期中的計劃，設計，開發，測試，發佈這些流程，重複。
擔當這個框架的管理者和引導者的關鍵角色就是ScrumMaster。Scrum 定義了一套簡單的遊戲規則 （有點像 chess game），一旦一個組織內團隊在一段時間內不懈地追求和實踐Scrum，擁抱敏捷思維，就會對組織產生潛移默化的影響：組織做計劃的方式，人們工作的方式（比如做決定和解決衝突），領導力的方式，從本質上改變了原來的遊戲規則。一個高效自治 （self-governing） 組織單元在漸進形成。從組織的角度來看，工作單元變成了團隊，而不再是個人。通過在短週期內工作，團隊很容易調整方向。
我們認爲：穩定的小團隊構成了規模化敏捷組織交付價值給客戶的基本單元（basic building block）。這樣的團隊具備精益創業型（Lean+ Entrepreneurship）的特質。以Scrum values 作爲core的工作文化，，一個充滿激情，學習型的，有機的，自適應生命體。ScrumMaster 正是打造這個產品（視團隊爲產品）的敏捷教練。敏捷管理者充分激發知識型員工的才幹和能力，把自己看作賦能者（enabler）而非控制者，並身體力行。
Scrum剛開始就非常關注團隊的設計和結構變化，Scrum的結構往往會迅速影響組織的文化。沒有建立和打造這樣的團隊作爲基石，規模化敏捷都是空中樓閣。
第二條原則：
以精益思想(Lean Thinking)爲基石的實踐
“Keep your organization as small as possible and focus on eating the elephant piece by piece. And only eat the really delicious parts of it.”
當下面臨的這個時代，我們再也不能以組織內部的規定和流程限制爲藉口，去搪塞和操縱客戶。客戶是我們的boss, 企業的每個個體都應該審視他們所做的每一份工作是否真正給客戶帶來價值，時刻銘記減少不增值(non-value added)的活動。
我更喜歡嘗試用精益思想五個核心原則，來一起探索規模化敏捷:
1.以產品來定義價值（identify value）。客戶價值是至高無上的。以聚焦於給客戶和用戶帶來附加增值和創新爲組織的目標，而非以短期盈利爲目標。LeSS 中對產品定義有專門的解釋。
2.爲每個產品識別價值流 （map value stream）。尋求從最初構想到產品交付的端到端的完整步驟，以交付客戶價值，同時要識別不同價值流之間的依賴。
3.確保價值的流動不被打斷(create flow)。 通過識別問題來改進我們的流程；減少或消除阻礙價值流動的瓶頸，去除浪費。
4．客戶從交付團隊拉取價值(establish pull system).。靠保持最小數量的庫存來進一步減小浪費和提高生產力，優化團隊的工作方式。
5. 追求完美 (seek perfection)。團隊和管理者堅持不懈的尋求改進.
我們如果從精益思想的原則出發，嘗試探索一個組織內部的規模化敏捷的基本框架，比如價值流的管理，如何讓價值能快速流動起來，並生成關鍵實踐。幾個實例：
用戶故事流的方式。一個核心理念就是連續流（flow）。在精益組織裏，通過單件流或連續流的方式，將全面（holistic） 正確的產品，端到端的無中斷地，快速交付客戶。這樣啓發我們：敏捷團隊在定義，開發，整合和部署產品時，通過將產品分解爲功能特性或用戶故事流的方式。一個功能特性 (feature)或者更細粒度的“用戶故事”代表着“單件”的商業價值，需要從客戶端以最快的速度無中斷的通過開發，測試和部署流程迴流到客戶端。(end to end).
以產品的探索（product visioning or discovery）爲例, 要經過產品願景，用戶畫像，產品路線圖，史詩級的用戶故事Epic到 迭代級的story （sprint-able），商業畫布驗證商業模式，設計實驗或MVP 驗證具體的想法，精益創業(lean start-up)的理念，用戶故事地圖，影響地圖等工具會幫助我們做產品的探索，然後採用Scrum 的框架幫助我們做產品交付(delivery), 這些技能我們都會在CSPO課上討論和操作，這裏不在累述。
那麼，組織如何去管理多個產品呢？我們定義了投資組合（Portfolio） backlog, 這個backlog的條目可能是不同的產品，或者是產品增量（比如一個發佈），或者項目（有些組織習慣用項目來規劃工作）。注意到，在敏捷的語境下，我們用產品來替代項目，敏捷中我們很少提及項目集（program）的概念。但有產品Portfolio的概念。參看下圖：
任何一個組織的資源和容量(capacity)都是一對矛盾體，組織需要建立Portfolio planning/management的策略。比如新的產品滿足什麼條件能夠拉入Portfolio backlog，產品優先級的排序考慮的要要素。
遺憾的是，一些組織在產品的Portfolio backlog的管理方面沒有明確的原則和策略。Ken Rubin的《Scrum 精髓》有專門的章節論述他建議的11條策略管理Portfolio backlog。
接下來我們聚集到一個點，討論如何通過限制在製品（WIP）數量來加速價值的流動。
“Develop and deliver in small batches. Focus on finding the true MVP by relentless customer research”
當一個共享的稀有資源的利用率越高，生產速度就越慢。排隊理論中的Little法則：
生產週期 = 在製品數量WIP/平均完成速率
因此，要想讓產品交付的更快，減少在製品數量（也就是進行中的條目），或增加完成的速度。加快速度是一件相當困難的事情。所以，要縮短生產週期，有效做法是減少在製品的數量。
我們在規模化敏捷的實踐中要考慮如何應用這一原則，即讓團隊聚焦在更少的在製品上，
這一思想可以從產品投資組合（Portfolio）的規劃到每天的工作任務中。按四個維度來討論：
(1) 限制在製品（WIP）數量的在產品Portfolio Backlog層面的應用：
終止殭屍項目。殭屍項目指的是不斷延期，團隊士氣低落，花費很高, 結果未卜的項目。經常聽到組織有的項目做了兩年了，每天忙碌，發佈遙遙無期。殭屍項目的終止是很難的，人們沒有勇氣面前現實，心存幻想。好多組織新上任的CEO第一件事就是砍掉殭屍項目。
創建一個有優先級的產品Portfolio（投資組合）待辦列表。就像團隊給產品待辦列表裏的用戶故事排優先級一樣，我們需要按照商業價值給產品排序，形成一個投資組合待辦列表。這樣，我們的團隊就可以從列表裏選擇最高優先級的條目。團隊只專注在一個產品上。只有當團隊發佈這個產品後，他們才能從待辦列表中拉出下一個高優先級的產品。當然組織也會根據它的capacity來限制產品在製品（WIP）數量，平行啓動的產品數量。團隊的可用性來決定啓動相應數目的產品或條目，合理平衡。
減少產品啓動的數量，加速已啓動產品的完成 （stop starting, start finishing）。如果一個產品開始出現不好的跡象，在變成殭屍項目前要果斷叫停。這樣做的目的是創造一個重新排列的動態的產品投資組合列表，更好的平衡利益干係人的需求，匹配團隊的交付能力。控制投資組合中進行中的產品數量，即限制產品在製品（WIP）的數量。
(2) 限制在製品（WIP）數量在Product backlog級別的應用：
把大的產品分解成小的增量，小批次規模 （small batch size）,比如最小可投放市場的特性（MMF）。我們可以把產品功能按MMF的增量來分次發佈，儘早將價值投放到終端用戶手中。減少在製品數量，縮短交付週期，敏捷鼓勵儘早地發佈，頻繁地發佈(發佈的cadence)。
在批次規模大小上，我們可以通過用戶故事地圖的工作坊形式共創（團隊，PO+干係人，客戶等）來管理和控制發佈層次。用戶故事地圖把發佈計劃和迭代計劃打通，我們和客戶一起確保系統功能被明確定義，發佈到每一個小的批次中。在發佈層面，每個功能特性批次儘量的小，功能特性(feature)拆分不超過3周的用戶故事，即使是大的Epic，每個發佈也不應該超過3個月。度量一個史詩級用戶故事的平均時間週期，來管理一個髮布進展。一個作爲產品負責人(PO) 能管理的Product backlog條目上限是100-300個, PO必須做出決定不做什麼。PO的工作是通過最小化輸出（output）來最大化成果（outcome），PO 要有勇氣學會say No。
與傳統的做法正好相反，團隊成員精力不會被分散在多個項目上，團隊專注一個產品，一個小批次規模的增量發佈，不會被意外需求或緊急事件打斷。如果需要快速轉變， PO和干係人會快速做決定。預算的機制也是incremental funding。
(3) 限制在製品（WIP）數量在迭代的Spring Backlog層面的應用：
在批次規模大小上，體現在控制迭代開發層面。一個Sprint或迭代中的每個用戶故事不應該超過3天的工作量，迭代週期控制在一週或二週。LeSS 推薦一個迭代一個團隊專注4個PBI （WIP）。
隨着團隊的成熟，建立起自己穩定的交付速率（Velocity）。我們也可以度量用戶故事的流入到在生產線上發佈的平均lead time。
鬆弛度（slack time）的引入。滿負荷或過載的系統所產生的負面效應就如同高峯時的高速公路。按照隊列理論，當更多個體進入隊列時，系統的處理機能就會下降甚至崩潰。系統必須保持一定的鬆弛度。我們 Sprint計劃會議要避免超載，即團隊不超過80%的capacity，保持20%的團鬆弛度。Google， Atlassian，Spotify, 留有20%創新。允許團隊成員20%的時間自己支配，這樣留有的冗餘讓價值能流動起來，而且會創造意想不到的額外價值。
(4) 限制在製品（WIP）數量在每天的Task board層級的應用：
避免多任務並行，當我們每次致力於一件或者兩件事情時，生產效率最高。敏捷團隊應專注於單一產品增量發佈的同時，在迭代中團隊專注一個PBI (Swarming)甚至Mob Programming，對團隊成員而言避免多任務並行，任務的切分也不要大於一天。番茄時間工作法對個人時間管理非常有幫助。
總之，規模化敏捷的探索，我們要堅持Inspect and Adapt的理念, 持續迭代。學習是通過持續的個體反思，團隊集體回顧，依靠環境（包括客戶的市場）的反饋來實現的，而改進則是通過對策略和規則的增量調整來實現的。
現實中，我們面對着臃腫的組織和複雜的流程， 我們開發人員到底離客戶有多遠？我們的管理層與開發團隊是否被隔離開來了，管理層更喜歡看報告，白天“浸淫”在一個接一個的會議中，週末郵件發號施令。規模化敏捷，邀請管理層要改變工作作風，去現場（Gemba）檢查（Inspect），並實施改善 （Kaizen）以期持續改進。
現場（Gemba）日語意思是“真正的地方” （work place）。它指的是創造價值的地方; 比如我們敏捷團隊所在的地方和客戶現場。問題在現場表現得最明顯，通過親自觀察現場正在進行的工作，更容易找到最佳的改進方法。比如走動管理是一項活動，管理層到進行實際價值交付的工作前，發現浪費和改進的機會。LeSS 中，專門設計了Sprint overall retrospective (回顧會)，有管理層，PO， SM，團隊代表參加， 從組織層面來看障礙。
第三條原則：
組織是以多團隊網絡湧現出來的動態的有機體
“The Task Force was no longer a rigid machine, it had become ‘an adaptable, complex, organism’, constantly twisting, turning, and learning to overwhelm its protean adversary” – from Stephen Denning
一個敏捷團隊在高績效的狀態下運行良好，達到其規模（size）限制，比如說團隊有9名成員（我傾向一個團隊不要超過6人），我們不會繼續擴大現有團隊的規模，需要構建另一個新的團隊。
爲了保證新團隊正確建立，一個小的種子組可能會從原團隊中脫離，形成新團隊的核心。這個種子確保把原團隊的願景和文化完整地傳播給新的團隊。這樣避免了團隊臃腫，也確保團隊的敏捷性。2010年3月我在上海開始組建Endeca海外的第一個Scrum 團隊，就採用這種有機增長的模式，2012年底Endeca高效敏捷的中國團隊（共45人）被甲骨文收購。
如何確保團隊結構靈活以適應快速的變化呢？利用特性團隊的變化來實施Jeff De Luca所創立的特性驅動開發（FDD）。核心組保持一致性和連續性，團隊中的一些成員的“位置”，會根據交付的功能不同，在不同的“Sprint”中被替換。
爲了在團隊之間建立聯繫，Johanna Rothman推薦了一種網絡非等級制度。小團隊網絡，隨着多個團隊的形成，我們希望這些網絡能夠在團隊中有機的浮現，不是自上而下支配， 而是自覺自願的呈現。比如，團隊成員可以關聯在某個共同的規範領域中，專注於改進自動化測試的工作組中，他們可以關注持續改善小組中， 建立不同的社區實踐（CoP）。
“對於一個運轉的大型組織而言，它必須表現的像個具有團體相關性的小型組織羣一樣” （E. F. Schumacher）。這樣的組織羣體具備複雜自適應系統（CAS）的特性，通過簡單而清晰的使命，目標，原則和規則來維持和管理這樣的多團隊網路。有機體是一個透明的，動態進化的生態系統，它不是一成不變的。 組織像一個系統一樣運作，敏捷實踐者和團隊都將組織視爲一個流動的、透明的以團隊爲單元的網絡，這些參與者爲了客戶的共同目標而協作。LeSS, Spotify, Holocracy （合弄制）, Scrum@Scale 和Team of Teams 等框架，都是團隊間的工作關係網絡的不同設計和呈現形式。
當整個組織真正擁抱敏捷時，組織就不再像一艘巨大的軍艦，而更像一支由小型戰隊組成的快艇。
這樣的組織網路有機體，呈現出的狀態：
（1）通過結構化的、迭代的、遵從Scrum框架的實踐（Scrum as a core approach）
（2）整個組織，每個人，都致力於爲客戶提供更多的價值, 聚焦於客戶 (the law of customer)
（3）團隊之間共享,包括信息的共享，能力的共享，成果的共享。爲實現一個有機的規模化敏捷組織，需要組織中每個人的主動性以及智慧(而非僅是管理者的智慧)。敏捷團隊採取主動，並與其他敏捷團隊交互解決常見的問題。創意可能來自組織的任何一個地方，管理者認識到能力存在於整個組織中。(The law of network)
（4）日常工作中尊重、平等、協作的工作氛圍和環境；體現產品、服務、工作方法的透明和持續改進的價值觀；開放的、對話式的，而非由上而下、層級制的溝通，而非官僚體制來指派工作。(agile culture and leadership)
一個真正的敏捷組織是需要組織機制，組織文化來保障。而改變一個組織的文化，始於Leadership 和敏捷領導力。比如，管理層首先要放棄權力，團隊有更多的自主權和決策權。這些話題我們在CAL課程中有討論。
小結：
有了這些核心原則指導下的實踐——培植小而穩定的踐行Scrum的團隊, 通過限制在製品（WIP）數量來實現價值流管理，建立並演進多團隊間的動態關係網絡， 我們以此爲基礎，就會探索和構建出一套以《規模化敏捷宣言》爲指導的適應組織自身的規模化敏捷框架。
Jim Wang
寫於2020年2月27日疫情期間
參考資料：
(1) The Age of Agile: How Smart Companies Are Transforming the Way Work Gets Done
by Stephen Denning (Author)
(2) https://blog.odd-e.com/yilv/2017/06/team-first-or-organization-first.html
(3) Team of Teams: New Rules of Engagement for a Complex World
by Stanley McChrystal (Author) etc.
(4) https://www.scrum.org/resources/blog/eliminate-dependencies-dont-manage-them
(5) 敏捷理念在生產管理中的嘗試， Dr Sven Fang
(6) “Scaling Agile A Lean Jumpstart” Sanjiv Augustine
近期必讀：
小說體敏捷/DevOps轉型教科書
和實戰經驗分享
購書指南
—
紙質書、電子書在京東、噹噹、亞馬遜、微信讀書等渠道已全面上架，搜索關鍵字“獵豹 敏捷”即可找到。點擊閱讀原文可直接購書。
有聲書已登錄喜馬拉雅、微信讀書，適合路上聽書的你。
關注公衆號看其他原創作品
敏於思 捷於行
堅持每週輸出一篇高質量文章
覺得好看，點個“在看”或轉發給朋友們，歡迎你留言