Scrum 是目前全球最流行的敏捷實踐，是針對複雜性工作團隊交付價值的一個框架，在 Scrum Guide 中沒有具體 Mutiple Scrum Team 的應用，在真實的組織工作場景中，我們往往面臨的是 Mutiple Scrum Team 共同交付同一個產品，Mutiple Scrum Team 增加了工作的複雜性。
多團隊 Scrum 產品交付 Workshop
參加了一場由 Jim Wang 和 Bob Jiang 舉辦的 Multiple Scrum Team 產品交付工作坊，時間長度為三小時。
基於一個 Scrum 的框架下，如何減低複雜度和溝通成本，以及 Scrum 會議要如何組織，透過這個工作坊我們可以建立一個屬於我們自己團隊特色的一個工作流程。
遊戲的規則大致上是這個樣子的：
- 所有的 scrum team 彼此之間是合作關係，而不是競爭關係。
- 我們的產品是個叫做 ”My City” 的城市，裡面包含一些具有特色的建築物。
- 主要採用的材料是樂高元件，當然，在必要的時候可以用其他的工具做輔助，譬如用麥克筆畫畫。
- PO 對於這個產品負責，因此擁有產品相關的最後決定權。
- PO 會參與整個開發流程、回答問題、給予回饋。
首先，全部的人分成四個 Scrum Team。給大家五分鐘的時間，大家覺得什麼東西應該要在 ”My City” 裡面，一個需求用一個 Story Card 寫下來。譬如說城市裡面需要有公園、道路、住宅、警察局、醫院等等。
接著，PO 收集所有的 Story，然後根據優先順序做排列，建立我們的 Single Product Backlog。通常這樣的活動，我們在組織裡會舉辦一個 Initial Story Writing Workshop，請大家一起發想有哪些需求需要放進 Product Backlog 裡面。
接著，我們會舉辦 Product Backlog Refinement (PBR)，請每個 Scrum Team 幫忙拿一些 Story 回到自己的座位，然後開始找 Requirement Owner 釐清 Story 內容，然後把 AC (Acceptance Criteria) 寫在便條貼上。如果 AC 討論完成以後，把便條貼貼在 Story 的下方。Requirement Owner 是指這個 Story 是誰提出的，可能是 PO 也可能是在場的同學。
每個 Story 都完成 AC 以後，我們要進行估點的活動，這裡採用的是 Affinity Estimation，大家把 Story 估出來的點數，貼在牆上相對應的地方。在貼的過程中，可以跟其他的 Story 比較相對大小。在 Scrum 裡面，每個團隊的 Story Point 基準點不一樣，團隊心中的 5 點，和另一個團隊心中的 5 點，定義其實可能是不一樣的，藉由這個活動，可以慢慢讓多個團隊慢慢對於點數的定義，趨近於接近。
當大家都把點數估計完成以後，PO 會把這些 Story 恢復成依造 Priority 的順序，因為 PO 目前已經得知每個 Story 大小的關係，PO 可以自己，或者邀請在場的各組代表，再討論一次優先序，看看有沒有需要重新調整。
我們在遊戲的當下，有把第 10 名的養老院，丟到最後面，因為我們假設 My City 是一個新的城市，裡面的居民應該都是比較年輕的，養老院相對不是那麼重要。第 1 名和第 7 名的一層建築，是否可以擺在一起，由團隊一起完成，但是 PO 拒絕了這個提案，因為居民是慢慢移入的，一開始只需要一個一層建築，太多的一層建築，PO 認為沒有價值，所以維持原來的順序。
總結，排序優先序其實是可以由團隊一起完成，不一定只由 PO 一個人完成。 PO 會先分享目前的優先序，之後會請各組從高優先序開始，讓四個團隊拿到座位上開始生產。
我們準備要開始 Sprint 1 的 Planning Meeting，因為 Product Backlog Item 太多，所以 PO 先留下了前面的 12 個，希望團隊可以幫忙完成。
接著我們會進行三次的迭代。進入開發的時候，同學們瘋狂的尋找適合的樂高元件。
這個是我們團隊的 Sprint Board，記錄我們的團隊開發狀況。
Sprint 結束以後，進行多團隊評審會議，看看大家每個迭代有什麼產出，以及讓 PO 和 Stackholder 給予回饋。
最後，我們團隊依據在本活動中建立的 story，用樂高積木建立一個小公園，具體呈現我們透過今天課程所獲得的成果。
這個遊戲真得很棒，從遊戲中可以體驗多團隊的 Scrum Team 如何一起開發同一個產品。基本上，都只會有一個 Product Backlog，每一個團隊都是從這裡取得 Story。
遊戲過程中，如果各個小 Team 獨立運作的話，會發生 My City 的城市規劃會很差，沒有一個整體性。所以會自動讓大家覺得需要有一些橫向協同合作。但主持人沒有明確提示要怎麼做，需要靠大家自己的想像力，或是過去的敏捷經驗中，找到一些可以用的元素。
你可以選擇每個 Team 派代表，組成 Scrum of Scrums，透過這個新團隊得知其他團隊的狀態。你可以選擇在 PBR 的時候，跟其他團隊分享 Story 是什麼，AC 是什麼，讓每一個人對於我們的產品都有初步的認知。你可以選擇組織 Joint Retro，讓大家一起討論怎樣的方法，可以幫助大家聚焦在產品，一起交付更有價值的產品。大家一起發揮想像力，說不定可以找到新的方式來幫助多團隊的協作。
基於 LeSS 框架的敏捷組織規模化設計與思考
這個部分是由曾庄浚和申健 (Jacky) 兩個人一起搭配的實際案例分享。曾庄浚講者在开思擔任 Scrum Master / Agile Coach，在團隊成立的初期，團隊人數大約 20人，大家都可以為產品提出更好的優化意見，團隊為最終成果負責，團隊內溝通沒有障礙。團隊成立一年後，研發團隊成長到 50~60 人左右，發現開發速度並沒有呈現線性的成長，團隊的決策成本變高，團隊的協同效率變低。 為了解決這個問題，將大團隊做了拆分，每個 Scrum Team 維持在 4~6 人，包含一名兼職的 Scrum Master。
拆分帶來的好處：
- 團隊的決策更快更一致。
- 團隊的協作效率更高。
- 兼職 Scrum Master 關注團隊人員的成長，負責每日站立會議，開發過程，總結會議的優化和最佳實踐。
拆分帶來的壞處：
- 團隊成員很難看到產品的全貌。
- 業務不清楚自己需求的排程情況。
- 多個團隊同時開發同一業務需求時，出現訊息不對稱問題。
因此，透過申健外部教練的建議，團隊開始嘗試導入 LeSS。
首先團隊想要解決的問題是，如何讓各個 Feature Team 可以同步訊息。團隊採用的方式是：
- 節奏統一：所有團隊迭代節奏統一，迭代長度，計畫會議，站力會議，評審會，回顧會議的時間都是統一的。
- 跨團隊訊息同步：各團隊戰力會議結束後，團隊 Scrum Master 再同步各組訊息，主要是同步團隊進度，需要其他團隊配合或求助的事項，多團隊協作項目的進度情況。
- 評審會時間統一：評審會議統一時間召開，由測試人員或開發人員統一對業務和產品人員進行演示。
- 回顧會議：每個迭代各團隊在迭代的最後一天早上召開，下午所有 Scrum Master 進行全體回顧。
- 管理層支持：設定組織及障礙清單，張貼在白板上，透明公開，同樣設定截止時間和負責人，有管理人員負責改進。
- 優先序排序：由 PO 進行優先序排序。
當公司發展到第三年的時候，團隊人數成長到 200 人，發生新人不熟悉業務，線上質量問題爆發，研發產能跟不上業務需求，因此引入了 LeSS Huge。
整個團隊根據業務特性拆成了四個部落 (在 LeSS 的術語應該是 Area Product，”部落” 的用語參考了 Spotify Model)，並在每一個部落中新增部落SM，部落架構師，部落測試架構師。
- 部落 SM：提升研發團隊的開發效率， 高質量的交付，人員成長，培養後備人才。
- 部落架構師：部落技術架構的演進，以及架構看護，整體 DevOps 能力構建。
- 部落測試架構師：部落自動化測試，測試架構演進，整體 DevOps 能力構建 。
把 LeSS 引入後的組織改造成果，根據業務特性分成多個部落，每個部落設置一位部落 PO，在 Area PO 上面設置總 PO，總 PO 負責公司的戰略規劃及整體優先級的協調。部落 PO 負責部落內的產品輸入，統一優先級，遇到跨部落需求時，需要進行整體溝通，並負責管理各小組 PO 的工作。
各小組內仍保持最小作戰單位，包含 PO、開發、測試人員，所有小組的迭代時間保持一致。部落 SM、部落架構師、部落測試架構師關注於部落內的事務。跨部落也會成立相關的社區，透過社區形式進行溝通與技術交流。
總結一下，聽到實際導入 LeSS 的案例分享，收穫非常的多。LeSS 建議在 Area Product 裡面只會有一個 PO，每一個 Scrum Team 都可以承接這個 Area Product 裡的 Story。但是在這個案例裡，他們選擇設置一個 Area Product，每一個 Scrum Team 裡面又設置了一個 PO，並且預先將每各個 Scrum Team 拆分成只做特定 Feature 的開發團隊。
這個案例裡的組織設計，每個 Scrum Team 只專注在自己任務上面，因為每次都是做很熟悉的東西，所以速度會比較快，但是相對犧牲了一些學習的機會，也降低對於整體產品的專注性。另外組織也會降低適應性，當產品需求變化時，或者某些 Feature 時程比較趕的時候，團隊間就比較沒辦法快速的互相支援。因此 LeSS 裡面不建議把團隊間任務的界限切分得太清楚。
我們用比較客觀的角度分析這個部分，因為團隊任務的劃分不是他們所遇到的問題，也不是他們想解決的問題，我們不必期待用同一個方法，可以套用在所有的公司和團隊裡，我們只要找到一個適合公司與團隊的方法，解決我們想要解決的問題就可以了，不必過於執著。
多個待辦事項對多元學習帶來的影響
在多團隊合作的產品中，往往也會遇到一個問題。到底是 Single Backlog 比較好，還是每一個 Functional Team 、Component Team、Feature Team 有一個各自的 Backlog 比較好。
這一場由呂毅帶來的分享，由系統思考 n(System Thinking) 的角度來探討這個問題。首先要定義優化的目標，我們的優化目標是可以獲得更高的敏捷性。
敏捷性是在不確定的環境裡交付最高的客戶價值。伴隨著不確定性，只有交付的能力並不充分，我們需要檢查和適應的能力才能交付最高的客戶價值。
我們檢查發現市場發生了變化，隨即擁抱變化作出必要的適應，然後交付價值。我們交付了最初的想法，隨即檢查反饋，然後響應反饋作出調整。
每一個 Functional Team 或 Component Team 都有各自的 Backlog 示意圖。
每一個 Feature Team 都有各自的 Backlog 示意圖。
多個待辦事項對多元學習的系統思考圖：
根據這張系統思考圖，我們可以得知這樣的結論：待辦列表越多，專業化程度越高，知識廣度越窄。然後狹窄的知識廣度又成了需要更多待辦列表的原因，這樣就形成增強的R4迴路。這個迴路很容易工作在往更多待辦列表的方向，我們如何能將它反轉？
還是一樣的增強迴路，但是讓它這樣工作 — 待辦列表越少，專業化程度越低，知識廣度越寬，然後就可以有更少的待辦列表，這裡的挑戰是降低專業化程度並不會自動帶來更寬的知識廣度，我們需要多面學習以增加知識廣度。
更少的待辦列表會驅動多面學習；而多面學習又讓我們可以有更少的待辦列表。它們之間互為促進。因此，待辦列表的份數本身就是一個重要的槓桿 — 通過創建一個真正的跨職能和跨組件的特性團隊來擁有一份待辦列表。我們多面學習些什麼？這裡的待辦列表是基於職能和組件的，因此我們需要跨職能和跨組件學習。
總結起來，多個 Functional Team 和 Component Team Backlog 是為了效率，但是他對於端到端的集成時間產生了額外的影響，更糟的是，我們透過系統思考的方式，把更多的考量因素一起考慮以後，發現多個 Backlog 損害到效率本身。多面向的學習可以減少 Backlog 數量，而更少的 Backlog 數量又可以驅動多面向的學習。
詳細的過程與分析，請參考原始文章：
結語
在目前的敏捷實踐裡，大多數的團隊都採用 Scrum。
當研發速度跟不上業務需求的時候，我們期待招募更多的研發團隊成員，希望研發的產出也可以跟著開發團隊人數呈現線性成長，往往結果不如預期。因為人數增加以後，就會帶來更多的溝通成本，更多的協同合作的需求。
因此在這樣的需求下，產生了許多基於 Scrum 框架下的 Multiple Scrum Team 框架。譬如說 Scrum@Scale、LeSS (Large Scale Scrum)、The Nexus、SAFe、Spotify Model 等等。
有的框架是比較輕量的，很容易可以導入並且實踐，有的框架引入比較多的流程與規則，是比較大面向的敏捷轉型。但是目的都是一致的，希望能夠多團隊發開同一個產品。
在引入這些敏捷框架以前，比較好的做法是讓 Single Scrum Team 跑得順順的，引入 XP (Extreme Programming)、CI、CD 等等實踐，當發現這些實踐都無法滿足時，才將敏捷框架導入，會是一個比較好的選擇，避免讓團隊同時要改善流程又要改善工程實踐。
