團隊合作是每一個敏捷流程的核心。Scrum 團隊一起成功、一起失敗——沒有「我的工作」和「你的工作」，只有「我們的工作」。本章探討如何建立全團隊責任感、妥善運用專家、持續做一點所有事情、促進團隊學習，以及透過承諾鼓勵協作。

擁抱全團隊責任 (Embrace Whole-Team Responsibility)#

成為一個功能性 Scrum 團隊的第一步是接受 全團隊責任（whole-team responsibility）。無論問題是什麼——「誰負責品質？」「誰負責 Product Backlog？」「誰負責乾淨的程式碼？」——答案都是：團隊。

Katzenbach 和 Smith 在 The Wisdom of Teams 中寫道：「沒有一個群體能真正成為團隊，除非它能以團隊的身分自我問責。」個別成員會對某些項目感到額外的責任，但這不能免除團隊對整體產品及其開發所有面向的共同責任。

放棄「一個可以掐的脖子」#

從管理者角度，能指著一個人說「出了問題就找他」很方便。但「一個可以掐的脖子」的論點是錯誤的。就像球隊——贏得冠軍的團隊總能找到獲勝的方法，不論情況如何。要建立共同擁有感和責任感的環境，唯一的方法是放棄「一個可以掐的脖子」的概念。

培養全團隊承諾#

在 Sprint 規劃中，雖然會討論誰可能做什麼工作，但這些分配應被視為暫定的。團隊的目標是完成所有承諾的 Product Backlog 項目——這是全團隊的承諾，而非每個人完成自己簽下的任務。

沒有全團隊承諾，Sprint 結束時很可能有許多項目處於「完成 90%」的狀態——因為每個人都在等後面的人完成最後一點工作。

依賴專家但要節制 (Rely On Specialists but Sparingly)#

一個常見的誤解是 Scrum 團隊中每個人都必須是通才（generalist）。這並不正確。

作者用三明治店做比喻：店裡有 點餐員（order takers）、製作員（sandwich makers）和 機動人員（floaters）。點餐員和製作員是專家，機動人員是通才——兩種工作都能做，雖然可能稍慢。每家三明治店都有一些專家，但也學會了擁有通才的價值。

對 Scrum 團隊而言：

• 應始終嘗試擁有一些通才，正是通才讓專家得以專注
• 每當加入一位專家，就像在團隊中加入一位只做三明治的人——放太多專家會增加有人等待工作被交接的可能性

持續做一點所有事情 (Do a Little Bit of Everything All the Time)#

習慣循序開發流程的團隊，已經習慣了專家之間的交接（hand-offs）：分析師交給設計師、設計師交給程式設計師、程式設計師交給測試人員。每次交接都包含會議、文件等開銷。

縮小交接單位#

新加入 Scrum 的團隊常犯的錯誤是假設程式設計師應該先寫完程式碼，再交給測試人員。這導致 Sprint 開始時測試人員無事可做，Sprint 結束時卻被工作淹沒。

正確的做法是：學科間的交接單位應該比單一 Product Backlog 項目更小。例如開發電商運費功能時，程式設計師、測試人員、分析師和 Product Owner 應該同時協作：

• 程式設計師開始寫 FedEx 運費計算時，測試人員同步撰寫和自動化測試
• 分析師同步研究 DHL 的運費參數
• 完成 FedEx 後，團隊立即轉向 DHL，重複此過程

關鍵在於：不是先做完分析階段、再做程式階段、再做測試階段，而是所有活動隨時都在發生一點。

不要等到 Sprint 結束才完成所有事情#

如果繼續以過大的區塊交接工作，會出現一個症狀：直到 Sprint 最後幾天才有項目完成。最好的曝光方式是繪製每天完成的 Product Backlog 項目數量圖表。

混合不同大小的 Product Backlog 項目#

規劃 Sprint 時，注意承諾項目的大小組合。避免全部都是大項目（會把測試工作推到 Sprint 尾端）。建議帶入一到兩個大項目搭配兩到三個較小的項目，確保測試人員在 Sprint 早期就能接到工作。

促進團隊學習 (Foster Team Learning)#

當團隊擁抱了全團隊承諾、減少對專家的依賴、持續做一點所有事情後，很多團隊會滿足於此而停滯。但要成為真正的高績效團隊，必須主動尋求新的學習和分享知識的方式。

確保學習條件存在#

團隊學習需要五個條件：

• 團隊為學習而設計：組建多元成員，並讓團隊盡可能長時間保持在一起（研究建議每三到四年引入一位新成員以維持創造力）
• 個人有具體的知識分享方式：透過 Daily Scrum、Sprint Review、Scrum of Scrums、Wiki、大型可視化圖表等方式分享知識；高績效團隊也會建立 Community of Practice（實踐社群）
• 領導者強化學習的重要性：領導者應展示他們希望在團隊中看到的學習行為——保持可接近性、主動徵求意見、以「易犯錯的模範」自居
• 給團隊激勵性的挑戰：挑戰的呈現方式很重要。不是丟一個不可能的期限說「去完成」，而是承認困難、說明重要性、強調每個人的貢獻
• 支持性的學習環境：包含以下特徵

支持性學習環境的特徵#

• 心理安全（Psychological safety）：團隊成員必須能安全地嘗試新事物、犯錯、提問、參與辯論。在轉型到 Scrum 時特別重要——過去被視為專家的人需要能安心詢問新領域的基礎問題
• 欣賞差異（Appreciation of differences）：團隊需要能挑戰過度同質化傾向的人。Richard Hackman 說：「每個團隊都需要一個偏離者」
• 對新想法開放（Openness to new ideas）：Scrum 團隊經常面臨「比以前更快開發」的挑戰，需要超越既有方法
• 反思的時間（Time for reflection）：大多數團隊發現每個 Sprint 花半小時到半天來尋找改善方式是值得的

消除知識浪費#

Lean 開發專家 Allen Ward 將知識浪費（knowledge waste）分為三類：

• 散亂（Scatter）：任何打破工作流的事物。兩大原因是溝通障礙和糟糕的工具（指僵化的標準化流程，而非軟體產品）
• 交接（Hand-off）：知識、責任、行動和回饋的分離。跨職能團隊的流行，部分就是為了回應傳統開發專案中交接造成的麻煩
• 一廂情願（Wishful thinking）：在資訊不充分的情況下做決策。遲到的專案是最明顯的例子；團隊發現罕見 bug 卻沒有加入自動化測試來防止復發，也是丟棄知識的一廂情願

透過承諾鼓勵協作 (Encourage Collaboration Through Commitment)#

團隊學習只能帶你走這麼遠。要讓自組織團隊作為一個整體而非個人集合來運作，必須不斷重新激發活力並聚焦於共同目標，更新團隊成員對目標和彼此的承諾。

建立承諾的方法#

• 廣泛參與（Involve widely）：讓開發者參與 Product Backlog 撰寫工作坊等活動，團隊成員看到越完整的專案和產品圖景，就越投入
• 找到點燃目的（Find an igniting purpose）：Lynda Gratton 用「hot spot」描述團隊感受到共同做重要事情的興奮時刻。點燃目的不必如拯救生命般崇高，只需讓成員感到興奮、有趣、值得參與
• 利用現有的內在動機（Tap into existing intrinsic motivation）：結構化專案使每個人獨特的個人目標與專案目標一致
• 當心最低動力的成員（Beware the least motivated team member）：一個高度積極的成員能讓隊友都變得更好；但一個消極的成員會拖垮整個團隊
• 讓每個人理解自己與目標的相關性（Help everyone understand their relevance to the goal）：如果成員感覺自己的貢獻微不足道，就很難全心投入
• 建立信心（Build confidence）：自信的團隊幾乎會承諾任何目標。信心來自對自己和隊友的信念

建立承諾不是一次性的工作。團隊需要定期重新激發活力，更新對專案和彼此的承諾。Christopher Avery 建議：「重新定向團隊的最佳時機，是你注意到共同方向感已經消失或能量已經下降的任何時候。」