幾年前，團隊集中在同一地點是常態；如今情況恰恰相反。團隊分散在全球各地或至少跨越幾個時區已成為普遍現象。一個常見的誤解是 Scrum 不適合地理分散的團隊，因為 Scrum 偏好面對面溝通。但事實並非如此 – 雖然集中的團隊總是會優於同等條件的分散團隊，Scrum 確實能幫助分散團隊達到接近集中團隊的績效水準。分散式開發帶來的好處（每個 sprint 末可見的進度、頻繁溝通、品質與測試自動化的強調、知識轉移的改善）遠大於其困難。

本章描述分散團隊可以採取的行動，以盡可能接近集中團隊的績效，同時保有分散的好處（如成本節約、多地招募的能力等）。

Decide How to Distribute Multiple Teams#

當專案涉及的人數足以組成多個 Scrum 團隊時，如何跨地理界線組織團隊是一個重要決策。大型專案可以組織為協作式集中團隊（collaborating collocated teams）或刻意分散團隊（deliberately distributed teams）。

Collaborating Collocated Teams#

在每個城市各建立一個完整團隊，各自擁有從構思到實作所需的所有技能。優點是簡化日常工作，大幅減少跨時區的會議。缺點是 Product Owner 和 ScrumMaster 可能需要跨時區參加 sprint planning 等會議。

Deliberately Distributed Teams#

刻意將團隊成員分散到不同地點。雖然看似增加溝通和協調負擔，但 daily scrum 會議實際上有助於打破文化障礙和工作風格差異，同時增強離岸團隊對客戶需求的理解。

分散團隊時應注意的常見問題：

• 遠端開發人員對業務或領域理解不足
• 不同城市的開發人員不知不覺地對開發內容產生分歧
• 不同城市的開發人員做出不相容的技術決策
• 不同地點之間發展出對立的「我們與他們」關係
• 一個城市的開發人員不知道另一個城市的人在做什麼

減少刻意分散帶來的溝通負擔的好方法是用 boundary spanners（邊界跨越者）來種子團隊 – 選擇曾合作過或在組織內有廣泛人脈的人加入團隊。

如何選擇#

選擇的關鍵在於對溝通不足或透明度缺乏的擔憂程度。如果地點之間可能存在嚴重的溝通或透明度問題（例如因併購而組合的團隊），作者建議刻意分散團隊，以降低地點間全面衝突的風險。

Create Coherence#

Coherence（凝聚力）源自拉丁語 cohaerent，意為「黏在一起」。分散團隊面臨語言、文化、物理距離和時區差異等多重挑戰，因此需要特別努力來建立凝聚力。

Acknowledge Significant Cultural Differences#

Geert Hofstede 調查了 50 多國的 IBM 員工，識別出五個關鍵的文化維度：

• Power Distance Index (PDI)：文化中權力不平等被接受的程度
• Individualism (IDV)：個人主義 vs. 集體主義的傾向
• Achievement Orientation (ACH)：文化對成就、收入等的重視程度
• Uncertainty Avoidance Index (UAI)：文化對不確定性和模糊性的容忍程度
• Long-Term Orientation (LTO)：文化重視長期考量的程度

例如，美中團隊合作時：中國的高 PDI 值（80 vs. 美國 40）意味著中國同事較不會主動挑戰權威，需要額外鼓勵他們參與公開討論。低 IDV 值（20 vs. 91）表示中國團隊成員更重視團隊整體而非個人表現。

任何文化分析都會導致概括化。雖然概括可能在群體層面是正確的，但每個人都是獨特的。文化概括可以提供初步洞察，但了解團隊中個人的最佳方式是個人經驗。

Acknowledge the Small Cultural Differences#

除了宏觀文化差異，還有許多微小但重要的文化差異：

• 不同的假日：許多團隊會建立一個包含所有成員慶祝的假日清單。在 daily scrum 中花幾分鐘讓當地團隊解釋即將到來的假日的目的和習俗
• 不同的工作週：例如以色列和埃及的工作週是週日到週四，而非週一到週五
• 不同的晚間習慣：美國人通常 5-6 點下班，6-7 點晚餐；但印度的晚上 9 點是家庭用餐時間，不適合安排電話會議

Strengthen Functional and Team Subcultures#

軟體開發人員之間的職業次文化可能比國家文化更強大。有效的團隊善於利用職能和團隊次文化來建立凝聚力，讓成員認同「我是 Orion 專案團隊的一員」而非「我是在 Orion 專案上工作的印度團隊成員」。

鼓勵實踐社群的形成、建立共享願景、創造跨地點的團隊認同感，都有助於強化這些次文化。

Communicate and Establish a Shared Vision#

沒有共享願景，就幾乎不可能發展出強大的團隊文化。Product Owner 有責任確保產品願景被所有地點共享。缺乏願景會導致頻繁返工和離岸團隊感覺工作不足的問題。

Reach Agreements#

分散團隊需要將更多協議明確化。集中團隊中隱含的規範（如及時回覆 email），在分散團隊中需要變成明確的約定。常見的團隊約定包括：

• email 的回覆時間（例如一個工作天內）
• 何時在辦公室、何時可以在正常工時外聯繫
• 會議應準時開始
• 各類型溝通（電話、email、IM）分別適用於什麼情況
• 所有團隊如何實施 Scrum（不需要完全一樣，但核心部分需要一致）

Build Trust by Emphasizing Early Progress#

在分散團隊中建立信任更加困難。研究顯示，團隊領導者應該在早期階段專注於任務而非人際關係，強調團隊需要在早期 sprint 就展示可運作的進度。這是因為過早強調關係建設會鼓勵基於表面屬性（美國人、瑞典人、C++ 程式員、Java 程式員等）的次群體形成。

在團隊合作幾個 sprint 後，再將重心轉向社交活動和關係建設。此時團隊成員已對彼此的技能和能力有了基於工作的認識，形成的次群體會更加健康。

Get Together in Person#

所有分散團隊都能從偶爾的面對面聚會中獲益。

Seeding Visits#

Martin Fowler 提倡的 seeding visit（種子拜訪）應在專案早期進行，目的是「建立關係」。將所有團隊成員聚在一起進行短期的集中合作，可以是幾天到整個第一個 sprint 的時間。

Oticon（丹麥助聽器製造商）的做法值得參考：他們讓每位波蘭開發人員到丹麥待兩個月，租了一間舒適的公寓而非住飯店，讓他們完全融入 Scrum 團隊。這讓波蘭和丹麥開發人員建立了深厚的友誼和工作關係。

Contact Visits#

在種子拜訪之後，contact visits（接觸拜訪）用於維持已建立的關係。Fowler 建議每隔幾個月進行一週的拜訪，以完成某個任務（規劃、解決問題等）為導向，但真正目的是建立工作關係。

季度 release planning 是將整個團隊重新聚在一起的好時機，可以結合新 release 的願景設定和前一個 release 最後一個 sprint 的 review。

Traveling Ambassadors#

大使（ambassador）是在「另一個」地點花費較長時間（數週到數月）的半永久駐點人員。大使的工作是寫程式碼、見人、傳遞各種非正式資訊（「Fernando 的寶寶昨晚學會走路了」這類看似不重要但有助於理解同事的瑣事）。

作者分享了一個案例：Denver 和 Toronto 因併購被迫合作的團隊，透過讓一位共同愛好攀岩的開發人員 Frank 作為大使訪問 Toronto，建立了跨城市的友誼，最終在一次伺服器命名被誤解為侮辱的事件中，這份信任成功化解了衝突。

Change How You Communicate#

分散團隊最深刻的影響之一是溝通方式的改變。

Adding Back Some Documentation#

分散團隊不可避免地需要更多書面溝通：書面狀態報告補充 sprint review、設計草圖需要書面化後傳遞、走廊對話被 email 取代。一個有效的做法是在口頭傳達訊息時同時提供書面版本（如 PowerPoint），會後非母語成員可以按自己的節奏閱讀。

Adding Detail to the Product Backlog#

分散團隊通常無法像集中團隊那樣遠離需求文件。Martin Fowler 說：「距離越遠，就需要在溝通需求上投入更多儀式感。」對於時差極大（如加州與班加羅爾相差 12.5 小時）、工作日幾乎沒有重疊的團隊，作者建議使用 send along a test 技術：當 user story 從 Product Owner 發送給團隊時，附上高層級的測試案例來說明 user story 何時算完成。

Encourage Lateral Communication#

在 Scrum 專案中，應鼓勵橫向溝通 – 一個城市的任何人都可以與另一個城市的任何人交談。這有助於對抗 mum effect（沉默效應），即團隊成員因害怕被懲罰、維護團隊和諧或缺乏溝通管道而不分享壞消息的現象。自由且頻繁的橫向溝通讓人更願意在非正式場合提及問題。

Meetings#

對分散團隊而言，時區差異比地理距離的影響更大。舊金山和倫敦的物理距離（8,600 公里）與倫敦和開普敦（9,700 公里）相近，但舊金山和倫敦相差 8 個時區，倫敦和開普敦只差 2 個時區，這使得後者的團隊合作容易得多。

General Advice#

Include Time for Small Talk：集中團隊有很多閒聊機會，分散團隊需要刻意創造。在會議開頭安排簡短的問候時間，聊聊天氣、當地新聞等。有些團隊使用 always-on video room 來重現共處一室的感覺。

Share the Pain：如果會議時間對某個地點不方便，應輪流分擔痛苦。例如加州和班加羅爾的團隊，不要永遠安排對加州方便但對印度人不方便的時間。輪流交替通話時間有助於維持地點間的權力平衡。

Tell Everyone Who Is Speaking：電話會議中辨識不同聲音是一個挑戰。一個有趣的做法叫 low fidelity videoconferencing：每個城市安排一個人，用照片代替攝像頭 – 當 Sonali 說話時舉起她的照片，Manish 說話時換舉他的照片。

Sprint Planning Meeting#

兩種常見策略：

The Long Phone Call（長電話）：所有人撥入同一通電話會議，像集中團隊一樣進行 sprint planning。這只在工作時間有顯著重疊時才可行，適合同一時區或相差不大的團隊。

Two Calls（兩通電話）：將 sprint planning 分成兩天進行。第一天的電話會議聚焦於 Product Owner 的最高優先功能和期望；會後各地子團隊各自規劃；第二天再通一次電話同步各子團隊的承諾。

第三種方式是讓各地技術主管自行進行所有規劃，但作者不推薦此做法，因為它排除了多數人的參與、降低了 buy-in、容易遺漏或誤估任務，且妨礙自組織。

Daily Scrum#

分散式 daily scrum 有三種主要策略：

Single Call（單一電話）：讓所有人在同一通電話上。適合時區差異不大的團隊。若時差太大，有些團隊會降低頻率（每兩三天一次），但作者引用 Fred Brooks 的話提醒：「一個專案怎麼會遲到一年？一天一天地遲到。」建議保持 daily scrum 的每日節奏。

Writing the Meeting（書面會議）：用 email、wiki 或協作工具取代電話會議。作者不推薦作為主要方式，因為口頭承諾（「我今天會完成這個」）比書面承諾感覺更有約束力。

Regional Meetings（區域會議）：各地點各自舉行當地的 daily scrum，然後透過每個子團隊派出至少一位代表的跨地點電話來分享關鍵資訊。這是作者認為最適合高度分散團隊的做法。

Scrum of Scrums#

Scrum of Scrums 每週只舉行兩三次、每次不超過一小時，因此比 daily scrum 更容易在分散團隊中安排。對於跨多個時區的大型團隊，可以選擇單一電話或區域會議的方式來進行。

Sprint Reviews and Retrospectives#

Sprint review 和 retrospective 結合了 daily scrum 和 sprint planning 的特點：不是每天舉行（較容易安排），但比 daily scrum 長（較難找到好時段）。

Participation Is Not Optional：作者不認為參加這些會議是可選的。雖然不期望每次都能在非工作時間參加，但應設定期望讓成員盡量出席，缺席時需提前通知。

Hold Occasional One-City Retrospectives：各地點應定期舉行自己的單城市 retrospective，聚焦於兩個主題：該地點獨有的問題、以及可以改善跨地點互動的事項。

Proceed with Caution#

沒有人會為了團隊的利益而選擇分散團隊。分散決策通常是為了節省成本、在多地招聘、獲取新區域的專業知識、因併購等原因。分散團隊會為個人帶來額外的工作和壓力，並為組織帶來顯著更多的風險。

分散式開發可以被做好，但分散團隊永遠不會像集中團隊那樣表現。研究者 Emmeline de Pillis 和 Kimberly Furumo 在 Communications of the ACM 上發表的結論值得深思：「虛擬團隊在績效、滿意度和成果投入比方面顯著低於面對面團隊。虛擬團隊似乎只在降低承諾、士氣和績效方面表現出色。」

因此，組織必須善用本章描述的各種技術 – 結構選擇、創造凝聚力、面對面聚會、溝通方式調整、會議策略 – 來盡可能幫助分散團隊發揮最佳水準。